acid-info
/
nimbus-site
mirror of https://github.com/acid-info/nimbus-site.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

docs: update content as per request

This commit is contained in:
jinhojang6 2024-02-29 00:30:17 +09:00
parent 7aa173fc58
commit e003921121
No known key found for this signature in database
GPG Key ID: 1762F21FE8B543F8
21 changed files with 11 additions and 934 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
about/clients.md
View File

@ -1,6 +1,6 @@
---
title: Nimbus clients
sidebar_position: 1.1
sidebar_position: 2
sidebar_label: Nimbus clients
hide_table_of_contents: true
---

109
docs/building.md
View File

@ -1,109 +0,0 @@
---
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)](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) 💛

47
docs/contributor_guide.md
View File

@ -1,47 +0,0 @@
---
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&amp;src=ctag&amp;ref_src=twsrc%5Etfw">$SNT</a>... And anonymous staking in &quot;dark pools&quot; build on application layer, fees paid to client/network nodes. 👌🏽😻.</p>&mdash; 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).

111
docs/custom-nimbus-testnet.md
View File

@ -1,111 +0,0 @@
---
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!
[![Screenshot-from-2019-03-29-21-25-15](https://our.status.im/content/images/2019/03/Screenshot-from-2019-03-29-21-25-15.png)](https://our.status.im/content/images/2019/03/Screenshot-from-2019-03-29-21-25-15.png)

35
docs/design.mdx
View File

@ -1,35 +0,0 @@
---
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&#39;t wait to run Nimbus straight from Status Desktop <a href="https://twitter.com/hashtag/hyped?src=hash&amp;ref_src=twsrc%5Etfw">#hyped</a></p>&mdash; 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

29
docs/eth1.md
View File

@ -1,29 +0,0 @@
---
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).

94
docs/eth2-temp.md
View File

@ -1,94 +0,0 @@
---
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)](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) 💛

14
docs/eth2.md
View File

@ -1,14 +0,0 @@
---
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.

21
docs/faq.md
View File

@ -1,21 +0,0 @@
---
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.

32
docs/fluffy.md
View File

@ -1,32 +0,0 @@
---
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.

30
docs/index.md
View File

@ -1,30 +0,0 @@
---
title: Get Started
sidebar_label: Get Started
---
## A lighter, high performing Ethereum client
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.
## 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** as is evidenced by thousands of solo stakers running Nimbus on local hardware and several larger institutional node operators running thousands of validators on enterprise-grade servers with Nimbus.

54
docs/index_old.md
View File

@ -1,54 +0,0 @@
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.

41
docs/libraries.md
View File

@ -1,41 +0,0 @@
---
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 :)

5
docs/libs.md
View File

@ -1,5 +0,0 @@
---
id: libs
title: Software Libraries
---

168
docs/milestones.md
View File

@ -1,168 +0,0 @@
---
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.

6
docs/options.md
View File

@ -1,6 +0,0 @@
---
id: options
title: Beyond the Basics
---
Let's look

21
docs/resources.md
View File

@ -1,21 +0,0 @@
---
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)

11
docs/sidebars.js
View File

@ -1,11 +0,0 @@
module.exports = {
main: [
'index',
'design',
'eth1',
'eth2',
'fluffy',
'libraries',
'contributor_guide',
],
}

45
docs/t0.md
View File

@ -1,45 +0,0 @@
---
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)](https://our.status.im/content/images/2019/03/Annotation-2019-03-29-202131-1.png)

42
docs/t1.md
View File

@ -1,42 +0,0 @@
---
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
```

28
docusaurus.config.js
View File

@ -67,15 +67,15 @@ const config = {
breadcrumbs: false,
},
],
[
'@docusaurus/plugin-content-docs',
{
id: 'docs',
routeBasePath: '/docs',
path: 'docs',
sidebarPath: 'docs/sidebars.js',
},
],
// [
// '@docusaurus/plugin-content-docs',
// {
// id: 'docs',
// routeBasePath: '/docs',
// path: 'docs',
// sidebarPath: 'docs/sidebars.js',
// },
// ],
],
scripts: [
@ -105,10 +105,6 @@ const config = {
label: 'Community',
to: '/community',
},
{
label: 'Docs',
to: '/docs',
},
{
label: 'Guide',
href: 'https://nimbus.guide/',
@ -142,14 +138,10 @@ const config = {
href: 'https://discord.gg/EP8DZnXu9y',
label: 'Discord',
},
{
to: '/docs',
label: 'Docs',
},
{
href: 'https://github.com/status-im',
label: 'Github',
}
},
],
},
{