chore: add doc pages
This commit is contained in:
Hossein Mehrabi
parent
9d830a51e7
commit
e6c8d5faf0
|
|
@ -0,0 +1,109 @@
|
|||
---
|
||||
id: building
|
||||
title: Getting Started with Nimbus
|
||||
---
|
||||
|
||||
This document explains how to install, test, and run Nimbus on your local machine. To learn about what Nimbus is, see our original [intro post](https://our.status.im/nimbus-for-newbies/). To dig deeper, see the Nimbus [Ethereum 1.0](https://github.com/status-im/nimbus-eth1) and [Ethereum 2.0](https://github.com/status-im/nimbus-eth2) repositories.
|
||||
|
||||
### Building and running Nimbus
|
||||
|
||||
To run Nimbus in [Ethereum 1.0 mode](https://github.com/status-im/nimbus-eth1), first [install the prerequisites](https://github.com/status-im/nimbus-eth1#prerequisites).
|
||||
|
||||
Then:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/status-im/nimbus-eth1
|
||||
cd nimbus-eth1
|
||||
make update
|
||||
|
||||
# >>> WINDOWS ONLY <<<
|
||||
make fetch-dlls # WINDOWS ONLY
|
||||
# >>> WINDOWS ONLY <<<
|
||||
|
||||
make nimbus
|
||||
./build/nimbus
|
||||
```
|
||||
|
||||
Nimbus will now run and attempt to synchronize with the Ethereum 1.0 blockchain. It can currently reach block 1.5 million.
|
||||
|
||||
### Building and running the Ethereum 2.0 local beacon chain simulation
|
||||
|
||||
The beacon chain simulation runs several beacon nodes on the local machine, attaches several local validators to each, and builds a beacon chain between them.
|
||||
|
||||
**Prerequisites:** At the moment, Nimbus has to be built from source, and has the following external dependencies -- developer tools (C compiler, Make, Bash, Git), [PCRE](https://www.pcre.org/); follow the instructions outlined [here](https://github.com/status-im/nim-beacon-chain#prerequisites-for-everyone) to install them.
|
||||
|
||||
Once you've installed the prerequisites, you're ready to enter the Ethereum 2.0 realm of Nimbus:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/status-im/nim-beacon-chain
|
||||
cd nim-beacon-chain
|
||||
|
||||
make
|
||||
make test
|
||||
```
|
||||
|
||||
To run the simulation:
|
||||
|
||||
```bash
|
||||
make eth2_network_simulation
|
||||
```
|
||||
|
||||
If you'd like to clean the previous run's data:
|
||||
|
||||
```bash
|
||||
make clean_eth2_network_simulation_all
|
||||
```
|
||||
|
||||
To change the number of validators and nodes:
|
||||
|
||||
```bash
|
||||
# Clear data files from your last run and start the simulation with a new genesis block:
|
||||
make VALIDATORS=192 NODES=6 USER_NODES=1 eth2_network_simulation
|
||||
```
|
||||
|
||||
If you’d like to see the nodes running on separated sub-terminals inside one big window, install [Multitail](https://www.vanheusden.com/multitail/index.php) (if you're on a Mac, follow the instructions [here](https://brewinstall.org/Install-multitail-on-Mac-with-Brew/)), then:
|
||||
|
||||
|
||||
```
|
||||
USE_MULTITAIL="yes" make eth2_network_simulation
|
||||
```
|
||||
|
||||
You’ll get something like this (click for full size):
|
||||
|
||||
[](https://i.imgur.com/Pc99VDO.png)
|
||||
|
||||
|
||||
You can find out more about the beacon node simulation [here](https://our.status.im/nimbus-development-update-03/#beaconsimulation).
|
||||
|
||||
### Building and running the Ethereum 2.0 local state transition simulation
|
||||
|
||||
This simulation is primarily designed for researchers, but we'll cover it briefly here in case you're curious :)
|
||||
|
||||
The [state transition](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#beacon-chain-state-transition-function) simulation quickly runs the beacon chain state transition function in isolation and outputs JSON snapshots of the state (directly to the `nim-beacon-chain` directory). It runs without networking and blocks are processed without slot time delays.
|
||||
|
||||
```bash
|
||||
# build the state simulator, then display its help ("-d:release" speeds it
|
||||
# up substantially, allowing the simulation of longer runs in reasonable time)
|
||||
make NIMFLAGS="-d:release" state_sim
|
||||
build/state_sim --help
|
||||
```
|
||||
|
||||
Use the output of the `help` command to pass desired values to the simulator - experiment with changing the number of slots, validators, , etc. to get different results.
|
||||
|
||||
The most important options are:
|
||||
|
||||
- `slots` : the number of slots to run the simulation for (default 192)
|
||||
- `validators`: the number of validators (default 6400)
|
||||
- `attesterRatio`: the expected fraction of attesters that actually do their work for every slot (default 0.73)
|
||||
- `json_interval`: how often JSON snapshots of the state are outputted (default every 32 slots -- or once per epoch)
|
||||
|
||||
For example, to run the state simulator for 384 slots, with 20,000 validators, and an average of 66% of attesters doing their work every slot, while outputting snapshots of the state twice per epoch, run:
|
||||
|
||||
```
|
||||
build/state_sim --slots=384 --validators=20000 --attesterRatio=0.66 --json_interval=16
|
||||
```
|
||||
|
||||
|
||||
### Medalla Ethereum 2.0 Testnet
|
||||
|
||||
There is a publicly available [Ethereum 2.0](https://our.status.im/tag/two-point-oh) multi-client testnet running until at least October. Read all about it [here](https://blog.ethereum.org/2020/08/03/eth2-quick-update-no-14/), and learn how you can join it in [the Nimbus beacon chain book](https://status-im.github.io/nimbus-eth2/medalla.html) 💛
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
---
|
||||
title: Contributor Guide
|
||||
sidebar_label: Contributor Guide
|
||||
---
|
||||
|
||||
## How to help with funding
|
||||
|
||||
We have a donation box set up at address `0xDeb4A0e8d9a8dB30a9f53AF2dCc9Eb27060c6557`, as well as a [Gitcoin Grant page](https://gitcoin.co/grants/137/nimbus-2/).
|
||||
|
||||
We use funds from donations to:
|
||||
|
||||
- fund bounties
|
||||
- fund audits of our production code
|
||||
- fund hardware on which to build Nimbus for you, from Raspberry Pis to feature phones
|
||||
|
||||
If you'd like to donate a conditional amount, i.e. one that depends on a certain milestone or deadline, please [get in touch](mailto:jacek@status.im).
|
||||
|
||||
## How To Get Involved with Nimbus' development
|
||||
|
||||
- look around [the repo](https://github.com/status-im/nimbus-eth2), especially the [open issues](https://github.com/status-im/nimbus-eth2/issues)
|
||||
- check out some [open bounties](https://gitcoin.co/explorer?keywords=nimbus&order_by=-web3_created)
|
||||
- learn about the source code by [dissecting](https://github.com/status-im/nimbus-eth2/tree/master/tests)
|
||||
|
||||
To configure your setup for development:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/status-im/nimbus-eth2
|
||||
cd nimbus-eth2
|
||||
make update
|
||||
```
|
||||
|
||||
[Build](/docs/eth2.html) and start hacking!
|
||||
|
||||
## Thought Experiments
|
||||
|
||||
<blockquote className="twitter-tweet" data-theme="dark"><p lang="en" dir="ltr">Still hoping to just have my <a href="https://twitter.com/ethstatus?ref_src=twsrc%5Etfw">@ethstatus</a> desktop wallet be my bn, and have my mobile device be my <a href="https://twitter.com/ethnimbus?ref_src=twsrc%5Etfw">@ethnimbus</a> vc 🤷🏽♀️😅. And then a nice little Rocketpool Staas run by <a href="https://twitter.com/search?q=%24SNT&src=ctag&ref_src=twsrc%5Etfw">$SNT</a>... And anonymous staking in "dark pools" build on application layer, fees paid to client/network nodes. 👌🏽😻.</p>— chloethedev.eth ⟠ δούλος 🏳️⚧️ (@Chloethedev) <a href="https://twitter.com/Chloethedev/status/1320710462032515072?ref_src=twsrc%5Etfw">October 26, 2020</a></blockquote>
|
||||
|
||||
If you have research ideas you'd like to throw at us, exotic hardware you'd like to test on, or anything else revolutionary cooking up in your mind let us know. We'll gladly experiment!
|
||||
|
||||
## Guidelines
|
||||
|
||||
Whatever you might expect to see in other projects applies here:
|
||||
|
||||
- Be nice to others
|
||||
- When evaluating PRs, focus exclusively on the quality of the code
|
||||
- If submitting code, make sure it's tested. All code MUST come with tests. To speed up the review, ping a [team member](/docs/team).
|
||||
- If submitting typo fixes or documentation changes, speed up the review process by pinging a team member. [Jacek](https://github.com/arnetheduck) or [Sacha](https://github.com/unixpi) will usually review those very quickly. The same applies if submitting a tutorial for inclusion on the [official blog](https://our.status.im/tag/nimbus).
|
||||
|
|
@ -0,0 +1,111 @@
|
|||
---
|
||||
id: custom-nimbus-testnet
|
||||
title: Creating your own Nimbus testnet
|
||||
---
|
||||
|
||||
## Building your own Nimbus testnet
|
||||
|
||||
All beacon nodes joining your custom testnet MUST be compiled with the same beacon chain constants - i.e. if a node is compiled with 8 slots per epoch, one with 16 slots per epoch will not be compatible with it. With that in mind, let's do this step of building the basic beacon node binary from within `vendor/nim-beacon-chain`, and let's also build the tool that can generate validator keys.
|
||||
|
||||
> Note that you need Go 1.12+ installed to build the libp2p Go daemon!
|
||||
|
||||
If you haven't cloned the beacon chain implementation already, do it now:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/status-im/nim-beacon-chain
|
||||
cd nim-beacon-chain
|
||||
make update
|
||||
|
||||
# >>> WINDOWS ONLY <<<
|
||||
make fetch-dlls # WINDOWS ONLY
|
||||
# >>> WINDOWS ONLY <<<
|
||||
```
|
||||
|
||||
Then let's build the binaries of the tools we'll need.
|
||||
|
||||
```bash
|
||||
export NIMFLAGS="-d:release -d:SECONDS_PER_SLOT=6 -d:SHARD_COUNT=64 -d:SLOTS_PER_EPOCH=64" \
|
||||
&& make beacon_node validator_keygen
|
||||
```
|
||||
|
||||
This will place the `beacon_node` binary and the `validator_keygen` tool in `build/` in the current folder.
|
||||
|
||||
Let's generate the folders where the node will store its data and then add the validator keys in there. I picked 500 keys.
|
||||
|
||||
```bash
|
||||
mkdir -p $HOME/testnets/custom-network/data
|
||||
./build/validator_keygen --totalValidators=500 --outputDir="$HOME/testnets/custom-network"
|
||||
```
|
||||
|
||||
This will have placed 500 private key files and 500 public key files into the specified output folder.
|
||||
|
||||
Next, let's have the node generate a testnet for us with all the bells and whistles we might need to have others connect to us.
|
||||
|
||||
```bash
|
||||
export NETWORK_DIR=$HOME/testnets/custom-network && ./build/beacon_node \
|
||||
--dataDir=$NETWORK_DIR/data \
|
||||
createTestnet \
|
||||
--networkId=666 \
|
||||
--validatorsDir=$NETWORK_DIR \
|
||||
--totalValidators=500 \
|
||||
--outputGenesis=$NETWORK_DIR/genesis.json \
|
||||
--outputNetwork=$NETWORK_DIR/custom-network.json \
|
||||
--bootstrapAddress=$(curl -s ifconfig.me) \
|
||||
--bootstrapPort=34000 \
|
||||
--genesisOffset=600
|
||||
```
|
||||
|
||||
- We set the home folder of the custom network, pass it to the required params and have it generate the genesis file and the metadata file for others to join us through.
|
||||
- The bootstrap address part is dynamically generated from the ifconfig.me service - you can manually input your public IP address here if you know it or if that service fails to detect it - test with `curl -s ifconfig.me` on the command line.
|
||||
- The port is optional but recommended so you don't get some cross-chain noise when accidentally connecting to other nodes on the default port.
|
||||
- The `genesisOffset` flag sets the time of genesis to some time in the future - in this case 10 minutes. We do this to give everyone who intends to join ample chance to join on genesis time because if they don't and the chain expects validators to be there and perform their duties, they'll be seen as offline and penalized and eventually kicked off the beacon chain.
|
||||
|
||||
Running the above command will result in two new files being created. In my case `$HOME/testnets/custom-network/genesis.json` and `$HOME/testnets/custom-network/custom-network.json`.
|
||||
|
||||
Because these files that were generated are made for others joining you, we need to make a copy of the `custom-network` file so that we can launch our node, the bootstrap node.
|
||||
|
||||
```bash
|
||||
cp $HOME/testnets/custom-network/custom-network.json $HOME/testnets/custom-network/custom-network_boot.json
|
||||
```
|
||||
|
||||
Then open this new file and delete the `bootstrapNodes` object, all of it. If you don't, the node you run will try to connect to a bootstrap node that is effectively its-not-yet-running-self. Without the `bootstrapNodes` part, the node just _runs_ so others can connect _to_ it.
|
||||
|
||||
We are now ready to connect and to share these files with those who would connect to us.
|
||||
|
||||
The `genesis.json` file is the starting state, "block 0" of your testnet beacon chain. It contains the listed validators, initial shufflings, and everything the system needs in order to have the clients connecting to the network build on the same foundation.
|
||||
|
||||
The `custom-network.json` file is the "metadata" file of your new network - it has identified your node, the one this file was generated with - as the bootstrap node and included its enode address under `bootstrapNodes`, along with the other required data and the root of the genesis.
|
||||
|
||||
Let's run the original node now.
|
||||
|
||||
```bash
|
||||
./build/beacon_node --network=$HOME/testnets/custom-network/custom-network_boot.json --stateSnapshot=$HOME/testnets/custom-network/genesis.json --tcpPort=34000 --udpPort=34000
|
||||
```
|
||||
|
||||
You can host `custom-network.json` and `genesis.json` on a server somewhere or in a [Github Gist](https://gist.github.com) so anyone grabbing them will be able to join your network if they execute the command:
|
||||
|
||||
```bash
|
||||
./build/beacon_node --network=$HOME/testnets/custom-network/custom-network.json --stateSnapshot=$HOME/testnets/custom-network/genesis2.json --tcpPort=34001 --udpPort=34001
|
||||
```
|
||||
|
||||
Let's run another node on the same machine where the bootstrap node is running. This requires that we create a new data dir, otherwise it'll clash with the current node. Execute the following chain of commands:
|
||||
|
||||
```bash
|
||||
export DATA_DIR=$HOME/testnets/custom-testnet/node-1 && mkdir -p $DATA_DIR/data && mkdir -p $DATA_DIR/validators && ./build/beacon_node \
|
||||
--network=$HOME/testnets/custom-network/custom-network_boot.json \
|
||||
--stateSnapshot=$HOME/testnets/custom-network/genesis.json \
|
||||
--tcpPort=34000 \
|
||||
--udpPort=34000 \
|
||||
--dataDir:$DATA_DIR/data \
|
||||
--nodename:node1
|
||||
```
|
||||
|
||||
However, they MUST first build their beacon node with the same parameters you did in the beginning of this setup:
|
||||
|
||||
```bash
|
||||
export NIMFLAGS="-d:release -d:SECONDS_PER_SLOT=6 -d:SHARD_COUNT=64 -d:SLOTS_PER_EPOCH=64" && make beacon_node
|
||||
```
|
||||
|
||||
Congrats, you have a custom Nimbus testnet up and running! Host those startup files somewhere, distribute some validator keys, and others can join your testnet!
|
||||
|
||||
[](https://our.status.im/content/images/2019/03/Screenshot-from-2019-03-29-21-25-15.png)
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
---
|
||||
title: Embeddable, Lightweight, and Self-Contained
|
||||
sidebar_label: Design
|
||||
---
|
||||
|
||||
## Design goals
|
||||
|
||||
One of our most important design goals is an application architecture that makes it **simple to embed Nimbus into other software.**
|
||||
|
||||
Another is to **minimize reliance on third-party software.**
|
||||
|
||||
A third is for the application binary to be as **lightweight as possible in terms of resources used.**
|
||||
|
||||
## Integration with Status
|
||||
|
||||
<blockquote className="twitter-tweet" data-theme="dark"><p lang="en" dir="ltr">I can't wait to run Nimbus straight from Status Desktop <a href="https://twitter.com/hashtag/hyped?src=hash&ref_src=twsrc%5Etfw">#hyped</a></p>— JARRAÐ HOPΞ (@jarradhope) <a href="https://twitter.com/jarradhope/status/1293473249347555334?ref_src=twsrc%5Etfw">August 12, 2020</a></blockquote>
|
||||
|
||||
As part of our first design goal, our primary objective here is for Nimbus to be tightly integrated into the [Status messaging app](https://status.im/).
|
||||
|
||||
The dream is for you to be able to run an eth2 validator on Status desktop.
|
||||
|
||||
## Commitment to Ethereum Improvement Proposals (EIP)
|
||||
|
||||
We are committed to open standards and to maintaining consensus with other Ethereum-compliant implementations. As such, the development of Nimbus and the changes in its protocols follow [the EIP process](https://github.com/ethereum/EIPs/).
|
||||
|
||||
We played a role in drafting [EIP-3076: Slashing Protection Interchange Format](https://eips.ethereum.org/EIPS/eip-3076).
|
||||
|
||||
|
||||
## Licensing: MIT, Apache v2.0
|
||||
|
||||
Most of our work is licensed under Apache 2.0 and MIT. A permissive licensing structure with patent protection would
|
||||
|
||||
1. Ensure the compatibility with GPL 2.0 and LGPL 2.0
|
||||
1. Extend the reach of the Ethereum platform
|
||||
1. Foster the highest degree of adoption by governments and enterprise
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
---
|
||||
title: Execution layer (eth1)
|
||||
sidebar_label: Execution layer
|
||||
---
|
||||
|
||||
While our core focus so far has been the consensus layer, we are now devoting significant resources to our execution layer client.
|
||||
|
||||
## Quickstart
|
||||
|
||||
To run Nimbus' [execution layer client](https://github.com/status-im/nimbus-eth1), first [install the prerequisites](https://github.com/status-im/nimbus-eth1#prerequisites).
|
||||
|
||||
Then run the following commands:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/status-im/nimbus-eth1
|
||||
cd nimbus-eth1
|
||||
make update
|
||||
|
||||
# >>> WINDOWS ONLY <<<
|
||||
make fetch-dlls # WINDOWS ONLY
|
||||
# >>> WINDOWS ONLY <<<
|
||||
|
||||
make nimbus
|
||||
./build/nimbus
|
||||
```
|
||||
|
||||
Nimbus will now run and attempt to synchronize with the Ethereum blockchain.
|
||||
|
||||
For a more complete overview see the [repository README](https://github.com/status-im/nimbus-eth1).
|
||||
|
|
@ -0,0 +1,94 @@
|
|||
---
|
||||
title: Connecting to the eth2 chain
|
||||
---
|
||||
|
||||
Depending on your objective, there are various ways to run Nimbus in [Ethereum 2.0 mode](https://github.com/status-im/nimbus-eth2).
|
||||
|
||||
Here is where we push our code: https://github.com/status-im/nimbus-eth2
|
||||
|
||||
The reference documentation is [the Nimbus Book](https://nimbus.guide): it explains all the ways in which you can play with Nimbus, and use Nimbus to either monitor the eth2 chain or become a fully-fledged validator.
|
||||
|
||||
It's hosted here: https://nimbus.guide
|
||||
|
||||
## Build and run the Ethereum 2.0 local beacon chain simulation
|
||||
|
||||
The beacon chain simulation runs several beacon nodes on the local machine, attaches several local validators to each, and builds a beacon chain between them.
|
||||
|
||||
**Prerequisites:** At the moment, Nimbus has to be built from source, and has the following external dependencies -- developer tools (C compiler, Make, Bash, Git), [PCRE](https://www.pcre.org/); follow the instructions outlined [here](https://github.com/status-im/nim-beacon-chain#prerequisites-for-everyone) to install them.
|
||||
|
||||
Once you've installed the prerequisites, you're ready to enter the Ethereum 2.0 realm of Nimbus:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/status-im/nim-beacon-chain
|
||||
cd nim-beacon-chain
|
||||
|
||||
make
|
||||
make test
|
||||
```
|
||||
|
||||
To run the simulation:
|
||||
|
||||
```bash
|
||||
make eth2_network_simulation
|
||||
```
|
||||
|
||||
If you'd like to clean the previous run's data:
|
||||
|
||||
```bash
|
||||
make clean_eth2_network_simulation_all
|
||||
```
|
||||
|
||||
To change the number of validators and nodes:
|
||||
|
||||
```bash
|
||||
# Clear data files from your last run and start the simulation with a new genesis block:
|
||||
make VALIDATORS=192 NODES=6 USER_NODES=1 eth2_network_simulation
|
||||
```
|
||||
|
||||
If you’d like to see the nodes running on separated sub-terminals inside one big window, install [Multitail](https://www.vanheusden.com/multitail/index.php) (if you're on a Mac, follow the instructions [here](https://brewinstall.org/Install-multitail-on-Mac-with-Brew/)), then:
|
||||
|
||||
|
||||
```
|
||||
USE_MULTITAIL="yes" make eth2_network_simulation
|
||||
```
|
||||
|
||||
You’ll get something like this (click for full size):
|
||||
|
||||
[](https://i.imgur.com/Pc99VDO.png)
|
||||
|
||||
|
||||
You can find out more about the beacon node simulation [here](https://our.status.im/nimbus-development-update-03/#beaconsimulation).
|
||||
|
||||
## Build and run the Ethereum 2.0 local state transition simulation
|
||||
|
||||
This simulation is primarily designed for researchers, but we'll cover it briefly here in case you're curious :)
|
||||
|
||||
The [state transition](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#beacon-chain-state-transition-function) simulation quickly runs the beacon chain state transition function in isolation and outputs JSON snapshots of the state (directly to the `nim-beacon-chain` directory). It runs without networking and blocks are processed without slot time delays.
|
||||
|
||||
```bash
|
||||
# build the state simulator, then display its help ("-d:release" speeds it
|
||||
# up substantially, allowing the simulation of longer runs in reasonable time)
|
||||
make NIMFLAGS="-d:release" state_sim
|
||||
build/state_sim --help
|
||||
```
|
||||
|
||||
Use the output of the `help` command to pass desired values to the simulator - experiment with changing the number of slots, validators, , etc. to get different results.
|
||||
|
||||
The most important options are:
|
||||
|
||||
- `slots` : the number of slots to run the simulation for (default 192)
|
||||
- `validators`: the number of validators (default 6400)
|
||||
- `attesterRatio`: the expected fraction of attesters that actually do their work for every slot (default 0.73)
|
||||
- `json_interval`: how often JSON snapshots of the state are outputted (default every 32 slots -- or once per epoch)
|
||||
|
||||
For example, to run the state simulator for 384 slots, with 20,000 validators, and an average of 66% of attesters doing their work every slot, while outputting snapshots of the state twice per epoch, run:
|
||||
|
||||
```
|
||||
build/state_sim --slots=384 --validators=20000 --attesterRatio=0.66 --json_interval=16
|
||||
```
|
||||
|
||||
|
||||
## Medalla Ethereum 2.0 Testnet
|
||||
|
||||
There is a publicly available [Ethereum 2.0](https://our.status.im/tag/two-point-oh) multi-client testnet currently running. Read all about it [here](https://blog.ethereum.org/2020/08/03/eth2-quick-update-no-14/), and learn how you can join it in [the Nimbus beacon chain book](https://status-im.github.io/nimbus-eth2/medalla.html) 💛
|
||||
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
title: Consensus layer (eth2)
|
||||
sidebar_label: Consensus layer
|
||||
---
|
||||
|
||||
Depending on your objective, there are various ways to run Nimbus' [consensus layer client](https://github.com/status-im/nimbus-eth2).
|
||||
|
||||
The reference documentation is [the Nimbus Book](https://nimbus.guide): it explains all the ways in which you can play with Nimbus, and use Nimbus to either monitor the beacon chain or become a fully-fledged validator.
|
||||
|
||||
We encourage you to check it out.
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
id: faq
|
||||
title: Frequently Asked Questions
|
||||
---
|
||||
|
||||
In talking to people both familiar and complete strangers to Ethereum clients, these questions were asked more than once.
|
||||
|
||||
|
||||
### Q: When do you expect to have it production-ready?
|
||||
|
||||
Soon. We've got some network simulations and a [public testnet](https://our.status.im/the-nimbus-mvp-testnet-is-here/) already running for [Ethereum 2.0](https://out.status.im/tag/two-point-oh), and we're syncing up to block 1.5 million on Ethereum 1.0. To stay in the loop, please follow our development updates on [our blog](https://our.status.im/tag/nimbus).
|
||||
|
||||
### Q: How is a super-light node different from just calling Infura through Web3js?
|
||||
|
||||
A Web3js or any similar JavaScript package for communicating with the blockchain is basically a more advanced XMLHttpRequest / Fetch wrapper. What we mean by this is that these packages retrieve information from another node and trust it implicitly. They ask "has this transaction been confirmed?" and get a response that's either "yes" or "that transaction is unknown".
|
||||
|
||||
With light nodes, they ask "give me the data to check if this transaction has been confirmed" and then check on their own. This is a trust-minimized setup which combines the best of both worlds - very little storage and processing power required while allowing for cryptographic verification of the full node's claims.
|
||||
|
||||
### Q: What's the plan for mobile?
|
||||
|
||||
While true that Nimbus only compiles to C, C++ and JavaScript and iOS and Android don't support C natively (and we definitely don't want a JS version of Nimbus running on a mobile device), native compiles with Nim work for both Android and iOS, just like geth written in go works. It's all NDK/C API. We'll soon have published specific instructions on how to compile it for all manner of devices, but you can already give it a go by following the [build instructions](/docs/building.html). Nimbus already runs just fine on OS X and any flavor of Linux, including a [NanoPC-T4 ARM](https://twitter.com/bitfalls/status/1111329152928485377) computer.
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
---
|
||||
title: Fluffy, an ultra light client for Ethereum
|
||||
sidebar_label: Fluffy
|
||||
---
|
||||
|
||||
Nimbus has joined the Ethereum Foundation’s Portal Network team as one of the launch clients for the portal network.
|
||||
|
||||
In a sentence, [the Portal Network](https://github.com/ethereum/stateless-ethereum-specs/blob/master/portal-network.md#network-functionality) is an in-progress cross-team effort to re-imagine the ethereum light client, and develop a practical and functional light client experience.
|
||||
|
||||
|
||||
In particular, our aim is to work together with the EF to develop a new set of Ethereum protocols alongside the existing Eth protocol that will specifically serve this new way of accessing Ethereum data.
|
||||
|
||||
The overarching goal is to provide a mode of operation for Ethereum that serves common usage patterns, as opposed to keeping track of the full state at all times, as current clients do.
|
||||
|
||||
What we are talking about building here is **the perfect client for a wallet. An ultra-light client that contributes to the network and does not require syncing** (i.e. is immediately usable from a fresh install or after being offline).
|
||||
|
||||
As such, one of the end goals for us is to embed this sort of client directly inside the Status app.
|
||||
|
||||
This has the potential to both improve the security and privacy of our users (we will no longer have any reliance on Infura), as well as improve Ethereum’s resilience by allowing each user to contribute back to the health of the network.
|
||||
|
||||
## Resources
|
||||
|
||||
- [Our introductory post](https://our.status.im/nimbus-fluffly/)
|
||||
- The Portal Wire protocol is added to the nim-eth repository, as Node Discovery v5.1 sub-protocol: https://github.com/status-im/nim-eth
|
||||
- Specifications: https://github.com/ethereum/stateless-ethereum-specs/
|
||||
- Website: https://www.ethportal.net/
|
||||
- Some quick notes regarding first Portal Wire interop tests with ddht and trin- https://gist.github.com/kdeme/36795f5deae7d02ce1785e9c7d501e53
|
||||
- Fluffy, our Portal Network client can be found in our nimbus-eth1 repository: https://github.com/status-im/nimbus-eth1/tree/master/fluffy
|
||||
- Portal Network specifications: https://github.com/ethereum/stateless-ethereum-specs/blob/master/portal-network.md
|
||||
- Portal Network website: https://www.ethportal.net/
|
||||
- [The winding road to functional light clients](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) blog post series of Piper Merriam
|
||||
- [This video talk](https://www.youtube.com/watch?v=MZxqRs_tLNs) about the subject.
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
title: A lighter Ethereum Client
|
||||
sidebar_label: What Is Nimbus?
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Nimbus is a client implementation for both Ethereum's consensus layer (eth2) and execution layer (eth1) that strives to be as lightweight as possible in terms of resources used. This allows it to perform well on embedded systems, embedded devices -- including Raspberry Pis and mobile devices.
|
||||
|
||||
However, **resource-restricted hardware is not the only thing Nimbus is good for.** Its low resource consumption makes it **easy to run Nimbus together with other workloads on your server** (this is especially valuable for stakers looking to lower the cost of their server instances).
|
||||
|
||||
|
||||
## Programming language
|
||||
|
||||
[Nim](https://nim-lang.org/) is an efficient, general-purpose systems programming language with a Python-like syntax that compiles to C. Nim allows us to implement Ethereum rapidly and take advantage of the mature C-language tooling: in compilation of machine code, and in the analysis of static code.
|
||||
|
||||
The end result of implementing in Nim is code that:
|
||||
|
||||
1. Enables us to easily bring research into production
|
||||
2. Has a high degree of reasonability for researchers
|
||||
3. Is performant in production
|
||||
|
||||
Both the Nim core contributors and the wider Nim community have been very supportive of this choice.
|
||||
|
||||
|
||||
## Light by design
|
||||
|
||||
|
||||
Existing implementations of Ethereum have focused on desktop computers and servers. These implementations have played a major role in the initial success of Ethereum, however, their deployment on resource-restricted systems has been an afterthought.
|
||||
|
||||
We believe the ability to run a node on resource-restricted hardware is key to a safe and secure Ethereum going forward.
|
||||
|
||||
As such, **Nimbus strives to perform just as well on resource-restricted hardware as it does on desktop computers and servers.**
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
title: An Ethereum 2.0 Sharding Client
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Nimbus aims to be a [sharding](https://github.com/ethereum/wiki/wiki/Sharding-FAQ) client implementation for the Ethereum Blockchain Application Platform. Because the largest deployment of Ethereum will potentially be on embedded systems, Nimbus will be designed to perform well on IoT and personal mobile devices, including older smartphones with resource-restricted hardware. The extensible, configurable, and modular design of Nimbus will make it production ready for Web 3.0 and will ensure that it can be supported and maintained across all goals of Ethereum 2.0.
|
||||
|
||||
|
||||
## GOALS
|
||||
|
||||
|
||||
1. Create an Ethereum implementation suitable for resource-restricted devices.
|
||||
1. Create an implementation team for the [Applied Research Objectives](https://hackmd.io/s/HkLkj55yb#objectives-in-applied-research) of [Ethereum Research](http://ethereumresearch.org/) (aka Ethereum Asia Pacific Limited), with focus on the following:
|
||||
1. Proof of Stake (PoS)
|
||||
1. Sharding
|
||||
1. Stateless Clients
|
||||
1. LES2
|
||||
1. eWASM
|
||||
1. Close the gap between research modeling and production.
|
||||
1. Pledge to participate in, help implement, and conform to the [Ethereum Improvement Proposal](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md).
|
||||
1. Implement permissive licensing.
|
||||
1. Focus on production-ready [Web 3.0](https://medium.com/@matteozago/why-the-web-3-0-matters-and-you-should-know-about-it-a5851d63c949) Stack ([Whisper](https://github.com/ethereum/wiki/wiki/Whisper), [PSS](https://github.com/nolash/psstalk/blob/master/README.md), and [Swarm](https://swarm-guide.readthedocs.io/en/latest/introduction.html)) and its ongoing research and development.
|
||||
1. Focus on marketing and promotion to address community concerns on scalability and to bolster Ethereum's dominant mindshare.
|
||||
|
||||
|
||||
## REQUIREMENTS
|
||||
|
||||
[Nim](https://nim-lang.org/) is an efficient, general-purpose systems programming language with a Python-like syntax that compiles to C. Nim will allow us to implement Ethereum rapidly and to take advantage of the mature C-language tooling: in compilation of machine code, and in the analysis of static code.
|
||||
|
||||
With Ethereum research currently modeled in Python, the end result of implementing in Nim should be code that:
|
||||
|
||||
1. Enables us to easily bring research into production
|
||||
1. Has a high degree of reasonability for researchers
|
||||
1. Is performant in production
|
||||
|
||||
The core contributors and Nim community have been very supportive and enthusiastic for the project.
|
||||
|
||||
|
||||
## Development on Embedded Systems
|
||||
|
||||
We believe that the largest successful deployment of Ethereum will reside on embedded systems: IoT devices and mobile personal devices, such as smartphones. Although Nimbus will support archival nodes, its first implementation will be as a light client, with focus on Proof of Stake and sharding.
|
||||
|
||||
Existing implementations of Ethereum have focused on desktop computers and servers. These implementations have played a major role in the initial success of Ethereum, and they are suitable for full and archival nodes. However, their deployment onto embedded systems has been an afterthought.
|
||||
|
||||
In addition, throughout the development of Status, we have found that the dominant Ethereum implementations, Geth and Parity, are unsuitable for our target platform unless they are profiled and optimised (in progress).
|
||||
|
||||
During the deployment of Status among 40,000 alpha testers, we found that a significant portion (23.6%) of users were still running old mobile devices. In addition, recently discovered [Spectre vulnerabilities](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)) have led to an increase in the demand for open processors. For these reasons, we propose a self-imposed constraint and a requirement that Status perform well on the following:
|
||||
|
||||
|
||||
1. 2014 [SoC](https://en.wikipedia.org/wiki/System_on_a_chip) architectures, such as the [Cortex-A53](https://developer.arm.com/products/processors/cortex-a/cortex-a53) (Samsung Note 4 & [Raspberry Pi 3](https://www.raspberrypi.org/products/raspberry-pi-3-model-b/)) and the Apple A8 (iPhone 6)
|
||||
1. [MIPS](https://en.wikipedia.org/wiki/MIPS_architecture)-based architectures, such as the [Onion Omega2](https://onion.io/omega2/)
|
||||
1. Open-source processors, such as [RISC-V](https://en.wikipedia.org/wiki/RISC-V)
|
||||
|
||||
When the 2020 scalability goal is fully realised, this constraint will help ensure that Ethereum runs performantly on resource-restricted hardware that is at least 6 years old.
|
||||
|
|
@ -0,0 +1,41 @@
|
|||
---
|
||||
title: Explore our libraries
|
||||
sidebar_label: Software Libraries
|
||||
---
|
||||
|
||||
In addition to our [execution layer](https://github.com/status-im/nimbus-eth1) and [consensus layer](https://github.com/status-im/nimbus-eth2) clients we have developed several high-quality libraries (the product of our ethereum work in Nim). These include:
|
||||
|
||||
- Nim libp2p: https://github.com/status-im/nim-libp2p
|
||||
|
||||
- Nim BLS Curve: https://github.com/status-im/nim-blscurve
|
||||
|
||||
- Nim Waku - Waku is a fork of the original Whisper protocol that enables better usability for resource restricted devices: https://github.com/status-im/nim-waku
|
||||
|
||||
- Nim QUIC - QUIC is being adopted as the underlying protocol for HTTP/3 and has the potential to give us censorship resistance due to its resistance to deep packet inspection: https://github.com/status-im/nim-quic
|
||||
|
||||
- Cryptographic functions: https://github.com/cheatfate/nimcrypto
|
||||
|
||||
- Nim Chronicles - detailed logging for Nim: https://github.com/status-im/nim-chronicles
|
||||
|
||||
- Nim Chronos - async Nim: https://github.com/status-im/nim-chronos
|
||||
|
||||
- Nim Web3 - https://github.com/status-im/nim-web3
|
||||
|
||||
- Ethereum Smart Contracts in Nim: https://github.com/status-im/nim-eth-contracts
|
||||
|
||||
- Nim JSON-RPC - a library for routing JSON 2.0 format remote procedure calls over different transports: https://github.com/status-im/nim-json-rpc
|
||||
|
||||
- Nim Stint - a stack based arbitrary precision library: https://github.com/status-im/nim-stint
|
||||
|
||||
- Nim Libbacktrace: https://github.com/status-im/nim-libbacktrace
|
||||
|
||||
- Nim EthHash - proof of work algorithm from Ethereum 1.0 reimplemented in Nim: https://github.com/status-im/nim-ethash
|
||||
|
||||
- Nim Eth - Ethereum-related utilities written in Nim: https://github.com/status-im/nim-eth
|
||||
|
||||
- Documentation Generator - language agnostic (but Nim-preconfigured) generator for beautiful detailed documentation suites for sets of libraries: https://github.com/status-im/nimbus-docs-suite
|
||||
|
||||
- Nim presto - an efficient library for REST API implementation: https://github.com/status-im/nim-presto
|
||||
|
||||
|
||||
We hope you take the time to check them out :)
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
id: libs
|
||||
title: Software Libraries
|
||||
---
|
||||
|
||||
|
|
@ -0,0 +1,168 @@
|
|||
---
|
||||
id: milestones
|
||||
title: Milestones
|
||||
---
|
||||
|
||||
Timelines are approximate and affected by research, implementation considerations, and revisions made while the team produces a detailed implementation timeline.
|
||||
|
||||
|
||||
## Formation of the Team, and Detailed Project Implementation Timeline
|
||||
|
||||
|
||||
### January - February 2018
|
||||
|
||||
|
||||
### Completed:
|
||||
|
||||
1. Form the initial team
|
||||
1. Define the project's scope, architecture, and implementation timelines
|
||||
|
||||
### Goals:
|
||||
|
||||
|
||||
1. Hire core contributors:
|
||||
1. Five (5) full-time core contributors
|
||||
1. Up to five (5) part-time core contributors
|
||||
1. One (1) Technical Program Manager
|
||||
1. One (1) Technical Writer
|
||||
1. Up to ten (10) full-time core contributors by 2019
|
||||
1. Create a detailed timeline for implementing the project as a deliverable
|
||||
|
||||
|
||||
## Compatibility with Ethereum 1.0
|
||||
|
||||
|
||||
### January - November 2018
|
||||
|
||||
As an initial goal, we will focus on implementing all components required for interoperability with the Ethereum ecosystem. We will publish these components as independently reusable modules and libraries.
|
||||
|
||||
However, before starting the implementation in Nim, we will develop an understanding of the existing implementations of Ethereum: [Go Ethereum](https://github.com/ethereum/go-ethereum/), [Pyethereum](https://github.com/ethereum/pyethereum), [Py-EVM](https://github.com/ethereum/py-evm), and [Parity](https://github.com/paritytech/parity).
|
||||
|
||||
The code will consist of independently reusable libraries that have the same permissive license as that of Nimbus itself:
|
||||
|
||||
|
||||
|
||||
1. [RLP encoding and decoding](https://github.com/status-im/nim-rlp)
|
||||
1. [Handling of the state database and users' keyfiles](https://github.com/status-im/nim-eth-keyfile/blob/master/README.md)
|
||||
1. Connecting to the Ethereum network
|
||||
1. Ethereum Patricia Trees
|
||||
1. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md#introduction) sub-protocols
|
||||
1. Ethereum [Ethash](https://github.com/ethereum/wiki/wiki/Ethash) function
|
||||
1. Implementation of EVM
|
||||
|
||||
|
||||
### Goals:
|
||||
|
||||
1. Nimbus is able to
|
||||
1. Sync with the latest blockchain, from scratch
|
||||
1. Accurately execute the entire transaction history
|
||||
1. The team is familiar with all codebases used to implement Ethereum.
|
||||
1. The team understands the main themes from [ethresear.ch](https://ethresear.ch/) and actively participates in EIPs.
|
||||
|
||||
|
||||
## Sharding Phase 1
|
||||
|
||||
|
||||
### July - November 2018
|
||||
|
||||
While implementing compatibility with Ethereum 1.0, we will gain early experience with the complete setup of sharding. As a result:
|
||||
|
||||
|
||||
1. The client will implement the core features necessary for sharding Phase 1.
|
||||
1. The team will actively participate in sharding-related EIPs.
|
||||
|
||||
|
||||
### Goal:
|
||||
|
||||
The architecture of Nimbus supports sharding nodes.
|
||||
|
||||
|
||||
## Auditing of Beta and Security
|
||||
|
||||
|
||||
### November 2018 - March 2019
|
||||
|
||||
An independent security partner will continuously perform a security audit on the Nimbus codebase. We will also adopt frequent reviews of code, testing with automated fuzzing frameworks, and other practices that enhance security. In addition, we will develop a Nim-optimized fuzzing framework and will release it for use by the community at large.
|
||||
|
||||
### Goal:
|
||||
|
||||
Deliver a security-audited, production-ready client.
|
||||
|
||||
## Implementation of Whisper and PSS
|
||||
|
||||
### July - November 2018
|
||||
|
||||
We will set and advertise the bounties as soon as the P2P layer gets implemented. The core team will start working on this in July, unless already completed.
|
||||
|
||||
### Goals:
|
||||
|
||||
1. Make Nimbus the leading platform for conducting research into the scalability aspects of Whisper and PSS. We consider this a key requirement for implementing a fully decentralised Status messaging platform within the Ethereum network.
|
||||
1. Deliver easy-to-use APIs for conducting large-scale and small-scale experiments within the network.
|
||||
|
||||
## Support for LES
|
||||
|
||||
### July - November 2018
|
||||
|
||||
We will optimize the architecture of Nimbus for implementing the [LES protocol](https://github.com/ethereum/wiki/wiki/Light-client-protocol). We will also optimize all internal state-handling operations such that they work efficiently and asynchronously. This will enable on-demand fetching of data from the network. This will also ensure that Nimbus runs with a high degree of concurrency and that the client UI is responsive.
|
||||
|
||||
### Goals:
|
||||
|
||||
1. Enable a Light Mode switch in Nimbus.
|
||||
1. Successfully operate Nimbus in a mobile environment, without relying on a proxy service.
|
||||
|
||||
## Sharding Phase 2
|
||||
|
||||
### November 2018 - July 2019
|
||||
|
||||
We will focus on achieving compatibility with all other clients. In addition, we will implement an [eWASM](https://github.com/ewasm/design/blob/master/README.md) runtime and will add Nim as one of the languages that can target the new VM.
|
||||
|
||||
### Goals:
|
||||
|
||||
Implement the following in Nim:
|
||||
|
||||
1. CLI tools and APIs for running Phase 2 nodes and for interacting with the Validator Manager Contract (VMC)
|
||||
1. The development tools that will target the eWASM runtime environment
|
||||
|
||||
## Casper Implementation
|
||||
|
||||
### December 2018 - February 2019
|
||||
|
||||
The team will closely follow the development of [Casper](https://blockgeeks.com/guides/ethereum-casper/) and will try to achieve and maintain compatibility with the existing Casper deployments.
|
||||
|
||||
## Implementation of Swarm
|
||||
|
||||
### January - July 2019
|
||||
|
||||
We will set and advertise the bounties as soon as the P2P layer gets implemented. The core team will start working on this in January, unless already completed.
|
||||
|
||||
### Goals:
|
||||
|
||||
Implement the following:
|
||||
|
||||
1. Ability to embed Nimbus into applications that deliver the complete Web 3.0 experience
|
||||
1. Support for the [Ethereum Name Service](https://ens.domains/)
|
||||
1. Support for a virtual file-system interface for accessing web content published on Swarm
|
||||
1. Reusable APIs for publishing and obtaining content from Swarm
|
||||
|
||||
## Sharding Phase 3
|
||||
|
||||
### March - August 2019
|
||||
|
||||
We will leverage our LES-optimized architecture to deliver a fully stateless client optimized for mobile devices.
|
||||
|
||||
### Goals:
|
||||
|
||||
Implement support for the following:
|
||||
|
||||
1. Always-on operations on mobile devices, without disrupting the battery life or inducing significant bandwidth charges
|
||||
1. Running stateless executor nodes in deployments of headless servers
|
||||
|
||||
## Ongoing Improvements in Sharding
|
||||
|
||||
### August - December 2019
|
||||
|
||||
### Goals:
|
||||
|
||||
1. Become one of the leading production-ready sharding implementations in the Ethereum ecosystem.
|
||||
1. Take active part in the effort to specify the new programming models required for cross-shard interactions.
|
||||
1. Provide an ongoing research into the applicability and performance characteristics of all super-quadratic sharding designs in a mobile environment.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
id: options
|
||||
title: Beyond the Basics
|
||||
---
|
||||
|
||||
Let's look
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
id: resources
|
||||
title: Resources
|
||||
---
|
||||
|
||||
1. [Awesome Ethereum Virtual Machine](https://github.com/pirapira/awesome-ethereum-virtual-machine)
|
||||
1. [Detailed introduction to the sharding proposal](https://github.com/ethereum/sharding/blob/develop/docs/doc.md)
|
||||
1. [Sharding FAQ](https://github.com/ethereum/wiki/wiki/Sharding-FAQ)
|
||||
1. [Ethereum 2.0: A presentation by Vitalik Buterin at BeyondBlock Taipei 2017](https://www.youtube.com/watch?v=9RtSod8EXn4&feature=youtu.be&t=11493)
|
||||
1. [The Stateless Client Concept](https://ethresear.ch/t/the-stateless-client-concept/172)
|
||||
1. [A Modest Proposal for Ethereum 2.0: A presentation by Vitalik Buterin at devcon three](https://youtu.be/hAhUfCjjkXc)
|
||||
1. [Python Implementation of the EVM](https://github.com/ethereum/py-evm/blob/master/README.md)
|
||||
1. [Discussion about sharding](https://ethresear.ch/c/sharding)
|
||||
1. [Discussion on Casper, scalability, abstraction and other low-level protocol research topics](https://gitter.im/ethereum/research)
|
||||
1. [ethereum/py-evm](https://gitter.im/ethereum/py-evm)
|
||||
1. [Ethereum Sharding: Overview and Finality](https://medium.com/@icebearhww/ethereum-sharding-and-finality-65248951f649)
|
||||
1. [Sharding - Mind Map](https://www.mindomo.com/mindmap/sharding-d7cf8b6dee714d01a77388cb5d9d2a01)
|
||||
1. [On Settlement Finality](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
|
||||
1. [Casper contract and full POS](https://ethresear.ch/t/casper-contract-and-full-pos/136/2)
|
||||
1. [Ethereum Casper 101](http://notes.eth.sg/MYEwhswJwMzAtADgCwEYBM9kAYBGJ4wBTETKdGZdXAVmRvUQDYg=?view#)
|
||||
1. [ethersphere/swarm, Light mode of operation](https://github.com/ethersphere/swarm/wiki/Light-mode-of-operation)
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
module.exports = {
|
||||
main: [
|
||||
'index',
|
||||
'design',
|
||||
'eth1',
|
||||
'eth2',
|
||||
'fluffy',
|
||||
'libraries',
|
||||
'contributor_guide',
|
||||
],
|
||||
}
|
||||
|
|
@ -0,0 +1,45 @@
|
|||
---
|
||||
id: t0
|
||||
title: Joining Nimbus Testnet0
|
||||
---
|
||||
|
||||
This document is a very short guide on how to join our testnet. For a full explanation of what's going on behind the scenes, please see the official [announcement post](https://our.status.im/the-nimbus-mvp-testnet-is-here/).
|
||||
|
||||
## Joining Nimbus Testnet 0
|
||||
|
||||
_Note: in the below commands, the command `make` is universal to *nix systems like Linux / OS X. On Windows, it becomes available with [Git Bash](https://git-scm.com/download/win) if you install Git for Windows, but you can also install [MinGW64](https://github.com/status-im/nimbus#windows) (recommended)._
|
||||
|
||||
Here is the full process if you're starting from scratch, without even Nim installed (you still need RocksDB though, so [install that first](https://github.com/status-im/nimbus#rocksdb)), unless you're on Windows, in which case the "WINDOWS ONLY" part below will handle the problem for you:
|
||||
|
||||
```bash
|
||||
# Ensure you have rocksdb installed before running this!
|
||||
git clone https://github.com/status-im/nim-beacon-chain
|
||||
cd nim-beacon-chain
|
||||
make update # this might take a few minutes
|
||||
|
||||
# >>> WINDOWS ONLY <<<
|
||||
make fetch-dlls # WINDOWS ONLY
|
||||
# >>> WINDOWS ONLY <<<
|
||||
|
||||
make testnet0
|
||||
./build/testnet0_node # this launches the testnet0-specific node you just built
|
||||
```
|
||||
|
||||
Here is the full process if you've already run testnet0 before but might be stuck with old source code or old, incompatible cache.
|
||||
|
||||
```bash
|
||||
cd nim-beacon-chain
|
||||
make update # update dependencies
|
||||
|
||||
# >>> WINDOWS ONLY <<<
|
||||
make fetch-dlls # WINDOWS ONLY
|
||||
# >>> WINDOWS ONLY <<<
|
||||
|
||||
cd vendor/nim-beacon-chain
|
||||
make clean-testnet0 testnet0 # clean cache and rebuild binary
|
||||
./build/testnet0_node # this launches the testnet0-specific node you just built
|
||||
```
|
||||
|
||||
Congratulations, you should now be joining us - your node will start syncing with the current state of our beacon chain. Once you're in sync, you should also start proposing your own blocks and providing attestations - exciting! You are now among [Ethereum 2.0 Nimbus pioneers](https://gitcoin.co/kudos/1160/nimbus_pilot)!
|
||||
|
||||
[](https://our.status.im/content/images/2019/03/Annotation-2019-03-29-202131-1.png)
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
---
|
||||
id: t1
|
||||
title: Joining Nimbus Testnet1
|
||||
---
|
||||
|
||||
Testnet1 is a cutting edge highly breakable in-flux testnet we use to test new features. If you do join, please [take the time to report any bugs](https://github.com/status-im/nim-beacon-chain/issues).
|
||||
|
||||
## Joining Nimbus Testnet 1
|
||||
|
||||
Before following the instructions below, please make sure you have Go installed. Follow [official instructions](https://golang.org/doc/install) and make sure it's above version 1.12. This is required because we build the Libp2p Go daemon. You also need `git-lfs` installed - on Windows that's a command documented below, on other operating systems it can be installed using your system's package manager (e.g. `sudo apt-get install git-lfs`).
|
||||
|
||||
```bash
|
||||
git clone https://github.com/status-im/nim-beacon-chain
|
||||
cd nim-beacon-chain
|
||||
git fetch
|
||||
git checkout devel
|
||||
make update
|
||||
|
||||
# >>> WINDOWS ONLY <<<
|
||||
make fetch-dlls # WINDOWS ONLY
|
||||
# >>> WINDOWS ONLY <<<
|
||||
|
||||
make clean-testnet1 testnet1
|
||||
./scripts/testnet1.sh
|
||||
```
|
||||
|
||||
Your node should be connecting to others now:
|
||||
|
||||
```bash
|
||||
DBG 2019-07-12 09:39:47+02:00 UPnP topics="nat" tid=8215 msg="Internet Gateway Device found but it's not connected. Trying anyway."
|
||||
DBG 2019-07-12 09:39:47+02:00 UPnP: added port mapping topics="nat" tid=8215 externalPort=9100 internalPort=9100 protocol=TCP
|
||||
DBG 2019-07-12 09:39:47+02:00 UPnP: added port mapping topics="nat" tid=8215 externalPort=9100 internalPort=9100 protocol=UDP
|
||||
INF 2019-07-12 09:39:47+02:00 Starting the LibP2P daemon tid=8215 announcedAddresses=@[/ip4/0.0.0.0/tcp/9100] hostAddress=/ip4/0.0.0.0/tcp/9100 keyFile=/home/swader/.cache/nimbus/BeaconNode/testnet1/privkey.protobuf
|
||||
INF 2019-07-12 09:39:48+02:00 Connecting to bootstrap nodes tid=8215 bootstrapNodes="@[{PeerID: '12D3KooWQmdmkcSdRaeLy8dMf9mCMeakJtxgHfX5qGAfqmvu7wTX' Addresses: ['/ip4/188.166.38.238/tcp/9100']}]"
|
||||
DBG 2019-07-12 09:39:49+02:00 Peer connected. Initiating sync tid=8215 bestSlot=0 peer=12*vu7wTX remoteBestSlot=4552
|
||||
DBG 2019-07-12 09:39:49+02:00 Waiting for block headers tid=8215 fromPeer=12*vu7wTX peer=12*vu7wTX remoteBestSlot=4552
|
||||
DBG 2019-07-12 09:39:51+02:00 Block headers received. Requesting block bodies tid=8215 peer=12*vu7wTX
|
||||
DBG 2019-07-12 09:39:57+02:00 Block received tid=8215 blck="(slot: 16, parent_root: \"4EDB527C\", state_root: \"27EEB0FE\", proposer_slashings_len: 0, attester_slashings_len: 0, attestations_len: 0, deposits_len: 0, voluntary_exits_len: 0, transfers_len: 0, signature: \"b5dbe5e4\")" blockRoot=76BE6B5D
|
||||
DBG 2019-07-12 09:39:57+02:00 Advancing state with empty slots tid=8215 stateSlot=0 targetSlot=15
|
||||
INF 2019-07-12 09:39:57+02:00 Block resolved tid=8215 blck="(slot: 16, parent_root: \"4EDB527C\", state_root: \"27EEB0FE\", proposer_slashings_len: 0, attester_slashings_len: 0, attestations_len: 0, deposits_len: 0, voluntary_exits_len: 0, transfers_len: 0, signature: \"b5dbe5e4\")" blockRoot=76BE6B5D justifiedRoot=4EDB527C justifiedSlot=0
|
||||
DBG 2019-07-12 09:39:57+02:00 Block received
|
||||
```
|
||||
|
|
@ -57,6 +57,22 @@ const config = {
|
|||
path: 'about',
|
||||
},
|
||||
],
|
||||
[
|
||||
'@docusaurus/plugin-content-docs',
|
||||
{
|
||||
id: 'docs',
|
||||
routeBasePath: '/docs',
|
||||
path: 'docs',
|
||||
sidebarPath: 'docs/sidebars.js',
|
||||
},
|
||||
],
|
||||
],
|
||||
|
||||
scripts: [
|
||||
{
|
||||
src: 'https://platform.twitter.com/widgets.js',
|
||||
async: true,
|
||||
},
|
||||
],
|
||||
|
||||
themeConfig:
|
||||
|
|
@ -71,6 +87,10 @@ const config = {
|
|||
label: 'About',
|
||||
to: '/about',
|
||||
},
|
||||
{
|
||||
label: 'Docs',
|
||||
to: '/docs',
|
||||
},
|
||||
{
|
||||
label: 'Github',
|
||||
href: 'https://github.com/status-im',
|
||||
|
|
@ -91,7 +111,7 @@ const config = {
|
|||
label: 'Discord',
|
||||
},
|
||||
{
|
||||
href: 'https://nimbus.team/docs/',
|
||||
to: '/docs',
|
||||
label: 'Docs',
|
||||
},
|
||||
{
|
||||
|
|
|
|||
Loading…
Reference in New Issue