status-im
/
nimbus-eth2
mirror of https://github.com/status-im/nimbus-eth2.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update systemd page and delete old files (#2200) 

* remove old pages

* update systemd file and move it to how-to's
This commit is contained in:
Sacha Saint-Leger 2020-12-21 10:04:46 +01:00 committed by GitHub
parent 6c8f630170
commit a1ba188de3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
7 changed files with 6 additions and 809 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/the_nimbus_book/src/SUMMARY.md
View File

@ -26,10 +26,10 @@
- [Recover / generate keys](./more-keys.md)
- [Migrate keys to another machine]()
- [Perform a voluntary exit](./voluntary-exit.md)
- [Setup a systemd service](./beacon-node-systemd.md)
# Tutorials
- [Grafana and Prometheus](./metrics-pretty-pictures.md)
- [Setup a systemd service](./beacon-node-systemd.md)
- [Create your own Infura endpoint](./infura-guide.md)
- [Switch between clients]()
- [Network stats (testnets only)](./eth2-stats.md)

58
docs/the_nimbus_book/src/advanced.md
View File

@ -1,58 +0,0 @@
# Advanced options
### Start multiple nodes
You can start multiple local nodes, in different terminal windows/tabs, by specifying numeric IDs:
```
make medalla NODE_ID=0 # the default
make medalla NODE_ID=1
make medalla NODE_ID=2
```
### Attach multiple validators to the same beacon node
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 may need to do this if you are running another client.
### 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
```
>**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
```
make medalla-deposit VALIDATORS=2 # default is just 1
```

31
docs/the_nimbus_book/src/beacon-node-systemd.md
View File

@ -1,33 +1,12 @@
# Set up a systemd service
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
Systemd is used in order to have a command or program run when your device boots (i.e. add it as a service). Once this is done, you can start/stop enable/disable from the linux prompt.
NBC's [external dependencies](./install.md#external-dependencies).
> [`systemd`](https://www.freedesktop.org/wiki/Software/systemd/) is a service manager designed specifically for Linux. There is no port to Mac OS. You can get more information from [https://www.raspberrypi.org/documentation/linux/usage/systemd.md](https://www.raspberrypi.org/documentation/linux/usage/systemd.md) or [https://fedoramagazine.org/what-is-an-init-system/](https://www.raspberrypi.org/documentation/linux/usage/systemd.md)
### 1. Clone repository
If you haven't done so already, clone the [nimbus-eth2](https://github.com/status-im/nimbus-eth2) repository.
```console
git clone https://github.com/status-im/nimbus-eth2.git
```
### 2. Build repository
Move into the directory and build the beacon node.
```console
cd nimbus-eth2
make nimbus_beacon_node
```
The resulting binaries should appear in `nimbus-eth2/build/nimbus_beacon_node`.
### 3. Create a systemd service unit file
### 1. Create a systemd service
Create a `systemd` service unit file -- `nbc.service` -- and save it in `/etc/systemd/system/`.
@ -61,13 +40,13 @@ Replace:
`<WEB3-URL>` with the WebSocket JSON-RPC URL that you are planning to use.
### 4. Notify systemd of the newly added service
### 2. Notify systemd of the newly added service
```console
sudo systemctl daemon-reload
```
### 5. Start the service
### 3. Start the service
```console
sudo systemctl enable nbc --now

219
docs/the_nimbus_book/src/beacon-node.md
View File

@ -1,219 +0,0 @@
# 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 nimbus_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=nimbus_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:
```
./nimbus_beacon_node --help
```
You should see the following output:
```
Usage:
nimbus_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:
nimbus_beacon_node 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.
nimbus_beacon_node deposits [OPTIONS]... command
The following options are available:
--deposit-private-key Private key of the controlling (sending) account.
Available sub-commands:
nimbus_beacon_node 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.
nimbus_beacon_node 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).
nimbus_beacon_node deposits status
Displays status information about all deposits.
nimbus_beacon_node wallets command
Available sub-commands:
nimbus_beacon_node 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.
nimbus_beacon_node 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.
nimbus_beacon_node wallets list
Lists details about all wallets.
```

188
docs/the_nimbus_book/src/create-wallet-and-deposit.md
View File

@ -1,188 +0,0 @@
# Generate your keys with Nimbus
> ⚠️ This page concerns the Medalla testnet. DO NOT USE THIS PAGE TO GENERATE KEYS FOR MAINNET. Please use the [Ethereum Foundation's Launchpad](https://launchpad.ethereum.org/) instead.
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 [Medalla 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.
For our purposes, a wallet is the [EIP-2386](https://github.com/ethereum/EIPs/blob/4494da0966afa7318ec0157948821b19c4248805/EIPS/eip-2386.md) JSON file which contains an encrypted seed, a name, and a counter (`nextaccount`) that allows for generating validator keystores incrementally as outlined in [EIP-2334](https://eips.ethereum.org/EIPS/eip-2334) (Deterministic Account Hierarchy). It's sometimes referred to as a walletstore.
Such a wallet can create (and restore) keys from a *seed* and a *path*. The encrypted seed is stored in the wallet (it needs to be accessible to create new keys). Further, the wallet also has a mechanism (a `nextaccount` index) for maintaining state about which keys have been generated (to help ensure you don't duplicate a key by accident).
## When do I need to use a wallet?
If you're asking yourself this question then you probably don't need to use one :)
To be clear, the purpose of such a wallet is to help you generate your keystores (and keep track of how many you've generated). But you don't need a wallet to do this.
> **Tip:** You can use tools like the Ethereum Foundation's [deposit-cli](https://github.com/ethereum/eth2.0-deposit-cli) to generate keystores without a wallet. In fact, we recommend this approach if you're not sure whether or not you need a wallet.
## Prerequisites
You need to have installed Nimbus' [external dependencies](./install.md#external-dependencies) and [built the beacon node](./beacon_node.md#building-the-node).
## 1. Create a wallet
Run the following command from the the home directory of the `nimbus-eth2` repository to launch the command line interface app:
```
build/nimbus_beacon_node wallets create
```
Now follow the instructions presented to you in the terminal window to create your wallet.
```bash
Wallet id: <YOUR_WALLET_ID>
INF 2020-08-18 11:05:47.126+02:00 Wallet file written
tid=137382
file=keystore_management.nim:404
path="<WHERE_YOUR_WALLET_IS_SAVED>"
```
At the end of the process, you should see the above message printed to the terminal. Make sure to keep track of your wallet id, and path.
### Available options
To see a list of the options/flags available, run:
```bash
build/nimbus_beacon_node wallets create --help
```
You should see the following:
```
The following options are available:
--next-account Initial value for the 'nextaccount' property of the wallet.
--name An easy-to-remember name for the wallet of your choice.
--out Output wallet file.
```
## 2. Create a keystore and signed deposit
To generate 1 keystore and create a `deposit_data` JSON file using an existing wallet, run:
```bash
build/nimbus_beacon_node deposits create --wallet="<YOUR_WALLET_ID>" --count=1
```
> **Tip:** To find your wallet id, look at your terminal history. You should see it printed right after you created your wallet. It's also saved in the `uuid` field of your wallet (remember your wallet is simply a JSON file).
Enter your password to unlock your wallet, create your signing keystore, and generate a `deposit_data` file.
```bash
INF 2020-08-19 13:53:24.271+02:00 Generating deposits
tid=330637
file=keystore_management.nim:143
totalValidators=2
validatorsDir=validators
secretsDir=secrets
INF 2020-08-19 13:53:24.286+02:00 Deposit data written
topics="beacnde" tid=330637
file=nimbus_beacon_node.nim:1406
filename=validators/deposit_data-1597838004.284995.json
```
The deposit data file you just created contains a signed deposit (signed by the key you just created). You can find it in the newly created `validators` directory.
In the `validators` directory you should also see a folder with a name that looks something like `0x8c...3ed3a5052e2d`. The name of this folder is your validator's public key. Inside it you'll find your validator's signing keystore -- `keystore.json`.
> **Note:** If you wish to create a new wallet from which to make a deposit (simply run `deposits create` with no extra flags).
### Available options
To see a list of the options/flags available, run:
```bash
build/nimbus_beacon_node deposits create --help
```
You should see the following:
```
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-validators-dir Output folder for validator keystores.
--out-secrets-dir Output folder for randomly generated keystore passphrases.
--out-deposits-file The name of generated deposits file.
--new-wallet-name An easy-to-remember name for the wallet of your choice.
--new-wallet-file Output wallet file.
```
</details>
## 3. Send your deposit transaction(s)
You're now ready to upload your `deposit_data` JSON file along with your signing keystore(s) to the EF's [Validator Launchpad](https://medalla.launchpad.ethereum.org/): it will take you through how to create the necessary transaction(s) to make your deposit(s) and register your validator(s).
>**Note:** Your `deposit_data` file contains a list of all your signed deposits. So even if you have many keystores, you should only have one `deposit_data` file.
0. Make sure you have enough [Goerli ETH](https://faucet.goerli.mudit.blog/) (32 ETH for each validator you wish to run). See [here](create_wallet_and_deposit.md#a-note-on-acquiring-goerli-eth) for how to request Goerli ETH.
1. Go to [https://medalla.launchpad.ethereum.org](https://medalla.launchpad.ethereum.org/)
<img src="https://storage.googleapis.com/ethereum-hackmd/upload_431e6a8ec269404e3f89fec7133482b9.png" width="700">
2. Click on **Get Started**
<img src="https://storage.googleapis.com/ethereum-hackmd/upload_cbe2983e3795cfa57b621ae21b6ba165.png" width="700">
3. Read through the *Overview section* -- making sure you understand the risks and responsibilities involved
<p>
<img width="350" src="https://storage.googleapis.com/ethereum-hackmd/upload_86a7b1e968fe5830cac4a06d4597f221.png">
<img width="350" src="https://storage.googleapis.com/ethereum-hackmd/upload_a630e2ad0e9c5e6c3111dd1fba3c9767.png">
</p>
4. Move on to the *Generate Keys* section to choose how many validators you'd like to run (1 per 32 ETH deposited)
<img src="https://storage.googleapis.com/ethereum-hackmd/upload_0fd4e55870b4b6ce57c80644323b45bd.png" width="700">
5. Scroll to the end of the Key Generation page, tick the box, and click continue
<img src="https://storage.googleapis.com/ethereum-hackmd/upload_10fcb69be02662e10bc4b62c29d8a074.png" width="700">
6. Upload the Deposit data file you generated using Nimbus in the previous step
<img src="https://storage.googleapis.com/ethereum-hackmd/upload_6db4e4c3715a0a80db53bd5f26eb1ffc.png" width="500">
*Remember you can find your `deposit_data` JSON file in the `nimbus-eth2/validators` directory*
</br>
The launchpad will then double check you understand the most important things. And help you send the required transaction(s).
<p>
<img width="350" src="https://storage.googleapis.com/ethereum-hackmd/upload_e2c60ad1c9840d0f2fcf5c4ae8ec284a.png">
<img width="350" src="https://storage.googleapis.com/ethereum-hackmd/upload_0d3c0a5c8cb421041b6847f0c2d24328.png">
</p>
### A note on acquiring Goerli ETH
The easiest way to acquire testnet ETH is to join [Prysmatic Labs' discord](https://discord.com/invite/YMVYzv6) and send a request for ETH in the **#-request-goerli-eth channel**.
```
!send <your metamask goerli network ETH address>
```
You can also use the [Goerli Authenticated Faucet](https://faucet.goerli.mudit.blog/).
## 4. Connect to Medalla
Now that you've generated your keys and registered your validator, the final step is to [connect to Medalla](medalla.md#connect-to-medalla).
### 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).
More technically: approximately every 3.5 hours the eth2 beacon chain receives an "include until X" eth1 block to vote on: this block must be at least 1024 blocks behind the eth1 head. However, can be made anywhere between the start and the end of a voting period, the time you'll need to wait can fluctuate (within a range of 1 or 2 voting periods).

221
docs/the_nimbus_book/src/medalla.md
View File

@ -1,221 +0,0 @@
# Become a Medalla validator
This chapter will take you through how to become a validator on the eth2 testnet [Medalla](https://github.com/goerli/medalla).
If you generated your signing key using the [eth2 launchpad](https://medalla.launchpad.ethereum.org/), and wish to import it into the Nimbus client, this page is for you.
> If you haven't created your validator key yet, we recommend you do so using the [launchpad](https://medalla.launchpad.ethereum.org/). If you're not sure what the eth2 launchpad is, we recommend reading this [introductory post](https://blog.ethereum.org/2020/07/27/eth2-validator-launchpad/) first.
> If you're an advanced user running Ubuntu, we recommend you check out this [excellent and complementary guide](https://medium.com/@SomerEsat/guide-to-staking-on-ethereum-2-0-ubuntu-medalla-nimbus-5f4b2b0f2d7c).
## Prerequisites
> ⚠️ If this is your first time playing with Nimbus, please make sure you [install our external dependencies](./install.md) first.
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.).
## Validating
To start validating on the `medalla` network:
#### 1. Clone the nim beacon chain repository
```
git clone https://github.com/status-im/nimbus-eth2
cd nimbus-eth2
```
#### 2. Build the beacon node
```
make nimbus_beacon_node
```
*Patience... this may take a few minutes.*
#### 3. Import keystore(s)
```
build/nimbus_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 your `validator_keys` directory.
> 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) in the *Generate Keys* section of the Launchpad process. Don't worry, this is entirely normal. Your validator client needs both your keystore(s) and the password encrypting it to import your [keys](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).
#### 4. Connect to Medalla
```
make medalla
```
This will build Nimbus and its dependencies, and connect you to Medalla.
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=nimbus_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
#### 5. Keep an eye on your validator
If you deposited after the [genesis](https://hackmd.io/@benjaminion/genesis) state was decided (August 2nd 1300 UTC), your validators will have been 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 days.
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 its 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).
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).
#### 6. Keep your validator updated
Finally, makes 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.
Looking forward to seeing you on Medalla! 💛
## Key management
Keys are stored in the `build/data/shared_medalla_0/` folder, under `secrets` and `validators` - make sure you keep these folders backed up.
The `secrets` folder contains the common secret that gives you access to all your validator keys.
The `validators` folder contains your keystores (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 (you can generate the withdrawal key from your mnemonic when you wish to withdraw).
## Metrics
Metrics are not included in the binary by default - to enable them, use the following options when starting the client:
```
make NIMFLAGS="-d:insecure" medalla
```
You can then browse the metrics by connecting to:
[http://localhost:8008/metrics](http://localhost:8008/metrics)
Make sure this port is protected as the http server used is not considered secure (it should not be used by untrusted peers).
For instructions on how to spin up a beautiful and useful monitoring dashboard for your validator and beacon node, see [this page](./metrics-pretty-pictures.md).
## Advanced options
### Start multiple nodes
You can start multiple local nodes, in different terminal windows/tabs, by specifying numeric IDs:
```
make medalla NODE_ID=0 # the default
make medalla NODE_ID=1
make medalla NODE_ID=2
```
### Attach multiple validators to the same beacon node
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 may need to do this if you are running another client.
### Make a deposit directly using Nimbus
```
make medalla-deposit VALIDATORS=2 # default is just 1
```
### 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
```
>**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).

96
docs/the_nimbus_book/src/validator.md
View File

@ -1,96 +0,0 @@
# Become a Validator
> Note, the instructions below currently apply to Altona. They will be updated shortly to explain how you can use Nimbus to create your validator keys and interact with the Medalla deposit contract.
>
> To become a validator on Medalla using the [eth2 launchpad](https://medalla.launchpad.ethereum.org/), see [here](./medalla.md).
To become a validator, you need to install the beacon chain software, acquire 32 ETH, set up your validator account, and register with the deposit contract on ethereum.
There is currently no eth2 mainnet - all networks are testnets.
## Recommended Testnets
Though Nimbus can connect to any of the testnets published in the [eth2-clients/eth2-testnets repo](https://github.com/eth2-clients/eth2-testnets/tree/master/nimbus), below are the recommended ones:
- Multi-client Testnet: [medalla](https://github.com/goerli/medalla) ([explorer](https://medalla.beaconcha.in))
- Nimbus Testnet: testnet0 (experimental, not always active)
## Medalla
### Initial setup
Before we start, we have to obtain 32 ETH on the Goerli testnet (later on, we'll need to send this ETH to the deposit contract in order to become a validator).
1. Open your [MetaMask](https://metamask.io/) wallet, switch to the `Goerli Test Network` option from the top right corner.
2. Copy your account address by clicking on one of your accounts.
3. Post your account address on a social media platform (Twitter or Facebook). Copy the url to the post.
4. Paste your post url on the [Goerli faucet](https://faucet.goerli.mudit.blog/) and select `Give me Ether > 37.5 Ethers` from the top right corner of the page.
5. Wait for a few seconds and return to your MetaMask wallet to check if you have successfully received the ETH.
6. Once the [prerequisites](./install.md) are installed, you can connect to the medalla testnet with the following commands: <br>
- **_Remember to replace `make` with `mingw32-make` if using Windows._**
```bash
git clone https://github.com/status-im/nimbus-eth2
cd nimbus-eth2
git checkout devel
git pull
make update
make medalla # This will build Nimbus and all other dependencies
# and connect you to medalla
```
_Once Nimbus has finished building, you will be prompted to enter the private key of the account you want to deposit the 32 ETH from._
<img src="./img/connect_testnet.PNG" alt="" style="margin: 0 40 0 40"/>
7. Copy your private key from MetaMask (click on the three dots in the top right, followed by **Account Details** and **Export Private Key**).
<img src="./img/metamask_export_private_1.png" alt="" width="200" style="margin: 0 40 0 40"/>
<img src="./img/metamask_export_private_2.png" alt="" width="200" style="padding-left: 60px; padding-right: 60px; margin: 0 40 0 40"/>
<img src="./img/metamask_export_private_3.png" alt="" width="200" style="margin: 0 40 0 40"/>
8. Paste your private key into the console.
<img src="./img/enter_private_key.PNG" alt="" style="margin: 0 40 0 40"/>
9. Press enter and wait for a few seconds until you see *Deposit sent*.
```
INF 2020-07-05 12:58:25+02:00 Generating deposits ... validatorsDir=/Users/sssaintleger/nim-beacon-chain/build/data/shared_medalla_0/validators ...
INF 2020-07-05 12:58:25+02:00 Sending deposits ... DepositContract=0x07b39F4fDE4A38bACe212b546dAc87C58DfE3fDC ...
INF 2020-07-05 12:58:26+02:00 Deposit sent ... status=0x5455b1faf773a535668bdd4ade6b03f6cfd52f88414a5ad74bbdfdfd89f28b86
Deposit sent, wait for confirmation then press enter to continue
```
10. Check the status of your deposit by copying and pasting the transaction hash into [https://goerli.etherscan.io/](https://goerli.etherscan.io/) (where the transacton hash is the text displayed after `status=` in your console). For example, in the output displayed after step 9, we have `status=0x5455...` so the transaction hash is `0x5455...`. If you see a green *Success* box (see the image below) you can go ahead and press enter to continue.
<img src="./img/deposit-transaction-details.png" alt="" style="margin: 0 40 0 40"/>
> Note: it should take approximately 8 hours for your deposit to be processed by the beacon chain. To keep track of the status of your validator you should go to [https://medalla.beaconcha.in/validators/eth1deposits/[Validator PubKey]](https://medalla.beaconcha.in/validators/eth1deposits), replacing [Validator PubKey] with your actual Validator PubKey -- you can find this in the etherscan transaction details (for example, in the image above the Validator PubKey is `0x95aa...`).
And voila! That's all there is to it :)
The beacon chain client will start syncing the network while your deposit is being processed. As soon as it has synced, and your validator has been confirmed as active, the client will start performing validation duties.
P.S. at the bottom of the console, you should see something like:
```
peers: 18 > finalized: 710631d5:283 > head: 98204d1:285:10 > time: 1405:2 (44982)
ETH: 0
```
You can get a brief estimate of the time remaining until you've synced to the network by comparing `head` with `time` (`time` gives the current epoch, whereas `head` tells you how many epochs you've synced so far). From the above output, we see that the number of epochs synced so far is `285`, and the current epoch is `1405`.