Book overhaul: modularity + raspberry pi guide (#1908)
* add first draft of Pi guide * pi guide -- edits * restructure book * edits * edits * deposit page: edits cp * deposit page edits * edits * remove extra emacs files * remove extra emacs files * edit toc * remove outdated overview * intro edits * add a note on verifying your validator has successfully attached * add permissions page placeholder to toc
This commit is contained in:
Sacha Saint-Leger
GitHub
parent
756b62fdf5
commit
8b90a34914
|
|
@ -1,18 +1,35 @@
|
|||
# Summary
|
||||
- [Introduction](./intro.md)
|
||||
- [Installation](./install.md)
|
||||
- [Become a Zinken validator](./zinken.md)
|
||||
- [Become a Medalla validator](./medalla.md)
|
||||
- [Troubleshooting Medalla](./medalla-troubleshooting.md)
|
||||
- [Running the beacon node](./beacon_node.md)
|
||||
- [Install dependencies](./install.md)
|
||||
- [Build the beacon node](./build.md)
|
||||
- [Make a deposit](./deposit.md)
|
||||
- [Manage your keys](./keys.md)
|
||||
- [Connect to eth2](./connect-eth2.md)
|
||||
- [Run your node on a Raspberry Pi](./pi-guide.md)
|
||||
- [Keep an eye on your validator](./keep-an-eye.md)
|
||||
- [Keep your validator updated](./keep-updated.md)
|
||||
- [Useful pre-genesis checks]()
|
||||
# Volume 2
|
||||
- [Metrics and pretty pictures](./metrics-pretty-pictures.md)
|
||||
- [Graffiti the blockchain](./graffiti.md)
|
||||
- [Run a local eth1 node]()
|
||||
- [Run just the beacon node]()
|
||||
- [Switch between clients]()
|
||||
- [Permissions]()
|
||||
- [Advanced options](./advanced.md)
|
||||
- [Troubleshooting](./troubleshooting.md)
|
||||
- [API](./api.md)
|
||||
# Advanced
|
||||
- [For developers](./advanced.md)
|
||||
- [Setting up a systemd service](./beacon_node_systemd.md)
|
||||
- [Generating your keys with NBC](./create_wallet_and_deposit.md)
|
||||
# Misc
|
||||
- [Infura guide](infura-guide.md)
|
||||
- [eth2stats guide]()
|
||||
# Volume 3
|
||||
- [For developers](./developers.md)
|
||||
- [Set up a systemd service](./beacon-node-systemd.md)
|
||||
- [Generate your keys with Nimbus](./create-wallet-and-deposit.md)
|
||||
- [Windows users]()
|
||||
- [FAQ](./faq.md)
|
||||
- [Contribute](./contribute.md)
|
||||
- [Resources](./resources.md)
|
||||
# Archived
|
||||
- [Become a Zinken validator](./zinken.md)
|
||||
- [Become a Medalla validator](./medalla.md)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,146 +1,58 @@
|
|||
# Advanced Usage for Developers
|
||||
# Advanced options
|
||||
|
||||
Latest updates happen in the `devel` branch which is merged into `master` every week on Tuesday.
|
||||
### Start multiple nodes
|
||||
|
||||
This page contains tips and tricks for developers, further resources, along with information on how to set up your build environment on your platform.
|
||||
|
||||
### Ubuntu guide
|
||||
|
||||
See [this excellent resource](https://medium.com/@SomerEsat/guide-to-staking-on-ethereum-2-0-ubuntu-medalla-nimbus-5f4b2b0f2d7c) for detailed step-by-step guide on how to stake on eth2 with Ubuntu.
|
||||
|
||||
It contains instructions on how to:
|
||||
|
||||
- Configure a newly running Ubuntu server instance
|
||||
- Configure and run an eth1 node as a service
|
||||
- Compile and configure the Nimbus client for eth 2, phase 0 (Medalla testnet)
|
||||
- Install and configure [Prometheus](https://prometheus.io/) metrics and set up a [Grafana](https://grafana.com/) dashboard
|
||||
|
||||
### Windows dev environment
|
||||
|
||||
Install Mingw-w64 for your architecture using the "[MinGW-W64 Online
|
||||
Installer](https://sourceforge.net/projects/mingw-w64/files/)" (first link
|
||||
under the directory listing). Run it and select your architecture in the setup
|
||||
menu (`i686` on 32-bit, `x86_64` on 64-bit), set the threads to `win32` and
|
||||
the exceptions to "dwarf" on 32-bit and "seh" on 64-bit. Change the
|
||||
installation directory to "C:\mingw-w64" and add it to your system PATH in "My
|
||||
Computer"/"This PC" -> Properties -> Advanced system settings -> Environment
|
||||
Variables -> Path -> Edit -> New -> C:\mingw-w64\mingw64\bin (it's "C:\mingw-w64\mingw32\bin" on 32-bit)
|
||||
|
||||
Install [Git for Windows](https://gitforwindows.org/) and use a "Git Bash" shell to clone and build nimbus-eth2.
|
||||
|
||||
If you don't want to compile PCRE separately, you can fetch pre-compiled DLLs with:
|
||||
|
||||
```bash
|
||||
mingw32-make # this first invocation will update the Git submodules
|
||||
mingw32-make fetch-dlls # this will place the right DLLs for your architecture in the "build/" directory
|
||||
```
|
||||
|
||||
You can now follow the instructions in this this book by replacing `make` with `mingw32-make` (you should run `mingw32` regardless of whether you're running 32-bit or 64-bit architecture):
|
||||
|
||||
```bash
|
||||
mingw32-make test # run the test suite
|
||||
```
|
||||
|
||||
### Linux, macOS
|
||||
|
||||
After cloning the repo:
|
||||
|
||||
```bash
|
||||
# Build beacon_node and all the tools, using 4 parallel Make jobs
|
||||
make -j4
|
||||
|
||||
# Run tests
|
||||
make test
|
||||
|
||||
# Update to latest version
|
||||
git pull
|
||||
make update
|
||||
```
|
||||
|
||||
To run a command that might use binaries from the Status Nim fork:
|
||||
|
||||
```bash
|
||||
./env.sh bash # start a new interactive shell with the right env vars set
|
||||
which nim
|
||||
nim --version # Nimbus is tested and supported on 1.0.2 at the moment
|
||||
|
||||
# or without starting a new interactive shell:
|
||||
./env.sh which nim
|
||||
./env.sh nim --version
|
||||
```
|
||||
|
||||
### Raspberry Pi
|
||||
|
||||
We recommend you remove any cover or use a fan; the Raspberry Pi will get hot (85°C) and throttle.
|
||||
|
||||
- Raspberry PI 3b+ or Raspberry Pi 4b.
|
||||
- 64gb SD Card (less might work too, but the default recommended 4-8GB will probably be too small)
|
||||
- [Raspbian Buster Lite](https://www.raspberrypi.org/downloads/raspbian/) - Lite version is enough to get going and will save some disk space!
|
||||
|
||||
Assuming you're working with a freshly written image:
|
||||
|
||||
```bash
|
||||
|
||||
# Start by increasing swap size to 2gb:
|
||||
sudo vi /etc/dphys-swapfile
|
||||
# Set CONF_SWAPSIZE=2048
|
||||
# :wq
|
||||
sudo reboot
|
||||
|
||||
# Install prerequisites
|
||||
sudo apt-get install git libgflags-dev libsnappy-dev libpcre3-dev
|
||||
|
||||
# Then you can follow instructions for Linux.
|
||||
You can start multiple local nodes, in different terminal windows/tabs, by specifying numeric IDs:
|
||||
|
||||
```
|
||||
|
||||
### Makefile tips and tricks for developers
|
||||
|
||||
- build all those tools known to the Makefile:
|
||||
|
||||
```bash
|
||||
# $(nproc) corresponds to the number of cores you have
|
||||
make -j$(nproc)
|
||||
make medalla NODE_ID=0 # the default
|
||||
make medalla NODE_ID=1
|
||||
make medalla NODE_ID=2
|
||||
```
|
||||
|
||||
- build a specific tool:
|
||||
### Attach multiple validators to the same beacon node
|
||||
|
||||
```bash
|
||||
make state_sim
|
||||
Simply [import as many keystores as you wish](./medalla.md#3-import-keystores) before running `make medalla`. Nimbus will automagically find your keys and attach your validators. See [key management](./medalla.md#key-management) for more information on where we store your keys.
|
||||
|
||||
To give you some context, we (the Nimbus team) are currently running 170 validators per beacon node on our AWS instances.
|
||||
|
||||
### Change the TCP and UDP ports
|
||||
|
||||
To change the TCP and UDP ports from their default value of 9000 to 9100, say, run:
|
||||
|
||||
```
|
||||
make BASE_PORT=9100 medalla
|
||||
```
|
||||
|
||||
- you can control the Makefile's verbosity with the V variable (defaults to 0):
|
||||
You may need to do this if you are running another client.
|
||||
|
||||
```bash
|
||||
make V=1 # verbose
|
||||
make V=2 test # even more verbose
|
||||
### Node parameters
|
||||
|
||||
You can customise your beacon node's parameters using the `NODE_PARAMS` option:
|
||||
|
||||
```
|
||||
make NODE_PARAMS="--tcp-port=9100 --udp-port=9100" medalla
|
||||
```
|
||||
|
||||
- same for the [Chronicles log level](https://github.com/status-im/nim-chronicles#chronicles_log_level):
|
||||
>**Note:** the above command has exactly the same effect as `make BASE_PORT=9100 medalla`
|
||||
|
||||
A complete list of the available parameters can be found [here](https://github.com/status-im/nimbus-eth2/blob/devel/beacon_chain/conf.nim#L92-L210) (use a parameter's `name` field to set it).
|
||||
|
||||
### Logs
|
||||
|
||||
Log files are saved in `build/data/shared_medalla_0/`.
|
||||
|
||||
|
||||
### Makefile
|
||||
|
||||
If you are comfortable reading [Makefiles](https://en.wikipedia.org/wiki/Makefile#:~:text=A%20makefile%20is%20a%20file,to%20generate%20a%20target%2Fgoal), you can see the commands that `make medalla` executes under the hood, [here](https://github.com/status-im/nimbus-eth2/blob/23bec993414df904e9d7ea9d26e65005b981aee0/Makefile#L184-L197).
|
||||
|
||||
Some of the provided options (such as `--network=medalla`) are essential while others (such as the ones controlling logging, metrics, ports, and the RPC service) are there for convenience.
|
||||
|
||||
The Goerli testnet parameters (`$(GOERLI_TESTNETS_PARAMS`), are defined higher up in the Makefile, [here](https://github.com/status-im/nimbus-eth2/blob/23bec993414df904e9d7ea9d26e65005b981aee0/Makefile#L164-L171).
|
||||
|
||||
### Make a deposit directly using Nimbus
|
||||
|
||||
```bash
|
||||
make LOG_LEVEL=DEBUG bench_bls_sig_agggregation # this is the default
|
||||
make LOG_LEVEL=TRACE beacon_node # log everything
|
||||
```
|
||||
|
||||
- pass arbitrary parameters to the Nim compiler:
|
||||
|
||||
```bash
|
||||
make NIMFLAGS="-d:release"
|
||||
make medalla-deposit VALIDATORS=2 # default is just 1
|
||||
```
|
||||
|
||||
- you can freely combine those variables on the `make` command line:
|
||||
|
||||
```bash
|
||||
make -j$(nproc) NIMFLAGS="-d:release" USE_MULTITAIL=yes eth2_network_simulation
|
||||
```
|
||||
|
||||
- don't use the [lightweight stack tracing implementation from nim-libbacktrace](https://github.com/status-im/nimbus-eth2/pull/745):
|
||||
|
||||
```bash
|
||||
make USE_LIBBACKTRACE=0 # expect the resulting binaries to be 2-3 times slower
|
||||
```
|
||||
|
||||
### Multi-client interop scripts
|
||||
|
||||
[This repository](https://github.com/eth2-clients/multinet) contains a set of scripts used by the client implementation teams to test interop between the clients (in certain simplified scenarios). It mostly helps us find and debug issues.
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
# APIs
|
||||
|
||||
NBC exposes a collection of APIs for querying the state of the application at runtime.
|
||||
`nimbus-eth2` exposes a collection of APIs for querying the state of the application at runtime.
|
||||
|
||||
> **Note:** Where applicable, these APIs mimic the [eth2 APIs](https://github.com/ethereum/eth2.0-APIs) with the exception that JSON-RPC is used instead of http rest (the method names, parameters and results are all the same except for the encoding / access method).
|
||||
|
||||
## Introduction
|
||||
|
||||
The NBC API is implemented using JSON-RPC 2.0. To query it, you can use a JSON-RPC library in the language of your choice, or a tool like `curl` to access it from the command line. A tool like [jq](https://stedolan.github.io/jq/) is helpful to pretty-print the responses.
|
||||
The `nimbus-eth2` API is implemented using JSON-RPC 2.0. To query it, you can use a JSON-RPC library in the language of your choice, or a tool like `curl` to access it from the command line. A tool like [jq](https://stedolan.github.io/jq/) is helpful to pretty-print the responses.
|
||||
|
||||
```
|
||||
curl -d '{"jsonrpc":"2.0","id":"id","method":"peers","params":[] }' -H 'Content-Type: application/json' localhost:9190 -s | jq
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Setting up a systemd service
|
||||
# Set up a systemd service
|
||||
|
||||
This guide will take you through how to set up a `systemd` service for your beacon node.
|
||||
This page will take you through how to set up a `systemd` service for your beacon node.
|
||||
> [`systemd`](https://www.freedesktop.org/wiki/Software/systemd/) is a service manager designed specifically for Linux. There is no port to Mac OS.
|
||||
|
||||
## Prerequisites
|
||||
|
|
@ -0,0 +1,219 @@
|
|||
# Run just the beacon node
|
||||
|
||||
The beacon node application connects to the eth2 network, manages the blockchain, and provides API's to interact with the beacon chain.
|
||||
|
||||
You can **run the beacon node without being a validator** - doing so allows you to sync the network and access its latest state.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before building and running the application, make sure you've gone through the [installation guidelines](./install.md).
|
||||
|
||||
## Building the node
|
||||
|
||||
To build the beacon run:
|
||||
|
||||
#### 1. Clone the nim beacon chain repository
|
||||
|
||||
```
|
||||
git clone https://github.com/status-im/nimbus-eth2
|
||||
cd nimbus-eth2
|
||||
```
|
||||
|
||||
#### 2. Run the beacon node build process
|
||||
|
||||
```
|
||||
make beacon_node
|
||||
```
|
||||
|
||||
## Running the node
|
||||
|
||||
When running the beacon node, you connect to a specific ethereum 2 network - this may be a private network or a public testnet like [Medalla](https://github.com/goerli/medalla/).
|
||||
|
||||
> **Note:** when running the node for the first time, you may need to specify network parameters, boot nodes and genesis information. This information can typically be found in the [eth2 testnets](https://github.com/eth2-clients/eth2-testnets) repository.
|
||||
|
||||
Once the beacon node is running, it will first connect to the boot nodes in the network, look for more peers and start syncing the chain. Once the sync is complete, it will keep following the head of the chain (you can interact with it through the [API](./api.md).
|
||||
|
||||
Before running the beacon node, it's important that your computer is set to the correct time - preferably using a trusted time source (this can be an NTP server you trust, GPS time or another precise source of time) -- however don't worry if you're unsure of how to do this, it isn't essential for testnet purposes.
|
||||
|
||||
### Syncing
|
||||
|
||||
To start syncing the `medalla` network:
|
||||
|
||||
|
||||
```
|
||||
make medalla
|
||||
|
||||
# Build output...
|
||||
|
||||
```
|
||||
|
||||
This will build Nimbus and its dependencies, and connect you to Medalla.
|
||||
You should see that the beacon node has launched and started syncing.
|
||||
|
||||
```
|
||||
INF 2020-07-03 15:28:15+02:00 Starting beacon node topics="beacnde" tid=176865 file=beacon_node.nim:866 SECONDS_PER_SLOT=12 SLOTS_PER_EPOCH=32 SPEC_VERSION=0.12.1 cat=init dataDir=/home/arnetheduck/status/nim-beacon-chain/build/data/shared_medalla_0 finalizedRoot=72e7b21c finalizedSlot=20064 headRoot=f92bf720 headSlot=20142 nim="Nim Compiler Version 1.2.2 [Linux: amd64] (be34b5ab)" pcs=start_beacon_node timeSinceFinalization=-108322 version="0.5.0 (c64737e)"
|
||||
|
||||
|
||||
peers: 7 ❯ finalized: 3a806c9f:634 ❯ head: b364f8e9:636:29 ❯ time: 909:7 (29095) ETH: 0.0
|
||||
```
|
||||
|
||||
### Status bar
|
||||
|
||||
The status bar shows important health information about your node:
|
||||
|
||||
* peers - The number of peers you're connected to
|
||||
* finalized - The block root and epoch of the latest finalized checkpoint - when the network is healthy, this value will stay at 2-3 epochs from the wall clock
|
||||
* head - The block root and time of the head block - as blocks are produced and processed, this will be updated to the latest head block as chosen by the consensus algorithm.
|
||||
* time - The current wall time according to your computer - when the node is synced, the head block will closely follow this time.
|
||||
* ETH: the total ETH validators attached to the node have accumulated. When there are no validators attached, this number will be 0.
|
||||
|
||||
Time is shown as `epoch:subslot`, starting from the block chain genesis time - one epoch is typically 32 slots but this may vary between networks.
|
||||
|
||||
The status bar content may be updated using command line flags.
|
||||
|
||||
### Metrics
|
||||
Nimbus includes metrics support using the Prometheus format. To enable it, you need to enable the insecure feature when compiling the application. The http server that exports Prometheus metrics should not be exposed to external parties.
|
||||
|
||||
```
|
||||
# Compile with insecure features enabled
|
||||
make NIMFLAGS="-d:insecure" medalla
|
||||
```
|
||||
|
||||
## Help
|
||||
To see a list of command line options with descriptions, navigate to the `build` directory and run:
|
||||
|
||||
```
|
||||
./beacon_node --help
|
||||
```
|
||||
|
||||
You should see the following output:
|
||||
|
||||
```
|
||||
Usage:
|
||||
|
||||
beacon_node [OPTIONS]... command
|
||||
|
||||
The following options are available:
|
||||
|
||||
--log-level Sets the log level.
|
||||
--eth1-network The Eth1 network tracked by the beacon node.
|
||||
-d, --data-dir The directory where nimbus will store all blockchain data.
|
||||
--web3-url URL of the Web3 server to observe Eth1.
|
||||
--deposit-contract Address of the deposit contract.
|
||||
--deposit-contract-block The Eth1 block hash where the deposit contract has been deployed.
|
||||
--non-interactive Do not display interative prompts. Quit on missing configuration.
|
||||
-b, --bootstrap-node Specifies one or more bootstrap nodes to use when connecting to the network.
|
||||
--bootstrap-file Specifies a line-delimited file of bootstrap Ethereum network addresses.
|
||||
--listen-address Listening address for the Ethereum LibP2P traffic.
|
||||
--tcp-port Listening TCP port for Ethereum LibP2P traffic.
|
||||
--udp-port Listening UDP port for node discovery.
|
||||
--max-peers The maximum number of peers to connect to.
|
||||
--nat Specify method to use for determining public address. Must be one of: any, none,
|
||||
upnp, pmp, extip:<IP>.
|
||||
-v, --validator Path to a validator keystore.
|
||||
--validators-dir A directory containing validator keystores.
|
||||
--secrets-dir A directory containing validator keystore passwords.
|
||||
--wallets-dir A directory containing wallet files.
|
||||
-s, --state-snapshot Json file specifying a recent state snapshot.
|
||||
--node-name A name for this node that will appear in the logs. If you set this to 'auto', a
|
||||
persistent automatically generated ID will be selected for each --data-dir
|
||||
folder.
|
||||
--verify-finalization Specify whether to verify finalization occurs on schedule, for testing.
|
||||
--stop-at-epoch A positive epoch selects the epoch at which to stop.
|
||||
--metrics Enable the metrics server.
|
||||
--metrics-address Listening address of the metrics server.
|
||||
--metrics-port Listening HTTP port of the metrics server.
|
||||
--status-bar Display a status bar at the bottom of the terminal screen.
|
||||
--status-bar-contents Textual template for the contents of the status bar.
|
||||
--rpc Enable the JSON-RPC server.
|
||||
--rpc-port HTTP port for the JSON-RPC service.
|
||||
--rpc-address Listening address of the RPC server.
|
||||
--in-process-validators Disable the push model (the beacon node tells a signing process with the private
|
||||
keys of the validators what to sign and when) and load the validators in the
|
||||
beacon node itself.
|
||||
--dump Write SSZ dumps of blocks, attestations and states to data dir.
|
||||
|
||||
Available sub-commands:
|
||||
|
||||
beacon_node_shared_medalla_0 createTestnet [OPTIONS]...
|
||||
|
||||
The following options are available:
|
||||
|
||||
--validators-dir Directory containing validator keystores.
|
||||
--total-validators The number of validator deposits in the newly created chain.
|
||||
--first-validator Index of first validator to add to validator list.
|
||||
--last-user-validator The last validator index that will free for taking from a testnet participant.
|
||||
--bootstrap-address The public IP address that will be advertised as a bootstrap node for the
|
||||
testnet.
|
||||
--bootstrap-port The TCP/UDP port that will be used by the bootstrap node.
|
||||
--genesis-offset Seconds from now to add to genesis time.
|
||||
--output-genesis Output file where to write the initial state snapshot.
|
||||
--with-genesis-root Include a genesis root in 'network.json'.
|
||||
--output-bootstrap-file Output file with list of bootstrap nodes for the network.
|
||||
|
||||
beacon_node_shared_medalla_0 deposits [OPTIONS]... command
|
||||
|
||||
The following options are available:
|
||||
|
||||
--deposit-private-key Private key of the controlling (sending) account.
|
||||
|
||||
Available sub-commands:
|
||||
|
||||
beacon_node_shared_medalla_0 deposits create [OPTIONS]...
|
||||
|
||||
Creates validator keystores and deposits.
|
||||
|
||||
The following options are available:
|
||||
|
||||
--count Number of deposits to generate.
|
||||
--wallet An existing wallet ID. If not specified, a new wallet will be created.
|
||||
--out-validatorss-dir Output folder for validator keystores and deposits.
|
||||
--out-secrets-dir Output folder for randomly generated keystore passphrases.
|
||||
--dont-send By default, all created deposits are also immediately sent to the validator
|
||||
deposit contract. You can use this option to prevent this behavior. Use the
|
||||
`deposits send` command to send the deposit transactions at your convenience
|
||||
later.
|
||||
|
||||
beacon_node_shared_medalla_0 deposits send [OPTIONS]...
|
||||
|
||||
Sends prepared deposits to the validator deposit contract.
|
||||
|
||||
The following options are available:
|
||||
|
||||
--validators-dir A folder with validator metadata created by the `deposits create` command.
|
||||
--min-delay Minimum possible delay between making two deposits (in seconds).
|
||||
--max-delay Maximum possible delay between making two deposits (in seconds).
|
||||
|
||||
beacon_node_shared_medalla_0 deposits status
|
||||
|
||||
Displays status information about all deposits.
|
||||
|
||||
beacon_node_shared_medalla_0 wallets command
|
||||
|
||||
Available sub-commands:
|
||||
|
||||
beacon_node_shared_medalla_0 wallets create [OPTIONS]...
|
||||
|
||||
Creates a new EIP-2386 wallet.
|
||||
|
||||
The following options are available:
|
||||
|
||||
--name An easy-to-remember name for the wallet of your choice.
|
||||
--next-account Initial value for the 'nextaccount' property of the wallet.
|
||||
--out Output wallet file.
|
||||
|
||||
beacon_node_shared_medalla_0 wallets restore [OPTIONS]...
|
||||
|
||||
Restores a wallet from cold storage.
|
||||
|
||||
The following options are available:
|
||||
|
||||
--name An easy-to-remember name for the wallet of your choice.
|
||||
--deposits Expected number of deposits to recover. If not specified, Nimbus will try to
|
||||
guess the number by inspecting the latest beacon state.
|
||||
--out Output wallet file.
|
||||
|
||||
beacon_node_shared_medalla_0 wallets list
|
||||
|
||||
Lists details about all wallets.
|
||||
```
|
||||
|
|
@ -1,219 +1 @@
|
|||
# The beacon node
|
||||
|
||||
The beacon node application connects to the eth2 network, manages the blockchain, and provides API's to interact with the beacon chain.
|
||||
|
||||
You can **run the beacon node without being a validator** - doing so allows you to sync the network and access its latest state.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before building and running the application, make sure you've gone through the [installation guidelines](./install.md).
|
||||
|
||||
## Building the node
|
||||
|
||||
To build the beacon run:
|
||||
|
||||
#### 1. Clone the nim beacon chain repository
|
||||
|
||||
```
|
||||
git clone https://github.com/status-im/nimbus-eth2
|
||||
cd nimbus-eth2
|
||||
```
|
||||
|
||||
#### 2. Run the beacon node build process
|
||||
|
||||
```
|
||||
make beacon_node
|
||||
```
|
||||
|
||||
## Running the node
|
||||
|
||||
When running the beacon node, you connect to a specific ethereum 2 network - this may be a private network or a public testnet like [Medalla](https://github.com/goerli/medalla/).
|
||||
|
||||
> **Note:** when running the node for the first time, you may need to specify network parameters, boot nodes and genesis information. This information can typically be found in the [eth2 testnets](https://github.com/eth2-clients/eth2-testnets) repository.
|
||||
|
||||
Once the beacon node is running, it will first connect to the boot nodes in the network, look for more peers and start syncing the chain. Once the sync is complete, it will keep following the head of the chain (you can interact with it through the [API](./api.md).
|
||||
|
||||
Before running the beacon node, it's important that your computer is set to the correct time - preferably using a trusted time source (this can be an NTP server you trust, GPS time or another precise source of time) -- however don't worry if you're unsure of how to do this, it isn't essential for testnet purposes.
|
||||
|
||||
### Syncing
|
||||
|
||||
To start syncing the `medalla` network:
|
||||
|
||||
|
||||
```
|
||||
make medalla
|
||||
|
||||
# Build output...
|
||||
|
||||
```
|
||||
|
||||
This will build Nimbus and its dependencies, and connect you to Medalla.
|
||||
You should see that the beacon node has launched and started syncing.
|
||||
|
||||
```
|
||||
INF 2020-07-03 15:28:15+02:00 Starting beacon node topics="beacnde" tid=176865 file=beacon_node.nim:866 SECONDS_PER_SLOT=12 SLOTS_PER_EPOCH=32 SPEC_VERSION=0.12.1 cat=init dataDir=/home/arnetheduck/status/nim-beacon-chain/build/data/shared_medalla_0 finalizedRoot=72e7b21c finalizedSlot=20064 headRoot=f92bf720 headSlot=20142 nim="Nim Compiler Version 1.2.2 [Linux: amd64] (be34b5ab)" pcs=start_beacon_node timeSinceFinalization=-108322 version="0.5.0 (c64737e)"
|
||||
|
||||
|
||||
peers: 7 ❯ finalized: 3a806c9f:634 ❯ head: b364f8e9:636:29 ❯ time: 909:7 (29095) ETH: 0.0
|
||||
```
|
||||
|
||||
### Status bar
|
||||
|
||||
The status bar shows important health information about your node:
|
||||
|
||||
* peers - The number of peers you're connected to
|
||||
* finalized - The block root and epoch of the latest finalized checkpoint - when the network is healthy, this value will stay at 2-3 epochs from the wall clock
|
||||
* head - The block root and time of the head block - as blocks are produced and processed, this will be updated to the latest head block as chosen by the consensus algorithm.
|
||||
* time - The current wall time according to your computer - when the node is synced, the head block will closely follow this time.
|
||||
* ETH: the total ETH validators attached to the node have accumulated. When there are no validators attached, this number will be 0.
|
||||
|
||||
Time is shown as `epoch:subslot`, starting from the block chain genesis time - one epoch is typically 32 slots but this may vary between networks.
|
||||
|
||||
The status bar content may be updated using command line flags.
|
||||
|
||||
### Metrics
|
||||
Nimbus includes metrics support using the Prometheus format. To enable it, you need to enable the insecure feature when compiling the application. The http server that exports Prometheus metrics should not be exposed to external parties.
|
||||
|
||||
```
|
||||
# Compile with insecure features enabled
|
||||
make NIMFLAGS="-d:insecure" medalla
|
||||
```
|
||||
|
||||
## Help
|
||||
To see a list of command line options with descriptions, navigate to the `build` directory and run:
|
||||
|
||||
```
|
||||
./beacon_node --help
|
||||
```
|
||||
|
||||
You should see the following output:
|
||||
|
||||
```
|
||||
Usage:
|
||||
|
||||
beacon_node [OPTIONS]... command
|
||||
|
||||
The following options are available:
|
||||
|
||||
--log-level Sets the log level.
|
||||
--eth1-network The Eth1 network tracked by the beacon node.
|
||||
-d, --data-dir The directory where nimbus will store all blockchain data.
|
||||
--web3-url URL of the Web3 server to observe Eth1.
|
||||
--deposit-contract Address of the deposit contract.
|
||||
--deposit-contract-block The Eth1 block hash where the deposit contract has been deployed.
|
||||
--non-interactive Do not display interative prompts. Quit on missing configuration.
|
||||
-b, --bootstrap-node Specifies one or more bootstrap nodes to use when connecting to the network.
|
||||
--bootstrap-file Specifies a line-delimited file of bootstrap Ethereum network addresses.
|
||||
--listen-address Listening address for the Ethereum LibP2P traffic.
|
||||
--tcp-port Listening TCP port for Ethereum LibP2P traffic.
|
||||
--udp-port Listening UDP port for node discovery.
|
||||
--max-peers The maximum number of peers to connect to.
|
||||
--nat Specify method to use for determining public address. Must be one of: any, none,
|
||||
upnp, pmp, extip:<IP>.
|
||||
-v, --validator Path to a validator keystore.
|
||||
--validators-dir A directory containing validator keystores.
|
||||
--secrets-dir A directory containing validator keystore passwords.
|
||||
--wallets-dir A directory containing wallet files.
|
||||
-s, --state-snapshot Json file specifying a recent state snapshot.
|
||||
--node-name A name for this node that will appear in the logs. If you set this to 'auto', a
|
||||
persistent automatically generated ID will be selected for each --data-dir
|
||||
folder.
|
||||
--verify-finalization Specify whether to verify finalization occurs on schedule, for testing.
|
||||
--stop-at-epoch A positive epoch selects the epoch at which to stop.
|
||||
--metrics Enable the metrics server.
|
||||
--metrics-address Listening address of the metrics server.
|
||||
--metrics-port Listening HTTP port of the metrics server.
|
||||
--status-bar Display a status bar at the bottom of the terminal screen.
|
||||
--status-bar-contents Textual template for the contents of the status bar.
|
||||
--rpc Enable the JSON-RPC server.
|
||||
--rpc-port HTTP port for the JSON-RPC service.
|
||||
--rpc-address Listening address of the RPC server.
|
||||
--in-process-validators Disable the push model (the beacon node tells a signing process with the private
|
||||
keys of the validators what to sign and when) and load the validators in the
|
||||
beacon node itself.
|
||||
--dump Write SSZ dumps of blocks, attestations and states to data dir.
|
||||
|
||||
Available sub-commands:
|
||||
|
||||
beacon_node_shared_medalla_0 createTestnet [OPTIONS]...
|
||||
|
||||
The following options are available:
|
||||
|
||||
--validators-dir Directory containing validator keystores.
|
||||
--total-validators The number of validator deposits in the newly created chain.
|
||||
--first-validator Index of first validator to add to validator list.
|
||||
--last-user-validator The last validator index that will free for taking from a testnet participant.
|
||||
--bootstrap-address The public IP address that will be advertised as a bootstrap node for the
|
||||
testnet.
|
||||
--bootstrap-port The TCP/UDP port that will be used by the bootstrap node.
|
||||
--genesis-offset Seconds from now to add to genesis time.
|
||||
--output-genesis Output file where to write the initial state snapshot.
|
||||
--with-genesis-root Include a genesis root in 'network.json'.
|
||||
--output-bootstrap-file Output file with list of bootstrap nodes for the network.
|
||||
|
||||
beacon_node_shared_medalla_0 deposits [OPTIONS]... command
|
||||
|
||||
The following options are available:
|
||||
|
||||
--deposit-private-key Private key of the controlling (sending) account.
|
||||
|
||||
Available sub-commands:
|
||||
|
||||
beacon_node_shared_medalla_0 deposits create [OPTIONS]...
|
||||
|
||||
Creates validator keystores and deposits.
|
||||
|
||||
The following options are available:
|
||||
|
||||
--count Number of deposits to generate.
|
||||
--wallet An existing wallet ID. If not specified, a new wallet will be created.
|
||||
--out-validatorss-dir Output folder for validator keystores and deposits.
|
||||
--out-secrets-dir Output folder for randomly generated keystore passphrases.
|
||||
--dont-send By default, all created deposits are also immediately sent to the validator
|
||||
deposit contract. You can use this option to prevent this behavior. Use the
|
||||
`deposits send` command to send the deposit transactions at your convenience
|
||||
later.
|
||||
|
||||
beacon_node_shared_medalla_0 deposits send [OPTIONS]...
|
||||
|
||||
Sends prepared deposits to the validator deposit contract.
|
||||
|
||||
The following options are available:
|
||||
|
||||
--validators-dir A folder with validator metadata created by the `deposits create` command.
|
||||
--min-delay Minimum possible delay between making two deposits (in seconds).
|
||||
--max-delay Maximum possible delay between making two deposits (in seconds).
|
||||
|
||||
beacon_node_shared_medalla_0 deposits status
|
||||
|
||||
Displays status information about all deposits.
|
||||
|
||||
beacon_node_shared_medalla_0 wallets command
|
||||
|
||||
Available sub-commands:
|
||||
|
||||
beacon_node_shared_medalla_0 wallets create [OPTIONS]...
|
||||
|
||||
Creates a new EIP-2386 wallet.
|
||||
|
||||
The following options are available:
|
||||
|
||||
--name An easy-to-remember name for the wallet of your choice.
|
||||
--next-account Initial value for the 'nextaccount' property of the wallet.
|
||||
--out Output wallet file.
|
||||
|
||||
beacon_node_shared_medalla_0 wallets restore [OPTIONS]...
|
||||
|
||||
Restores a wallet from cold storage.
|
||||
|
||||
The following options are available:
|
||||
|
||||
--name An easy-to-remember name for the wallet of your choice.
|
||||
--deposits Expected number of deposits to recover. If not specified, Nimbus will try to
|
||||
guess the number by inspecting the latest beacon state.
|
||||
--out Output wallet file.
|
||||
|
||||
beacon_node_shared_medalla_0 wallets list
|
||||
|
||||
Lists details about all wallets.
|
||||
```
|
||||
# Run the beacon node
|
||||
|
|
|
|||
|
|
@ -0,0 +1,31 @@
|
|||
# Build the beacon node
|
||||
|
||||
The beacon node connects to the eth2 network, manages the blockchain, and provides API's to interact with the beacon chain.
|
||||
|
||||
Importantly, you need to have built the beacon node in order to be able to import your keys.
|
||||
|
||||
*Todo: explain relationship between beacon node and validator client*
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before building and running the application, make sure you've gone through the [installed the required dependencies](./install.md).
|
||||
|
||||
## Building the node
|
||||
|
||||
#### 1. Clone the nim beacon chain repository
|
||||
|
||||
```
|
||||
git clone https://github.com/status-im/nimbus-eth2
|
||||
cd nimbus-eth2
|
||||
```
|
||||
|
||||
#### 2. Run the beacon node build process
|
||||
|
||||
To build the Nimbus beacon node and it's dependencies, run:
|
||||
|
||||
```
|
||||
make beacon_node
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
# Connect to eth2
|
||||
|
||||
From the `nimbus-eth2` repository, run:
|
||||
|
||||
```
|
||||
make medalla
|
||||
```
|
||||
|
||||
This will build Nimbus and its dependencies, and connect you to the Medalla testnet.
|
||||
You should see that the beacon node has launched with your validator attached:
|
||||
|
||||
```
|
||||
WRN 2020-08-03 16:24:17.950+02:00 Validator not in registry (yet?) topics="beacval" tid=11677993 file=validator_duties.nim:53 pubKey=a9c4df36
|
||||
INF 2020-08-03 16:24:17.951+02:00 Local validator attached tid=11677993 file=validator_pool.nim:21 pubKey=a9c4df36 validator=a9c4df36
|
||||
INF 2020-08-03 16:24:17.951+02:00 Local validators attached topics="beacval" tid=11677993 file=validator_duties.nim:61 count=1
|
||||
INF 2020-08-03 16:24:17.958+02:00 Starting beacon node topics="beacnde" tid=11677993 file=beacon_node.nim:875 version="0.5.0 (31b33907)" nim="Nim Compiler Version 1.2.6 [MacOSX: amd64] (bf320ed1)" timeSinceFinalization=81350 head=ebe49843:0 finalizedHead=ebe49843:0 SLOTS_PER_EPOCH=32 SECONDS_PER_SLOT=12 SPEC_VERSION=0.12.2 dataDir=build/data/shared_medalla_0 pcs=start_beacon_node
|
||||
```
|
||||
|
||||
> **Note:** when you run `make medalla`, the beacon node launches with an Infura endpoint supplied by us. This endpoint is passed through the `web3-url` option (which takes as input the url of the web3 server from which you'd like to observe the eth1 chain).
|
||||
>
|
||||
> Because Infura caps the requests per endpoint per day to 100k, and all Nimbus nodes use the same Infura endpoint by default, it can happen that our Infura endpoint is overloaded (i.e the requests on a given day reach the 100k limit). If this happens, all requests to Infura using the default endpoint will fail, which means your node will stop processing new deposits.
|
||||
>
|
||||
> To pass in your own Infura endpoint, you'll need to run:
|
||||
>```
|
||||
> make NODE_PARAMS="--web3-url=<YOUR_WEBSOCKET_ENDPOINT>" medalla
|
||||
>```
|
||||
> Importantly, the endpoint must be a websocket (`wss`) endpoint, not `https`. If you're not familiar with Infura, we recommend reading through our [Infura guide](./infura-guide), first.
|
||||
>
|
||||
> P.S. We are well aware that Infura is less than ideal from a decentralisation perspective. As such we are in the process of changing our default to [Geth](https://geth.ethereum.org/docs/install-and-build/installing-geth) (with Infura as a fallback). For some rough notes on how to use Geth with Nimbus, see [here](https://gist.github.com/onqtam/aaf883d46f4dab1311ca9c160df12fe4) (we will be adding more complete instructions very soon).
|
||||
|
||||
|
||||
> **Tip:** to 🎨 on the [graffitwall](https://medalla.beaconcha.in/graffitiwall), pass the graffiti parameter like this:
|
||||
>```
|
||||
>make NODE_PARAMS="--graffiti='<YOUR_GRAFFITI>'" medalla
|
||||
|
||||
For a more complete list of the options available, see [here](./advanced.md).
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Generating your keys with NBC
|
||||
# Generate your keys with Nimbus
|
||||
|
||||
In this chapter, we'll take you through how to create an [EIP-2386](https://github.com/ethereum/EIPs/blob/4494da0966afa7318ec0157948821b19c4248805/EIPS/eip-2386.md) wallet to help you generate your validator keys (keystores), create a `deposits_data` file compatible with the Ethereum Foundation's [Validator Launchpad](https://medalla.launchpad.ethereum.org/), and use the launchpad to send this data to the eth1 network so that your validator can be registered.
|
||||
On this page, we'll take you through how to create an [EIP-2386](https://github.com/ethereum/EIPs/blob/4494da0966afa7318ec0157948821b19c4248805/EIPS/eip-2386.md) wallet to help you generate your validator keys (keystores), create a `deposits_data` file compatible with the Ethereum Foundation's [Validator Launchpad](https://medalla.launchpad.ethereum.org/), and use the launchpad to send this data to the eth1 network so that your validator can be registered.
|
||||
|
||||
|
||||
> **Note:** this page is primarily aimed at users who wish to run multiple validators on several machines. If you simply wish to get one validator up and running with Nimbus, or run several validators on a single machine, we recommend following our [become a Medalla validator](./medalla.md) guide instead.
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
# Make a deposit
|
||||
|
||||
The easiest way to get your deposit in is to follow the Ethereum Foundation's launchpad instructions here:
|
||||
|
||||
[https://medalla.launchpad.ethereum.org/](https://zinken.launchpad.ethereum.org/)
|
||||
|
||||
You may notice that there have been considerable improvements to the launchpad process since the summer.
|
||||
|
||||
In particular, the Key Generation section is now much clearer, and you no longer have to install dependencies to get the command line app working.
|
||||
|
||||
|
||||
|
||||
We won't elaborate on each individual step here, since they are well explained on the site itself. However, there are two points of note:
|
||||
|
||||
## 1. Eth1 connection
|
||||
|
||||
|
||||
In the `Select Client` section you'll first be asked to choose an eth1 client. You need to run an eth1 client in order to process incoming validator deposits from the eth1 chain.
|
||||
|
||||
|
||||
|
||||
We recommend you choose `Go Ethereum` (or `Geth`).
|
||||
|
||||
## 2. Block explorer
|
||||
Once you've sent off your transaction, you should see the following screen.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
We recommend you click on `Beaconchain`. This will open up a window that allows you to keep track of your validator's status.
|
||||
|
||||
|
||||
|
||||
It's a good idea to bookmark this page.
|
||||
|
||||
## A note on expected waiting time (the queue)
|
||||
Once you send off your transaction(s), your validator will be put in a queue based on deposit time, and will getting through the queue may take a few hours or days (assuming the chain is finalising).
|
||||
|
||||
|
|
@ -0,0 +1,146 @@
|
|||
# For Developers
|
||||
|
||||
Latest updates happen in the `devel` branch which is merged into `master` every week on Tuesday.
|
||||
|
||||
This page contains tips and tricks for developers, further resources, along with information on how to set up your build environment on your platform.
|
||||
|
||||
### Ubuntu guide
|
||||
|
||||
See [this excellent resource](https://medium.com/@SomerEsat/guide-to-staking-on-ethereum-2-0-ubuntu-medalla-nimbus-5f4b2b0f2d7c) for detailed step-by-step guide on how to stake on eth2 with Ubuntu.
|
||||
|
||||
It contains instructions on how to:
|
||||
|
||||
- Configure a newly running Ubuntu server instance
|
||||
- Configure and run an eth1 node as a service
|
||||
- Compile and configure the Nimbus client for eth 2, phase 0 (Medalla testnet)
|
||||
- Install and configure [Prometheus](https://prometheus.io/) metrics and set up a [Grafana](https://grafana.com/) dashboard
|
||||
|
||||
### Windows dev environment
|
||||
|
||||
Install Mingw-w64 for your architecture using the "[MinGW-W64 Online
|
||||
Installer](https://sourceforge.net/projects/mingw-w64/files/)" (first link
|
||||
under the directory listing). Run it and select your architecture in the setup
|
||||
menu (`i686` on 32-bit, `x86_64` on 64-bit), set the threads to `win32` and
|
||||
the exceptions to "dwarf" on 32-bit and "seh" on 64-bit. Change the
|
||||
installation directory to "C:\mingw-w64" and add it to your system PATH in "My
|
||||
Computer"/"This PC" -> Properties -> Advanced system settings -> Environment
|
||||
Variables -> Path -> Edit -> New -> C:\mingw-w64\mingw64\bin (it's "C:\mingw-w64\mingw32\bin" on 32-bit)
|
||||
|
||||
Install [Git for Windows](https://gitforwindows.org/) and use a "Git Bash" shell to clone and build nimbus-eth2.
|
||||
|
||||
If you don't want to compile PCRE separately, you can fetch pre-compiled DLLs with:
|
||||
|
||||
```bash
|
||||
mingw32-make # this first invocation will update the Git submodules
|
||||
mingw32-make fetch-dlls # this will place the right DLLs for your architecture in the "build/" directory
|
||||
```
|
||||
|
||||
You can now follow the instructions in this this book by replacing `make` with `mingw32-make` (you should run `mingw32` regardless of whether you're running 32-bit or 64-bit architecture):
|
||||
|
||||
```bash
|
||||
mingw32-make test # run the test suite
|
||||
```
|
||||
|
||||
### Linux, macOS
|
||||
|
||||
After cloning the repo:
|
||||
|
||||
```bash
|
||||
# Build beacon_node and all the tools, using 4 parallel Make jobs
|
||||
make -j4
|
||||
|
||||
# Run tests
|
||||
make test
|
||||
|
||||
# Update to latest version
|
||||
git pull
|
||||
make update
|
||||
```
|
||||
|
||||
To run a command that might use binaries from the Status Nim fork:
|
||||
|
||||
```bash
|
||||
./env.sh bash # start a new interactive shell with the right env vars set
|
||||
which nim
|
||||
nim --version # Nimbus is tested and supported on 1.0.2 at the moment
|
||||
|
||||
# or without starting a new interactive shell:
|
||||
./env.sh which nim
|
||||
./env.sh nim --version
|
||||
```
|
||||
|
||||
### Raspberry Pi
|
||||
|
||||
We recommend you remove any cover or use a fan; the Raspberry Pi will get hot (85°C) and throttle.
|
||||
|
||||
- Raspberry PI 3b+ or Raspberry Pi 4b.
|
||||
- 64gb SD Card (less might work too, but the default recommended 4-8GB will probably be too small)
|
||||
- [Raspbian Buster Lite](https://www.raspberrypi.org/downloads/raspbian/) - Lite version is enough to get going and will save some disk space!
|
||||
|
||||
Assuming you're working with a freshly written image:
|
||||
|
||||
```bash
|
||||
|
||||
# Start by increasing swap size to 2gb:
|
||||
sudo vi /etc/dphys-swapfile
|
||||
# Set CONF_SWAPSIZE=2048
|
||||
# :wq
|
||||
sudo reboot
|
||||
|
||||
# Install prerequisites
|
||||
sudo apt-get install git libgflags-dev libsnappy-dev libpcre3-dev
|
||||
|
||||
# Then you can follow instructions for Linux.
|
||||
|
||||
```
|
||||
|
||||
### Makefile tips and tricks for developers
|
||||
|
||||
- build all those tools known to the Makefile:
|
||||
|
||||
```bash
|
||||
# $(nproc) corresponds to the number of cores you have
|
||||
make -j$(nproc)
|
||||
```
|
||||
|
||||
- build a specific tool:
|
||||
|
||||
```bash
|
||||
make state_sim
|
||||
```
|
||||
|
||||
- you can control the Makefile's verbosity with the V variable (defaults to 0):
|
||||
|
||||
```bash
|
||||
make V=1 # verbose
|
||||
make V=2 test # even more verbose
|
||||
```
|
||||
|
||||
- same for the [Chronicles log level](https://github.com/status-im/nim-chronicles#chronicles_log_level):
|
||||
|
||||
```bash
|
||||
make LOG_LEVEL=DEBUG bench_bls_sig_agggregation # this is the default
|
||||
make LOG_LEVEL=TRACE beacon_node # log everything
|
||||
```
|
||||
|
||||
- pass arbitrary parameters to the Nim compiler:
|
||||
|
||||
```bash
|
||||
make NIMFLAGS="-d:release"
|
||||
```
|
||||
|
||||
- you can freely combine those variables on the `make` command line:
|
||||
|
||||
```bash
|
||||
make -j$(nproc) NIMFLAGS="-d:release" USE_MULTITAIL=yes eth2_network_simulation
|
||||
```
|
||||
|
||||
- don't use the [lightweight stack tracing implementation from nim-libbacktrace](https://github.com/status-im/nimbus-eth2/pull/745):
|
||||
|
||||
```bash
|
||||
make USE_LIBBACKTRACE=0 # expect the resulting binaries to be 2-3 times slower
|
||||
```
|
||||
|
||||
### Multi-client interop scripts
|
||||
|
||||
[This repository](https://github.com/eth2-clients/multinet) contains a set of scripts used by the client implementation teams to test interop between the clients (in certain simplified scenarios). It mostly helps us find and debug issues.
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
# Graffiti
|
||||
|
||||
*Todo*
|
||||
```
|
||||
make NODE_PARAMS="--graffiti='<YOUR_GRAFFITI>'" medalla
|
||||
```
|
||||
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Installation
|
||||
# Install dependencies
|
||||
|
||||
The Nimbus beacon chain can run on Linux, macOS, Windows, and Android. At the moment, Nimbus has to be built from source.
|
||||
The Nimbus beacon chain can run on Linux, macOS, Windows, and Android. At the moment, Nimbus has to be built from source, which means you'll need to install some dependencies.
|
||||
|
||||
## Time
|
||||
|
||||
|
|
@ -65,6 +65,3 @@ Assuming you use Ubuntu PRoot
|
|||
apt install build-essential git libpcre3-dev
|
||||
```
|
||||
|
||||
## Next steps
|
||||
|
||||
You're now ready to move on to running a validator.
|
||||
|
|
|
|||
|
|
@ -2,13 +2,12 @@
|
|||
|
||||
The Nimbus beacon chain is a research implementation of the Beacon Chain – the core system level chain at the heart of Ethereum 2.0.
|
||||
|
||||
|
||||
- Open sourced at [github.com/status-im/nimbus-eth2](https://github.com/status-im/nimbus-eth2/tree/master)
|
||||
|
||||
- Specification described at [ethereum/eth2.0-specs](https://github.com/ethereum/eth2.0-specs/tree/v1.0.0-rc.0#phase-0)
|
||||
|
||||
This book strives to achieve two purposes: 1) to attempt to provide a more or less complete documentation of the Nimbus beacon chain, and 2) to explain the various ways in which you can use Nimbus to become a validator on eth2.
|
||||
|
||||
### Helpful resources
|
||||
|
||||
- [nimbus-eth2 repository](github.com/status-im/nimbus-eth2)
|
||||
- [eth2 specification](https://github.com/ethereum/eth2.0-specs/tree/v1.0.0-rc.0#phase-0)
|
||||
- [Ben Edgington's annotated spec](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)
|
||||
|
||||
- [Vitalik's annotated spec](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md)
|
||||
|
|
@ -16,32 +15,13 @@ The Nimbus beacon chain is a research implementation of the Beacon Chain – the
|
|||
- [Danny Ryan's annotated spec](https://notes.ethereum.org/@djrtwo/Bkn3zpwxB)
|
||||
|
||||
|
||||
## Overview
|
||||
|
||||
In this book, we will cover:
|
||||
|
||||
1. An [introduction](./intro.md#introduction) to the beacon chain, eth2, and Nimbus to equip you with some basic knowledge
|
||||
2. [Installation steps](./install.md) outlining the prerequisites to get started
|
||||
3. How to [become a Zinken validator](./zinken.md)
|
||||
4. How to [become a Medalla validator](./medalla.md)
|
||||
5. [Troubleshooting Medalla](./medalla-troubleshooting.md)
|
||||
6. How to [run the beacon node](./beacon_node.md) software to sync the beacon chain
|
||||
7. How to spin up a [beautiful monitoring dashboard](./metrics-pretty-pictures.md) for your validator
|
||||
8. The [API](./api.md) for monitoring your node
|
||||
9. [Advanced usage](./advanced.md) for developers
|
||||
10. How to [setup up a systemd service](./beacon_node_systemd.md)
|
||||
11. How to [use Nimbus to generate your validator keys](./create_wallet_and_deposit.md)
|
||||
12. How to [supply your own Infura endpoint](./infura-guide)
|
||||
13. Tips and tricks for windows users (WIP)
|
||||
14. Common [questions and answers](./faq.md) to satisfy your curiosity
|
||||
15. How to [contribute](./contribute.md) to this book
|
||||
|
||||
|
||||
## Introduction
|
||||
|
||||
### What's the Beacon Chain?
|
||||
|
||||
In short, the beacon chain is the brain underpinning eth2 -- the next generation of Ethereum. It contains all of the machinery behind eth2's consensus.
|
||||
The beacon chain is the brain underpinning eth2 -- the next generation of Ethereum. It contains all of the machinery behind eth2's consensus.
|
||||
|
||||
You can find a complete introduction to the beacon chain in our [Ethereum 2.0 blog series](https://our.status.im/two-point-oh-the-beacon-chain/).
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,54 @@
|
|||
# Keep an eye on your validator
|
||||
|
||||
If you deposit after the [genesis](https://hackmd.io/@benjaminion/genesis) state was decided, your validator(s) will be put in a queue based on deposit time, and will slowly be inducted into the validator set after genesis. Getting through the queue may take a few hours or a day or so.
|
||||
|
||||
The best way to keep track of your validator's status is [medalla.beaconcha.in](https:/medalla.beaconcha.in) (click on the orange magnifying glass at the very top and paste in your validator's public key).
|
||||
|
||||
You can even [create an account](https://medalla.beaconcha.in/register) to add alerts and keep track of your validator's [performance](https://medalla.beaconcha.in/dashboard).
|
||||
|
||||
## Make sure your validator is attached
|
||||
|
||||
On startup, you should see a log message that reads `Local validators attached`. This has a `count` field which should correctly reflect the number of validators you wish to run.
|
||||
|
||||
```
|
||||
{"lvl":"NOT","ts":"2020-10-26 10:16:51.365+00:00","msg":"Local validators attached ","topics":"beacval","tid":12291,"file":"validator_duties.nim:65","count":1}
|
||||
```
|
||||
*In the above case, the `count` field reads `1`, which means 1 validator has successfully attached to the beacon node.*
|
||||
|
||||
## Keep track of your syncing progress
|
||||
|
||||
To keep track of your syncing progress, have a look at the output at the very bottom of the terminal window in which your validator is running. You should see something like:
|
||||
|
||||
```
|
||||
peers: 35 ❯ finalized: ada7228a:8765 ❯ head: b2fe11cd:8767:2 ❯ time: 9900:7 (316807) ❯ sync: wPwwwwwDwwDPwPPPwwww:7:4.0627 (280512)
|
||||
```
|
||||
|
||||
Where:
|
||||
- `peers` tells you how many peers you're currently connected to (in the above case, 35 peers)
|
||||
- `finalized` tells you the most recent finalized epoch you've synced to so far (the 8765th epoch)
|
||||
- `head` tells you the most recent slot you've synced to so far (the 2nd slot of the 8767th epoch)
|
||||
- `time` tells you the current time since Genesis (the 7th slot of the 9900th epoch -- or equivalently, the 316,807th slot)
|
||||
- `sync` tells you how fast you're syncing (4.0627 blocks per second), how many blocks you've synced so far (280,512), along with information about 20 sync workers linked to the 20 most performant peers you are currently connected to (represented by a string of letters and a number).
|
||||
|
||||
To dig into `sync` a little:
|
||||
```
|
||||
sync: <sync worker map>:<number of active workers>:<current syncing speed in blocks/second>
|
||||
```
|
||||
|
||||
The string of letters -- what we call the `sync worker map` (in the above case represented by `wPwwwwwDwwDPwPPPwwww`) represents the status of the sync workers mentioned above, where:
|
||||
|
||||
```
|
||||
s - sleeping (idle),
|
||||
w - waiting for a peer from PeerPool,
|
||||
R - requesting blocks from peer
|
||||
D - downloading blocks from peer
|
||||
P - processing/verifying blocks
|
||||
U - updating peer's status information
|
||||
```
|
||||
|
||||
The number following it (in the above case represented by `7`) represents the number of workers that are currently active (i.e not sleeping or waiting for a peer).
|
||||
|
||||
## eth2stats
|
||||
<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Zinken eth2stats is up!<a href="https://t.co/3LsvmN3NXN">https://t.co/3LsvmN3NXN</a><br><br>One good pre-genesis check is to query your local node's API to see if you have peers (you should!)<br><br>If you hook up to eth2stats, you can easily monitor this metric from anywhere 👀</p>— dannyryan (@dannyryan) <a href="https://twitter.com/dannyryan/status/1314280942651858945?ref_src=twsrc%5Etfw">October 8, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
|
||||
|
||||
*Todo*
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
# Keep your validator updated
|
||||
|
||||
Make sure you stay on the lookout for any critical updates to Nimbus. This best way to do so is through the **announcements** channel on our [discord](https://discord.com/invite/XRxWahP).
|
||||
|
||||
To update to the latest version, disconnect from medalla and run:
|
||||
|
||||
```
|
||||
git pull && make update
|
||||
```
|
||||
|
||||
Once the update is complete, run `make medalla` to reconnect to the network.
|
||||
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
# Manage your keys
|
||||
|
||||
## Import
|
||||
|
||||
To import your signing key(s) into Nimbus, from the `nimbus-eth2` directory run:
|
||||
|
||||
```
|
||||
build/beacon_node deposits import --data-dir=build/data/shared_medalla_0 <YOUR VALIDATOR KEYS DIRECTORY>
|
||||
```
|
||||
|
||||
|
||||
Replacing `<YOUR VALIDATOR KEYS DIRECTORY>` with the full pathname of the `validator_keys` directory that was created when you generated your keys using the [Medalla Launchpad](https://medalla.launchpad.ethereum.org/) [command line app](https://github.com/ethereum/eth2.0-deposit-cli/releases/).
|
||||
|
||||
> **Tip:** run `pwd` in your `validator_keys` directory to print the full pathname to the console.
|
||||
|
||||
You'll be asked to enter the password you created to encrypt your keystore(s).
|
||||
|
||||
Don't worry, this is entirely normal. Your validator client needs both your signing keystore(s) and the password encrypting it to import your [key](https://blog.ethereum.org/2020/05/21/keys/) (since it needs to decrypt the keystore in order to be able to use it to sign on your behalf).
|
||||
|
||||
## Storage
|
||||
|
||||
When you import your keys into Nimbus, your validator signing key(s) are stored in the `build/data/shared_medalla_0/` folder, under `secrets` and `validators` - **make sure you keep these folders backed up somewhere sage.**
|
||||
|
||||
The `secrets` folder contains the common secret that gives you access to all your validator keys.
|
||||
|
||||
The `validators` folder contains your signing keystore(s) (encrypted keys). Keystores are used by validators as a method for exchanging keys. For more on keys and keystores, see [here](https://blog.ethereum.org/2020/05/21/keys/).
|
||||
|
||||
>**Note:** The Nimbus client will only ever import your signing key -- in any case, if you used the deposit launchpad, this is the only key you should have (thanks to the way these keys are derived, you can generate the withdrawal key from your mnemonic whenever you wish to withdraw).
|
||||
|
||||
## Export
|
||||
|
||||
*Todo*
|
||||
|
|
@ -14,7 +14,7 @@ The easiest way to see metrics concerning your validator / node is to run the be
|
|||
make NIMFLAGS="-d:insecure" medalla
|
||||
```
|
||||
|
||||
> **Note:** this flag is needed because we consider the HTTP server that needs to start to serve the metrics to be insecure (without this flag it won't launch properly). As such, we recommend you make sure port 8008 is protected.
|
||||
> **Note:** Metrics are not included in the binary by default. The `NIMFLAGS="-d:insecure"` is needed because we consider the HTTP server that needs to start to serve the metrics to be insecure (without this flag it won't launch properly). As such, we recommend you make sure port 8008 is protected.
|
||||
|
||||
|
||||
Now visit [http://127.0.0.1:8008/metrics](http://127.0.0.1:8008/metrics) to see the raw metrics. You should see a plaintext page that looks something like this:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,369 @@
|
|||
# Validating with a Raspberry Pi
|
||||
|
||||
<blockquote class="twitter-tweet"><p lang="en" dir="ltr">I expect the new Raspberry Pi 4 (4GB RAM option, external SSD) to handle an Eth2 validator node without breaking a sweat. That's $100 of hardware running at 10 Watts to support a 32 ETH node (currently ~$10K stake).</p>— Justin Ðrake (@drakefjustin) <a href="https://twitter.com/drakefjustin/status/1143091047058366465?ref_src=twsrc%5Etfw">June 24, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
|
||||
|
||||
## Introduction
|
||||
This page will take you through how to use your laptop to program your Raspberry Pi, get Nimbus running, and connect to the Medalla testnet (if this is not something you plan on doing, feel free to [skip ahead](./keep-an-eye.md)).
|
||||
|
||||
One of the most important aspects of the Raspberry Pi experience is trying to make it as easy as possible to get started. As such, we try our best to explain things from first-principles.
|
||||
|
||||
## Prerequisites
|
||||
- Raspberry Pi 4 (4GB RAM option)
|
||||
- 64GB microSD Card
|
||||
- microSD USB adapter
|
||||
- 5V 3A USB-C charger
|
||||
- Reliable Wifi connection
|
||||
- Laptop
|
||||
- Basic understanding of the [command line](https://www.learnenough.com/command-line-tutorial/basics)
|
||||
|
||||
### 1. Download Raspberry Pi Imager
|
||||
|
||||
[Raspberry Pi Imager](https://www.raspberrypi.org/blog/raspberry-pi-imager-imaging-utility/) is a new imaging utility that makes it simple to manage your microSD card with Raspbian (the free Pi operating system based on Debian).
|
||||
|
||||
You can find the [download](https://www.learnenough.com/command-line-tutorial/basics) link for your operating system here: [Windows](https://downloads.raspberrypi.org/imager/imager_1.4.exe), [macOS](https://downloads.raspberrypi.org/imager/imager_1.4.dmg), [Ubuntu](https://downloads.raspberrypi.org/imager/imager_1.4_amd64.deb).
|
||||
|
||||
|
||||
### 2. Plug in SD card
|
||||
Use your microSD to USB adapter to plug the SD card into your computer.
|
||||
|
||||
|
||||
### 3. Download Raspberry Pi OS
|
||||
|
||||
Open Raspberry Pi Imager and click on **CHOOSE OS**
|
||||
|
||||
|
||||
|
||||
Select **Raspberry Pi OS (other)**
|
||||
|
||||
|
||||
|
||||
Select **Raspberry Pi OS Lite (32-bit)**
|
||||
|
||||
|
||||
|
||||
|
||||
### 4. Write to SD card
|
||||
|
||||
|
||||
Click on **CHOOSE SD CARD**
|
||||
|
||||
|
||||
|
||||
You should see a menu pop-up with your SD card listed -- Select it
|
||||
|
||||
|
||||
|
||||
Click on **WRITE**
|
||||
|
||||
|
||||
|
||||
Click **YES**
|
||||
|
||||
|
||||
|
||||
Make a cup of coffee :)
|
||||
|
||||
|
||||
### 5. Set up wireless LAN
|
||||
|
||||
Since you have loaded Raspberry Pi OS onto a blank SD card, you will have two partitions. The first one, which is the smaller one, is the `boot` partition.
|
||||
|
||||
Create a `wpa_supplicant` configuration file in the `boot` partition with the following content:
|
||||
|
||||
```
|
||||
# wpa_supplicant.conf
|
||||
|
||||
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
|
||||
update_config=1
|
||||
country=<Insert 2 letter ISO 3166-1 country code here>
|
||||
|
||||
network={
|
||||
ssid="<Insert your Wifi network's name here>"
|
||||
psk="<Insert your Wifi network's password here>"
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
> **Note:** Don't forget to replace the placeholder `country`, `ssid`, and `psk` values. See [Wikipedia](https://en.wikipedia.org/wiki/ISO_3166-1) for a list of 2 letter `ISO 3166-1` country codes.
|
||||
|
||||
|
||||
|
||||
### 6. Enable SSH (using Linux or macOS)
|
||||
|
||||
You can [access the command line](https://www.raspberrypi.org/documentation/remote-access/ssh/) of a Raspberry Pi remotely from another computer or device on the same network using [SSH](https://en.wikipedia.org/wiki/Ssh_(Secure_Shell)).
|
||||
|
||||
While SSH is not enabled by default, you can enable it by placing a file named `ssh`, without any extension, onto the boot partition of the SD card.
|
||||
|
||||
When the Pi boots, it will look for the `ssh` file. If it is found, SSH is enabled and the file is deleted. The content of the file does not matter; it can contain text, or nothing at all.
|
||||
|
||||
To create an empty `ssh` file, from the home directory of the `boot` partition file, run:
|
||||
|
||||
```
|
||||
touch ssh
|
||||
```
|
||||
|
||||
### 7. Find your Pi's IP address
|
||||
|
||||
Since Raspberry Pi OS supports [Multicast_DNS](https://en.wikipedia.org/wiki/Multicast_DNS) out of the box, you can reach your Raspberry Pi by using its hostname and the `.local` suffix.
|
||||
|
||||
The default hostname on a fresh Raspberry Pi OS install is `raspberrypi`, so any Raspberry Pi running Raspberry Pi OS should respond to:
|
||||
|
||||
|
||||
```
|
||||
ping raspberrypi.local
|
||||
```
|
||||
|
||||
The output should look more or less as follows:
|
||||
|
||||
```
|
||||
PING raspberrypi.local (195.177.101.93): 56 data bytes
|
||||
64 bytes from 195.177.101.93: icmp_seq=0 ttl=64 time=13.272 ms
|
||||
64 bytes from 195.177.101.93: icmp_seq=1 ttl=64 time=16.773 ms
|
||||
64 bytes from 195.177.101.93: icmp_seq=2 ttl=64 time=10.828 ms
|
||||
...
|
||||
```
|
||||
|
||||
Keep note of your Pi's IP address. In the above case, that's `195.177.101.93`
|
||||
|
||||
|
||||
### 8. SSH (using Linux or macOS)
|
||||
|
||||
Connect to your Pi by running:
|
||||
|
||||
```
|
||||
ssh pi@195.177.101.93
|
||||
```
|
||||
|
||||
You'll be prompted to enter a password:
|
||||
```
|
||||
pi@195.177.101.93's password:
|
||||
```
|
||||
|
||||
Enter the Pi's default password: `raspberry`
|
||||
|
||||
You should see a message that looks like the following:
|
||||
```
|
||||
Linux raspberrypi 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l
|
||||
|
||||
The programs included with the Debian GNU/Linux system are free software;
|
||||
the exact distribution terms for each program are described in the
|
||||
individual files in /usr/share/doc/*/copyright.
|
||||
|
||||
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
|
||||
permitted by applicable law.
|
||||
|
||||
SSH is enabled and the default password for the 'pi' user has not been changed.
|
||||
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.
|
||||
```
|
||||
|
||||
Followed by a command-line prompt indicating a successful connection:
|
||||
|
||||
```
|
||||
pi@raspberrypi:~ $
|
||||
```
|
||||
|
||||
### 9. Increase swap size to 2GB
|
||||
|
||||
The first step is to increase the [swap size](https://itsfoss.com/swap-size/) to 2GB (2048MB).
|
||||
|
||||
> **Note:** Swap acts as a breather to your system when the RAM is exhausted. When the RAM is exhausted, your Linux system uses part of the hard disk memory and allocates it to the running application.
|
||||
|
||||
Use the Pi's built-in text editor [nano](https://www.nano-editor.org/dist/latest/cheatsheet.html) to open up the swap file:
|
||||
|
||||
```
|
||||
sudo nano /etc/dphys-swapfile
|
||||
```
|
||||
|
||||
|
||||
|
||||
Change the value assigned to `CONF_SWAPSIZE` from `100` to `2048`:
|
||||
|
||||
```
|
||||
...
|
||||
|
||||
# set size to absolute value, leaving empty (default) then uses computed value
|
||||
# you most likely don't want this, unless you have an special disk situation
|
||||
CONF_SWAPSIZE=2048
|
||||
|
||||
...
|
||||
|
||||
```
|
||||
|
||||
|
||||
Save (`Ctrl+S`) and exit (`Ctrl+X`).
|
||||
|
||||
### 10. Reboot
|
||||
Reboot your Pi to have the above changes take effect:
|
||||
|
||||
```
|
||||
sudo reboot
|
||||
```
|
||||
|
||||
This will cause your connection to close. So you'll need to `ssh` into your Pi again:
|
||||
|
||||
```
|
||||
ssh pi@195.177.101.93
|
||||
```
|
||||
|
||||
> **Note:** Remember to replace `195.177.101.93` with the IP address of your Pi.
|
||||
|
||||
### 11. Install Nimbus dependencies
|
||||
|
||||
You'll need to install some packages (`git`, `libgflags-dev`, `libsnappy-dev`, and `libpcre3-dev`) in order for Nimbus to run correctly.
|
||||
|
||||
To do so, run:
|
||||
```
|
||||
sudo apt-get install git libgflags-dev libsnappy-dev libpcre3-dev
|
||||
|
||||
```
|
||||
### 12. Install Screen
|
||||
|
||||
`screen` is a tool that lets you safely detach from the SSH session without exiting the remote job. In other words `screen` allows the commands you run on your Pi from your laptop to keep running after you've logged out.
|
||||
|
||||
Run the following command to install `screen`:
|
||||
```
|
||||
sudo apt-get install screen
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 13. Clone the Nimbus repository
|
||||
|
||||
Run the following command to clone the [nimbus-eth2 repository](https://github.com/status-im/nimbus-eth2):
|
||||
|
||||
```
|
||||
git clone https://github.com/status-im/nimbus-eth2
|
||||
```
|
||||
|
||||
|
||||
|
||||
### 14. Build the beacon node
|
||||
|
||||
Change into the directory and build the beacon node.
|
||||
```
|
||||
cd nimbus-eth2
|
||||
make beacon_node
|
||||
```
|
||||
|
||||
*Patience... this may take a few minutes.*
|
||||
|
||||
### 15. Copy signing key over to Pi
|
||||
|
||||
>**Note:** If you haven't generated your validator key(s) and/or made your deposit yet, follow the instructions on [this page](./deposit.md) before carrying on.
|
||||
|
||||
We'll use the `scp` command to send files over SSH. It allows you to copy files between computers, say from your Raspberry Pi to your desktop/laptop, or vice-versa.
|
||||
|
||||
Copy the folder containing your validator key(s) from your computer to your `pi`'s homefolder by opening up a new terminal window and running the following command:
|
||||
|
||||
```
|
||||
scp -r <VALIDATOR_KEYS_DIRECTORY> pi@195.177.101.93:
|
||||
```
|
||||
|
||||
> **Note:** Don't forget the colon (:) at the end of the command!
|
||||
|
||||
As usual, replace `195.177.101.93` with your Pi's IP address, and `<VALIDATOR_KEYS_DIRECTORY>` with the full pathname of your `validator_keys` directory (if you used the Launchpad [command line app](https://github.com/ethereum/eth2.0-deposit-cli/releases/) this would have been created for you when you generated your keys).
|
||||
|
||||
|
||||
> **Tip:** run `pwd` in your `validator_keys` directory to print the full pathname to the console.
|
||||
|
||||
|
||||
|
||||
### 16. Import signing key into Nimbus
|
||||
|
||||
To import your signing key into Nimbus, from the `nimbus-eth2` directory run:
|
||||
|
||||
```
|
||||
build/beacon_node deposits import --data-dir=build/data/shared_medalla_0 ../validator_keys
|
||||
```
|
||||
|
||||
|
||||
|
||||
You'll be asked to enter the password you created to encrypt your keystore(s). Don't worry, this is entirely normal. Your validator client needs both your signing keystore(s) and the password encrypting it to import your [key](https://blog.ethereum.org/2020/05/21/keys/) (since it needs to decrypt the keystore in order to be able to use it to sign on your behalf).
|
||||
|
||||
### 17. Run Screen
|
||||
|
||||
From the `nimbus-eth2` directory, run:
|
||||
```
|
||||
screen
|
||||
```
|
||||
|
||||
You should see output that looks like the following:
|
||||
```
|
||||
GNU Screen version 4.06.02 (GNU) 23-Oct-17
|
||||
|
||||
Copyright (c) 2015-2017 Juergen Weigert, Alexander Naumov, Amadeusz Slawinski
|
||||
Copyright (c) 2010-2014 Juergen Weigert, Sadrul Habib Chowdhury
|
||||
Copyright (c) 2008-2009 Juergen Weigert, Michael Schroeder, Micah Cowan, Sadrul Habib Chowdhury
|
||||
Copyright (c) 1993-2007 Juergen Weigert, Michael Schroeder
|
||||
Copyright (c) 1987 Oliver Laumann
|
||||
|
||||
This program is free software; you can redistribute it and/or modify it under the terms of the GNU
|
||||
General Public License as published by the Free Software Foundation; either version 3, or (at your
|
||||
option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even
|
||||
the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
|
||||
License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License along with this program (see the file
|
||||
COPYING); if not, see http://www.gnu.org/licenses/, or contact Free Software Foundation, Inc., 51
|
||||
Franklin Street, Fifth Floor, Boston, MA 02111-1301 USA.
|
||||
|
||||
Send bugreports, fixes, enhancements, t-shirts, money, beer & pizza to screen-devel@gnu.org
|
||||
|
||||
|
||||
Capabilities:
|
||||
+copy +remote-detach +power-detach +multi-attach +multi-user +font +color-256 +utf8 +rxvt
|
||||
+builtin-telnet
|
||||
```
|
||||
|
||||
Press `Enter` or `Space`.
|
||||
|
||||
### 18. Connect to medalla
|
||||
|
||||
We're finally ready to connect to medalla!
|
||||
|
||||
>**Note:** If you haven't already, we recommend registering for, and running, your own Infura endpoint to connect to eth1. For instruction on how to do so, see [this page](./infura-guide.md).
|
||||
|
||||
To connect to medalla, run:
|
||||
```
|
||||
make NODE_PARAMS="--web3-url=wss://goerli.infura.io/ws/v3/ae1e57122a1e49af8e835e82a5e35e60" medalla
|
||||
```
|
||||
|
||||
Be sure to replace the `web3-url` above with your own websocket (`wss`) Infura endpoint.[^1]
|
||||
|
||||
### 19. Check for successful connection
|
||||
|
||||
If you look near the top of the logs printed to your console, you should see confirmation that your beacon node has started, with your local validator attached:
|
||||
|
||||
```
|
||||
INF 2020-10-07 17:04:09.213+02:00 Initializing networking topics="networking" tid=11688398 file=eth2_network.nim:1335 hostAddress=/ip4/0.0.0.0/tcp/9000 network_public_key=0802122102defb020c8e47dd8f5da89f51ed6c3998aaa0dd59eeb2784e29d47fdbdab69235 announcedAddresses=@[/ip4/195.177.101.93/tcp/9000]
|
||||
WRN 2020-10-07 17:04:09.215+02:00 Ignoring invalid bootstrap address tid=11688398 file=eth2_discovery.nim:45 bootstrapAddr= reason="an empty string is not a valid bootstrap node"
|
||||
NOT 2020-10-07 17:04:09.231+02:00 Local validators attached topics="beacval" tid=11688398 file=validator_duties.nim:65 count=0
|
||||
NOT 2020-10-07 17:04:09.231+02:00 Starting beacon node topics="beacnde" tid=11688398 file=beacon_node.nim:923 version="0.5.0 (1dec860b)" nim="Nim Compiler Version 1.2.6 [MacOSX: amd64] (bf320ed1)" timeSinceFinalization=0ns head=0814b036:0 finalizedHead=0814b036:0 SLOTS_PER_EPOCH=32 SECONDS_PER_SLOT=12 SPEC_VERSION=0.12.3 dataDir=build/data/shared_zinken_0
|
||||
```
|
||||
|
||||
To keep track of your syncing progress, have a look at the output at the very bottom of the terminal window in which your validator is running. You should see something like:
|
||||
|
||||
```
|
||||
peers: 35 ❯ finalized: ada7228a:8765 ❯ head: b2fe11cd:8767:2 ❯ time: 9900:7 (316807) ❯ sync: wPwwwwwDwwDPwPPPwwww:7:4.0627 (280512)
|
||||
```
|
||||
|
||||
Keep an eye on the number of peers your currently connected to (in the above case that's `35`), as well as your [sync progress](./keep-an-eye.md#syncing-progress).
|
||||
|
||||
### 20. End ssh session and logout
|
||||
|
||||
To detach your `screen` session but leave your processes running, press `Ctrl-A` followed by `Ctrl-D`. You can now exit your `ssh` session (`Ctrl-C`) and switch off your laptop.
|
||||
|
||||
Verifying your progress is as simple as `ssh`ing back into your Pi and typing `screen -r`. This will resume your screen session (and you will be able to see your node's entire output since you logged out).
|
||||
|
||||
-------
|
||||
|
||||
[^1]: If you were to just run `make medalla`, the beacon node would launch with an Infura endpoint supplied by us. This endpoint is passed through the `web3-url` option (which takes as input the url of the web3 server from which you'd like to observe the eth1 chain). Because Infura caps the requests per endpoint per day to 100k, and all Nimbus nodes use the same Infura endpoint by default, it can happen that our Infura endpoint is overloaded (i.e the requests on a given day reach the 100k limit). If this happens, all requests to Infura using the default endpoint will fail, which means your node will stop processing new deposits.
|
||||
To pass in your own Infura endpoint, you'll need to run:
|
||||
```
|
||||
make NODE_PARAMS="--web3-url=<YOUR_WEBSOCKET_ENDPOINT>" medalla
|
||||
```
|
||||
Importantly, the endpoint must be a websocket (`wss`) endpoint, not `https`. If you're not familiar with Infura, we recommend reading through our [Infura guide](./infura-guide), first. **P.S.** We are well aware that Infura is less than ideal from a decentralisation perspective. As such we are in the process of changing our default to [Geth](https://geth.ethereum.org/docs/install-and-build/installing-geth) (with Infura as a fallback). For some rough notes on how to use Geth with Nimbus, see [here](https://gist.github.com/onqtam/aaf883d46f4dab1311ca9c160df12fe4) (we will be adding more complete instructions very soon).
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
# Resources
|
||||
|
||||
- [ethstaker discord](https://discord.com/invite/e84CFep): great place for tips and discussions
|
||||
|
||||
- [Validator launchpad](https://medalla.launchpad.ethereum.org): to send Medalla deposits
|
||||
|
||||
- [Beacon chain explorer](https://zinken.beaconcha.in/) : to monitor testnet health
|
||||
|
||||
- [Nimbus discord](https://discord.com/invite/XRxWahP) : best place to ask questions and to stay up-to-date with critical updates
|
||||
|
||||
- [Ethereum on ARM: Raspberry Pi 4 image + tutorial](https://www.reddit.com/r/ethereum/comments/gf3nhg/ethereum_on_arm_raspberry_pi_4_images_release/) : turn your Raspberry Pi 4 into an eth1 or eth2 node just by flashing the MicroSD card
|
||||
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Troubleshooting Medalla
|
||||
# Troubleshooting (Medalla)
|
||||
|
||||
As it stands, we are continuously making improvements to both stability and memory usage. So please make sure you keep your client up to date! This means restarting your node and updating your software regularly from the `master` branch. If you can't find a solution to your problem here, feel free to hit us up on our [discord](https://discord.com/invite/XRxWahP)!
|
||||
|
||||
|
|
@ -1,6 +1,5 @@
|
|||
# Become a Zinken validator
|
||||
|
||||
|
||||
This page will take you through how to import your key(s) and get your validator(s) ready for [Zinken genesis](https://blog.ethereum.org/2020/09/22/eth2-quick-update-no-17/).
|
||||
|
||||
For those of you who are unfamiliar, [Zinken](https://github.com/goerli/medalla/blob/master/zinken/README.md) is a short-lived eth2 testnet that will begin on **Monday, October 12th at 12 UTC** and last for three days or so. Its main objective is to allow us to test the deposit/[genesis](https://hackmd.io/@benjaminion/genesis) flow one more time before mainnet launch.
|
||||
|
|
@ -13,7 +12,7 @@ Although it will mainly be client teams taking part, it's also a chance for you
|
|||
|
||||
This tutorial assumes basic knowledge of the [command line](https://www.learnenough.com/command-line-tutorial/basics#:~:text=Learn%20Enough%20Command%20Line%20to%20Be%20Dangerous%20is%20an%20introduction,broad%20an%20audience%20as%20possible.).
|
||||
|
||||
## 1. Make a deposit
|
||||
## 1. Make a deposit
|
||||
|
||||
The easiest way to get your deposit in is to follow the Launchpad instructions here:
|
||||
|
||||
|
|
@ -80,11 +79,11 @@ This tutorial assumes basic knowledge of the [command line](https://www.learneno
|
|||
If you look near the top of the logs printed to your console, you should see that your beacon node has started, with your local validator attached:
|
||||
|
||||
```
|
||||
INF 2020-10-07 17:04:09.213+02:00 Initializing networking topics="networking" tid=11688398 file=eth2_network.nim:1335 hostAddress=/ip4/0.0.0.0/tcp/9000 network_public_key=0802122102defb020c8e47dd8f5da89f51ed6c3998aaa0dd59eeb2784e29d47fdbdab69235 announcedAddresses=@[/ip4/192.168.11.83/tcp/9000]
|
||||
INF 2020-10-07 17:04:09.213+02:00 Initializing networking topics="networking" tid=11688398 file=eth2_network.nim:1335 hostAddress=/ip4/0.0.0.0/tcp/9000 network_public_key=0802122102defb020c8e47dd8f5da89f51ed6c3998aaa0dd59eeb2784e29d47fdbdab69235 announcedAddresses=@[/ip4/195.177.101.93/tcp/9000]
|
||||
WRN 2020-10-07 17:04:09.215+02:00 Ignoring invalid bootstrap address tid=11688398 file=eth2_discovery.nim:45 bootstrapAddr= reason="an empty string is not a valid bootstrap node"
|
||||
NOT 2020-10-07 17:04:09.231+02:00 Local validators attached topics="beacval" tid=11688398 file=validator_duties.nim:65 count=0
|
||||
NOT 2020-10-07 17:04:09.231+02:00 Starting beacon node topics="beacnde" tid=11688398 file=beacon_node.nim:923 version="0.5.0 (1dec860b)" nim="Nim Compiler Version 1.2.6 [MacOSX: amd64] (bf320ed1)" timeSinceFinalization=0ns head=0814b036:0 finalizedHead=0814b036:0 SLOTS_PER_EPOCH=32 SECONDS_PER_SLOT=12 SPEC_VERSION=0.12.3 dataDir=build/data/shared_zinken_0
|
||||
peers: 0 ❯ finalized: 0814b036:0 ❯ head: 0814b036:0:0 ❯ time: 387:2 (12386) INF 2020-10-07 17:04:09.232+02:00 Starting discovery node topics="discv5" tid=11688398 file=protocol.nim:799 node=Node[192.168.11.83:9000] uri=enr:-LK4QCje1Tb8tPIjuIWcAjVRprALNr-fGSmX0ijk2nt4-BgTRSG_q2oekHW9IxbdRi-bcT9RsppI7JtjIxjkm-dG9ZwBh2F0dG5ldHOI__________-EZXRoMpCEe0P1AAAAA___________gmlkgnY0gmlwhMCoC1OJc2VjcDI1NmsxoQLe-wIMjkfdj12on1HtbDmYqqDdWe6yeE4p1H_b2raSNYN0Y3CCIyiDdWRwgiMo bindAddress=0.0.0.0:9000
|
||||
peers: 0 ❯ finalized: 0814b036:0 ❯ head: 0814b036:0:0 ❯ time: 387:2 (12386) INF 2020-10-07 17:04:09.232+02:00 Starting discovery node topics="discv5" tid=11688398 file=protocol.nim:799 node=Node[195.177.101.93:9000] uri=enr:-LK4QCje1Tb8tPIjuIWcAjVRprALNr-fGSmX0ijk2nt4-BgTRSG_q2oekHW9IxbdRi-bcT9RsppI7JtjIxjkm-dG9ZwBh2F0dG5ldHOI__________-EZXRoMpCEe0P1AAAAA___________gmlkgnY0gmlwhMCoC1OJc2VjcDI1NmsxoQLe-wIMjkfdj12on1HtbDmYqqDdWe6yeE4p1H_b2raSNYN0Y3CCIyiDdWRwgiMo bindAddress=0.0.0.0:9000
|
||||
```
|
||||
|
||||
> **Note:** when you run `make zinken`, the beacon node launches with an Infura endpoint supplied by us. This endpoint is passed through the `web3-url` option (which takes as input the url of the web3 server from which you'd like to observe the eth1 chain).
|
||||
|
|
@ -100,7 +99,7 @@ NOT 2020-10-07 17:04:09.231+02:00 Starting beacon node top
|
|||
> P.S. We are well aware that Infura is less than ideal from a decentralisation perspective. As such we are in the process of changing our default to [Geth](https://geth.ethereum.org/docs/install-and-build/installing-geth) (with Infura as a fallback). For some rough notes on how to use Geth with Nimbus, see [here](https://gist.github.com/onqtam/aaf883d46f4dab1311ca9c160df12fe4) (we will be adding more complete instructions very soon).
|
||||
|
||||
|
||||
## 4. Keep an eye on your validator
|
||||
## 4. Keep an eye on your validator
|
||||
|
||||
If you deposit after the [genesis](https://hackmd.io/@benjaminion/genesis) state was decided (October 8th, 12pm UTC), your validators will be put in a queue based on deposit time, and will slowly be inducted into the validator set after genesis. Getting through the queue may take a few hours or a day or so.
|
||||
|
||||
|
|
@ -134,7 +133,7 @@ NOT 2020-10-07 17:04:09.231+02:00 Starting beacon node top
|
|||
|
||||
>**Note:** The Nimbus client will only ever import your signing key -- in any case, if you used the deposit launchpad, this is the only key you should have (thanks to the way these keys are derived, you can generate the withdrawal key from your mnemonic whenever you wish to withdraw).
|
||||
|
||||
## Metrics
|
||||
## Metrics
|
||||
|
||||
Metrics are not included in the binary by default - to enable them, use the following options when starting the client:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue