doc updates: intro and getting started pages (#81)

This commit is contained in:
Sacha Saint-Leger 2020-08-15 22:12:20 +02:00 committed by GitHub
parent 7cf03103eb
commit cf5b4e642e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 24 additions and 39 deletions

View File

@ -3,11 +3,13 @@ id: building
title: Getting Started with Nimbus title: Getting Started with Nimbus
--- ---
This document will explain how to install, test, and run Nimbus on your local machine. To learn about what Nimbus is, see the [intro post](https://our.status.im/nimbus-for-newbies/). This document will explain how to install, test, and run Nimbus on your local machine. To learn about what Nimbus is, see the [intro post](https://our.status.im/nimbus-for-newbies/). To dig deeper, see the Nimbus [Ethereum 1.0](https://github.com/status-im/nimbus) and [Ethereum 2.0](https://github.com/status-im/nim-beacon-chain) repositories.
### Building and Running Nimbus ### Building and running Nimbus
To run Nimbus in Ethereum 1.0 mode: To run Nimbus in [Ethereum 1.0 mode](https://github.com/status-im/nimbus), first [install the prerequisites](https://github.com/status-im/nimbus#prerequisites).
Then:
```bash ```bash
git clone https://github.com/status-im/nimbus git clone https://github.com/status-im/nimbus
@ -24,22 +26,18 @@ make nimbus
Nimbus will now run and attempt to synchronize with the Ethereum 1.0 blockchain. It can currently reach block 1.5 million. 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 ### 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. This is a precursor to our [testnet](https://our.status.im/the-nimbus-mvp-testnet-is-here/). 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: Golang 1.12+, because we need it to build the Go libp2p daemon for node communication. You also need `git-lfs` installed to run tests - 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`). Prerequisites: Follow the instructions outlined [here](https://github.com/status-im/nim-beacon-chain#prerequisites-for-everyone).
Enter the Ethereum 2.0 realm of Nimbus: Now, enter the Ethereum 2.0 realm of Nimbus:
```bash ```bash
git clone https://github.com/status-im/nim-beacon-chain git clone https://github.com/status-im/nim-beacon-chain
cd nim-beacon-chain cd nim-beacon-chain
# >>> WINDOWS ONLY <<<
make fetch-dlls # WINDOWS ONLY
# >>> WINDOWS ONLY <<<
make make
make test make test
``` ```
@ -53,42 +51,31 @@ make eth2_network_simulation
If you'd like to clean the previous run's data: If you'd like to clean the previous run's data:
```bash ```bash
make clean_eth2_network_simulation_files eth2_network_simulation make clean_eth2_network_simulation_all
``` ```
If you'd like to see the nodes running on separated sub-terminals inside one big window, install [Multitail](https://www.vanheusden.com/multitail/), then:
```bash
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)
To change the number of validators and nodes: To change the number of validators and nodes:
```bash ```bash
VALIDATORS=512 NODES=50 make eth2_network_simulation # 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
``` ```
Find out more about the simulation [here](https://our.status.im/nimbus-development-update-03/). Find out more about the simulation [here](https://our.status.im/nimbus-development-update-03/).
### Building and Running the Ethereum 2.0 local state transition simulation ### Building and running the Ethereum 2.0 local state transition simulation
The state transition simulation measures how fast it can process the tasks in the beacon chain's state transition. The state transition simulation quickly runs the Beacon chain state transition function in isolation and outputs JSON snapshots of the state. It runs without networking and blocks are processed without slot time delays.
```bash ```bash
cd research # build and run the state simulator, then display its help ("-d:release" speeds it
nim c -d:release -r state_sim --help # 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 sim - change number of validators, nodes, etc. to get different results. Use the output of the help command to pass desired values to the sim - change number of validators, nodes, etc. to get different results.
### Nimbus Ethereum 2.0 Testnet ### Medalla Ethereum 2.0 Testnet
We have a publicly available testnet running between Nimbus nodes. Read all about it and learn how you can join it [here](/docs/t0.html). There is also a cutting edge [testnet 1](/docs/t1.html) that's basically a testing ground for testnet 0. 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/nim-beacon-chain/medalla.html).
---
Congrats! You're now running Nimbus for both the Ethereum 1.0 platform, and the coming [Ethereum 2.0](https://our.status.im/tag/two-point-oh).

View File

@ -5,12 +5,12 @@ title: An Ethereum 2.0 Sharding Client
Nimbus aims to be a [sharding](https://eth.wiki/sharding/Sharding-FAQs) 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. Nimbus aims to be a [sharding](https://eth.wiki/sharding/Sharding-FAQs) 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.
For a more comprehensive introduction, please read our Nimbus for Newbies post or proceed directly to [getting started](/docs/building.html) if you're already sold. For a more comprehensive introduction, please read our [Nimbus for Newbies](https://our.status.im/nimbus-for-newbies/) post or proceed directly to [getting started](/docs/building.html) if you're already sold.
## Requirements ## 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. [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 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: With Ethereum research currently modeled in Python, the end result of implementing in Nim should be code that:
@ -23,11 +23,9 @@ The core contributors and Nim community have been very supportive and enthusiast
## Development on Embedded Systems ## 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. 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 full and archival nodes, its main 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. 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 on 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: 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: