Documentation improvements (#4794)
This commit is contained in:
zah
GitHub
parent
0d6453aa51
commit
2ae909d9b9
39
README.md
39
README.md
|
|
@ -59,7 +59,6 @@ You can check where the beacon chain fits in the Ethereum ecosystem in our Two-P
|
|||
## Donations
|
||||
|
||||
If you'd like to contribute to Nimbus development, our donation address is [`0x70E47C843E0F6ab0991A3189c28F2957eb6d3842`](https://etherscan.io/address/0x70E47C843E0F6ab0991A3189c28F2957eb6d3842)
|
||||
|
||||
## Branch guide
|
||||
|
||||
* `stable` - latest stable release - **this branch is recommended for most users**
|
||||
|
|
@ -68,11 +67,7 @@ If you'd like to contribute to Nimbus development, our donation address is [`0x7
|
|||
|
||||
## Developer resources
|
||||
|
||||
To build tools that interact with Nimbus while it's running, we expose an [RPC API](https://nimbus.guide/api.html).
|
||||
|
||||
To get started with developing Nimbus itself, see the [developer handbook](https://nimbus.guide/developers.html). The code follows the [Status Nim Style Guide](https://status-im.github.io/nim-style-guide/).
|
||||
|
||||
Nimbus is built in the [Nim language](https://nim-lang.org) - the compiler is automatically installed when building the project for the first time. More information - in particular security-related information about the language - can be found in the [Auditor Handbook](https://nimbus.guide/auditors-book/).
|
||||
To get started with developing Nimbus itself, see the [developer handbook](https://nimbus.guide/developers.html).
|
||||
|
||||
## Tooling and utilities
|
||||
|
||||
|
|
@ -98,12 +93,11 @@ build/state_sim --help
|
|||
### Local network simulation
|
||||
|
||||
The local network simulation will create a full peer-to-peer network of beacon nodes and validators on a single machine, and run the beacon chain in real time.
|
||||
|
||||
Parameters such as shard, validator counts, and data folders are configured [vars.sh](tests/simulation/vars.sh). They can be set in as environment variables before launching the simulation.
|
||||
Parameters such as shard, validator counts, and data folders can be set in as environment variables before launching the simulation.
|
||||
|
||||
```bash
|
||||
# Clear data files from your last run and start the simulation with a new genesis block:
|
||||
make VALIDATORS=192 NODES=6 USER_NODES=1 eth2_network_simulation
|
||||
make VALIDATORS=192 NUM_NODES=6 USER_NODES=1 local-testnet-minimal
|
||||
|
||||
# In another terminal, get a shell with the right environment variables set:
|
||||
./env.sh bash
|
||||
|
|
@ -124,43 +118,28 @@ client processes (50/50), communicating through the
|
|||
beacon node and 6 validator client processes, where each of them will handle 16
|
||||
validators), but if you don't want to use external validator clients and instead
|
||||
want to have all the validators handled by the beacon nodes you may use
|
||||
`BN_VC_VALIDATOR_SPLIT=no` as an additional argument to `make eth2_network_simulation`.
|
||||
|
||||
By default, the simulation will start from a pre-generated genesis state. If you wish to
|
||||
simulate the bootstrap process with a Ethereum 1.0 validator deposit contract, start the
|
||||
simulation with `WAIT_GENESIS=yes`
|
||||
|
||||
```
|
||||
make eth2_network_simulation WAIT_GENESIS=yes
|
||||
```
|
||||
|
||||
You can also separate the output from each beacon node in its own panel, using [multitail](https://www.vanheusden.com/multitail/):
|
||||
|
||||
```bash
|
||||
make eth2_network_simulation USE_MULTITAIL="yes"
|
||||
```
|
||||
|
||||
You can find out more about it in the [development update](https://our.status.im/nimbus-development-update-2018-12-2/).
|
||||
`USE_VC=0` as an additional argument to `make local-testnet-minimal`.
|
||||
|
||||
_Alternatively, fire up our [experimental Vagrant instance with Nim pre-installed](https://our.status.im/setting-up-a-local-vagrant-environment-for-nim-development/) and give us your feedback about the process!_
|
||||
|
||||
### Visualising simulation metrics
|
||||
|
||||
<!-- TODO: Is this up to date? -->
|
||||
|
||||
The [generic instructions from the Nimbus repo](https://github.com/status-im/nimbus/#metric-visualisation) apply here as well.
|
||||
|
||||
Specific steps:
|
||||
|
||||
```bash
|
||||
# This will generate the Prometheus config on the fly, based on the number of
|
||||
# nodes (which you can control by passing something like NODES=6 to `make`).
|
||||
make VALIDATORS=192 NODES=6 USER_NODES=0 eth2_network_simulation
|
||||
# This will generate the Prometheus config on the fly, based on the number of nodes:
|
||||
make REMOTE_VALIDATORS_COUNT=192 NUM_NODES=6 USER_NODES=0 local-testnet-minimal
|
||||
|
||||
# In another terminal tab, after the sim started:
|
||||
cd tests/simulation/prometheus
|
||||
prometheus
|
||||
```
|
||||
|
||||
The dashboard you need to import in Grafana is "grafana/beacon\_nodes\_Grafana\_dashboard.json".
|
||||
The dashboard you need to import in Grafana is `grafana/beacon_nodes_Grafana_dashboard.json`.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -54,7 +54,6 @@ nav:
|
|||
- 'build.md'
|
||||
- 'start-syncing.md'
|
||||
- 'trusted-node-sync.md'
|
||||
- 'web3-backup.md'
|
||||
|
||||
- Validator:
|
||||
- 'deposit.md'
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
# Add an additional validator
|
||||
|
||||
<!-- TODO: We should work on a new recommended way to add validators based on the Keymanager API (this doesn't require a node restart) -->
|
||||
|
||||
To add an additional validator, [generate a new key](./more-keys.md) then follow [the same steps](./keys.md) as you did when adding your other keys.
|
||||
|
||||
You'll have to [restart](./connect-eth2.md) the beacon node for the changes to take effect.
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ The tool requires that you [build nimbus from source](./build.md).
|
|||
Make sure you're in the `nimbus-eth2` repository.
|
||||
|
||||
### 1. Build ncli_db
|
||||
|
||||
The first step is to build `ncli_db`:
|
||||
```sh
|
||||
make ncli_db
|
||||
|
|
@ -34,7 +35,7 @@ The following options are available:
|
|||
|
||||
Where:
|
||||
|
||||
- The `network` can be `mainnet`, `prater`, or `sepolia`
|
||||
- The `network` can be `mainnet`, `prater`, or `sepolia`.
|
||||
|
||||
- The default location of the `db` is `build/data/shared_mainnet_0/db` for `mainnet`, `build/data/shared_prater_0/db` for `prater`, etc.
|
||||
|
||||
|
|
@ -91,9 +92,11 @@ This workbook consists of three inter-related spreadsheets: `Summary`, `My Valid
|
|||
|
||||
2. Remove the table entries in `My Validators` and delete everything in the `datasource` sheet.
|
||||
|
||||
3. Import the output from `validatorPerf` to `datasource` - the easiest way to do this is to pipe the output to a `csv`, remove the first few lines, and import the `csv` into `datasource`.
|
||||
3. Import the output from `validatorPerf` to `datasource`.
|
||||
The easiest way to do this is to pipe the output to a `csv`, remove the first few lines, and import the `csv` into `datasource`.
|
||||
|
||||
4. Manually copy over your validator(s) to the `My Validators` sheet - the easiest way to find your validator's `validator_index` is to search for it by its public key on [beaconcha.in](https://beaconcha.in/) (for example, [this validator's](https://beaconcha.in/validator/115733) index is 115733).
|
||||
4. Manually copy over your validator(s) to the `My Validators` sheet.
|
||||
The easiest way to find your validator's `validator_index` is to search for it by its public key on [beaconcha.in](https://beaconcha.in/) (for example, [this validator's](https://beaconcha.in/validator/115733) index is 115733).
|
||||
|
||||
5. Go to the `Summary` page and view your results.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,8 +6,8 @@ This page will take you through how to set up a `systemd` service for your beaco
|
|||
Once this is done, you can start/stop enable/disable from the linux prompt.
|
||||
|
||||
!!! abstract "`systemd`"
|
||||
[`systemd`](https://systemd.io/) is a service manager designed specifically for Linux - it cannot be used on Windows / Mac.
|
||||
You can find out more about `systemd` [here](https://fedoramagazine.org/what-is-an-init-system/)
|
||||
[`systemd`](https://systemd.io/) is a service manager designed specifically for Linux: it cannot be used on Windows / Mac.
|
||||
You can find out more about `systemd` [here](https://fedoramagazine.org/what-is-an-init-system/).
|
||||
|
||||
!!! note "Package manager installations"
|
||||
When installing Nimbus via your [package manager](./binaries.md), a user and service will already have been created for you and you can skip straight to the configuration section.
|
||||
|
|
@ -109,12 +109,20 @@ sudo journalctl -u nimbus_beacon_node.service --since yesterday
|
|||
|
||||
## Import validator keys
|
||||
|
||||
Before you start, familiarize yourself with the [standard way of importing validators](./keys.md).
|
||||
|
||||
Make sure you use the correct [data directory](./data-dir.md).
|
||||
Look for the `--data-dir` option in the `.service` file.
|
||||
|
||||
When using a service, the beacon node is running as a different user.
|
||||
Look for the `User=` option in the `.service`.
|
||||
Here we assume that the user is called `nimbus`.
|
||||
|
||||
The key import must be performed as this user in order for the key files to have the correct permission:
|
||||
|
||||
```
|
||||
# Run import command as the `nimbus` user
|
||||
sudo -u nimbus /usr/bin/nimbus_beacon_node deposit import --data-dir=/var/lib/nimbus/shared_mainnet_0 /path/to/keys
|
||||
sudo -u nimbus /usr/bin/nimbus_beacon_node deposits import --data-dir=/var/lib/nimbus/shared_mainnet_0 /path/to/keys
|
||||
```
|
||||
|
||||
!!! note
|
||||
|
|
|
|||
|
|
@ -17,6 +17,10 @@ When building from source, you will need additional build dependencies to be ins
|
|||
- Developer tools (C compiler, Make, Bash, Git)
|
||||
- [CMake](https://cmake.org/)
|
||||
|
||||
<!-- TODO: Please test whether the instructions below are correct. I think we are missing some dependencies on Windows. -->
|
||||
<!-- Microsoft offer virtual machines that you can use for testing here: -->
|
||||
<!-- https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ -->
|
||||
|
||||
=== "Linux"
|
||||
|
||||
On common Linux distributions the dependencies can be installed with
|
||||
|
|
@ -51,11 +55,11 @@ When building from source, you will need additional build dependencies to be ins
|
|||
3. Set exceptions to "dwarf" on 32-bit and "seh" on 64-bit.
|
||||
4. 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` (`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`.
|
||||
|
||||
!!! note
|
||||
If the online installer isn't working you can try installing `mingw-w64` through [MSYS2](https://www.msys2.org/).
|
||||
|
||||
Install [Git for Windows](https://gitforwindows.org/) and use a "Git Bash" shell to clone and build `nimbus-eth2`.
|
||||
|
||||
=== "Android"
|
||||
|
||||
- Install the [Termux](https://termux.com) app from FDroid or the Google Play store
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ You can set up a separate address or reuse the address from which you funded you
|
|||
|
||||
### 2. (Re)start the node
|
||||
|
||||
Press `Ctrl-c` to stop the beacon node if it's running, then use the same command [as before]() to run it again, this time adding the `--suggested-fee-recipient` option in addition to `--web3-url`:
|
||||
Press `Ctrl-c` to stop the beacon node if it's running, then use the same command as before to run it again, this time adding the `--suggested-fee-recipient` option in addition to `--web3-url`:
|
||||
|
||||
=== "Mainnet"
|
||||
```sh
|
||||
|
|
|
|||
|
|
@ -1,3 +1,13 @@
|
|||
# Back up your database
|
||||
|
||||
The best way to do this is to simply copy it over: you'll find it either in `build/data/shared_mainnet_0/db/` (if you're running Prater, `shared_prater_0`) or the directory you supplied to the `--data-dir` argument when you launched Nimbus.
|
||||
|
||||
The best way to do this is to use `.backup` sqlite command:
|
||||
|
||||
1. Navigate to either `build/data/shared_mainnet_0/db/` (if you're running Prater: `shared_prater_0`) or the directory you supplied to the `--data-dir` argument when you launched Nimbus.
|
||||
|
||||
2. Run the following command:
|
||||
```
|
||||
sqlite3 nbc.sqlite3 ".backup 'backup_nbc.sqlite3'"
|
||||
```
|
||||
Make sure to correctly type both single and double quotes, as written above.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,6 +10,13 @@ Before building Nimbus for the first time, make sure to install the [prerequisit
|
|||
* [Ben Edgington's annotated spec](https://eth2book.info/bellatrix/)
|
||||
* [Vitalik's annotated spec](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md)
|
||||
|
||||
## Nim programming language
|
||||
|
||||
Nimbus is built in the [Nim language](https://nim-lang.org).
|
||||
The compiler is automatically installed when building the project for the first time.
|
||||
|
||||
More information — in particular security-related information about the language — can be found in the [Auditor Handbook](https://nimbus.guide/auditors-book/).
|
||||
|
||||
## Code style
|
||||
|
||||
The code follows the [Status Nim Style Guide](https://status-im.github.io/nim-style-guide/).
|
||||
|
|
@ -119,7 +126,7 @@ nim --version # Nimbus is tested and supported on 1.2.12 at the moment
|
|||
|
||||
- you can freely combine those variables on the `make` command line:
|
||||
```bash
|
||||
make -j$(nproc) NIMFLAGS="-d:release" USE_MULTITAIL=yes eth2_network_simulation
|
||||
make -j$(nproc) NIMFLAGS="-d:release" USE_MULTITAIL=yes local-testnet-minimal
|
||||
```
|
||||
|
||||
- don't use the [lightweight stack tracing implementation from nim-libbacktrace](https://github.com/status-im/nimbus-eth2/pull/745):
|
||||
|
|
@ -185,7 +192,7 @@ To run the simulation:
|
|||
|
||||
```bash
|
||||
make update
|
||||
make eth2_network_simulation
|
||||
make local-testnet-minimal
|
||||
```
|
||||
|
||||
To clean the previous run's data:
|
||||
|
|
@ -198,14 +205,14 @@ To change the number of validators and nodes:
|
|||
|
||||
```bash
|
||||
# Clear data files from your last run and start the simulation with a new genesis block:
|
||||
make VALIDATORS=192 NODES=6 USER_NODES=1 eth2_network_simulation
|
||||
make VALIDATORS=192 NODES=6 USER_NODES=1 local-testnet-minimal
|
||||
```
|
||||
|
||||
If you’d like to see the nodes running on separated sub-terminals inside one big window, install [Multitail](https://www.vanheusden.com/multitail/index.php) (if you're on a Mac, follow the instructions [here](https://brewinstall.org/Install-multitail-on-Mac-with-Brew/)), then:
|
||||
|
||||
|
||||
```
|
||||
USE_MULTITAIL="yes" make eth2_network_simulation
|
||||
USE_MULTITAIL="yes" make local-testnet-minimal
|
||||
```
|
||||
|
||||
You’ll get something like this (click for full size):
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ cd nimbus-eth2
|
|||
|
||||
### 2. Run the build process
|
||||
|
||||
To build the Nimbus light client and its dependencies, run:
|
||||
To build the Nimbus light client and its dependencies, make sure you have [all prerequisites](./install.md) and then run:
|
||||
|
||||
```sh
|
||||
make -j4 nimbus_light_client
|
||||
|
|
|
|||
|
|
@ -58,11 +58,7 @@ This simulates the maximum load that the consensus layer will put on the machine
|
|||
|
||||
### How do I add an additional validator?
|
||||
|
||||
To add an additional validator, follow [the same steps](./keys.md) as you did when you added your first.
|
||||
You'll have to restart the beacon node for the changes to take effect.
|
||||
|
||||
!!! note
|
||||
A single Nimbus instance is able to handle multiple validators.
|
||||
See the information [here](./additional-validator.md).
|
||||
|
||||
### What does `synced/opt` mean, in the "Slot start" message?
|
||||
|
||||
|
|
@ -167,7 +163,7 @@ At the other end of the spectrum, if your balance is closer to 31 ETH, it's prob
|
|||
|
||||
### When can I withdraw my funds, and what's the difference between exiting and withdrawing?
|
||||
|
||||
After the Capella hard-fork, activated on 12th of April 2023, all exited validators that use 0x01 withdrawal credentials will have their funds automatically withdrawn.
|
||||
After the Capella hard-fork, activated on 12th of April 2023, all exited validators that use `0x01` withdrawal credentials will have their funds automatically withdrawn.
|
||||
Please see our dedicated [guide for withdrawals](./withdrawals.md) for further information.
|
||||
|
||||
### How are validators incentivized to stay active and honest?
|
||||
|
|
@ -251,7 +247,8 @@ This means that validators need not go to extreme lengths with backup clients or
|
|||
Again, it depends.
|
||||
Behaving maliciously, e.g. attesting to invalid or contradicting blocks, will lead to a validator's stake being slashed.
|
||||
|
||||
The minimum amount that can be slashed is 1 ETH, but **this number increases if other validators are slashed at the same time.**
|
||||
If a malicious behavior is detected, 1/32 of validator's staked ether (up to a maximum of 1 ETH) is immediately slashed and a 36-day removal period begins.
|
||||
During this period, the validator's stake is gradually slashed and at day 18 an additional penalty is applied: the amount depends on the number of other slashed validators — the more validators are slashed, the magnitude of the slash increases.
|
||||
|
||||
The idea behind this is to minimize the losses from honest mistakes, but strongly discouraging coordinated attacks.
|
||||
|
||||
|
|
@ -271,23 +268,22 @@ Validators that are slashed are prevented from participating in the protocol fur
|
|||
|
||||
If the signing key is lost, the validator can no longer propose or attest.
|
||||
|
||||
Over time, the validator's balance will decrease as he or she is punished for not participating in the consensus process.
|
||||
When the validator's balance reaches 16 ETH, he or she will be automatically exited from the validator pool.
|
||||
|
||||
However, all is not lost.
|
||||
Assuming validators derive their keys using [EIP2334](https://eips.ethereum.org/EIPS/eip-2334) (as per the default onboarding flow) then **validators can always recalculate their signing key from their withdrawal key**.
|
||||
|
||||
The 16 ETH can then be withdrawn, with the withdrawal key, after a delay of around a day.
|
||||
|
||||
Note that this delay can be longer if many others are exiting or being kicked out at the same time.
|
||||
|
||||
### What happens if I lose my withdrawal key?
|
||||
|
||||
If the withdrawal key is lost, there is no way to obtain access to the funds held by the validator.
|
||||
|
||||
As such, it's a good idea to create your keys from mnemonics which act as another backup.
|
||||
This will be the default for validators who join via this site's onboarding process.
|
||||
|
||||
If the validator can no longer propose or attest, their balance will decrease over time as they are punished for not participating in the consensus process.
|
||||
When the validator's balance reaches 16 ETH, they will be automatically exited from the validator pool, and 16 ETH will be transfered to their withdrawal address (as long it's specified).
|
||||
|
||||
!!! note
|
||||
After the Capella hard-fork, activated on 12th of April 2023, all exited validators that use `0x01` withdrawal credentials will have their funds automatically withdrawn.
|
||||
Please see our dedicated [guide for withdrawals](./withdrawals.md) for further information.
|
||||
|
||||
### What happens if my withdrawal key is stolen?
|
||||
|
||||
If the withdrawal key is stolen, the thief can transfer the validator’s balance, but only once the validator has exited.
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@
|
|||
You can use your node's graffiti flag to include a short text in the blocks that your node creates.
|
||||
You will be able to see it using the block explorer.
|
||||
|
||||
The graffiti can be either a string or, if you want to specify raw bytes, you can use 0x-prefixed hex value.
|
||||
|
||||
## Command line
|
||||
|
||||
=== "Mainnet"
|
||||
|
|
|
|||
|
|
@ -1,17 +1,15 @@
|
|||
# Monitor the health of your node
|
||||
|
||||
The most important thing for the the health, performance and stablity of your node and the overall network is the strength of your node's network connectivity / peer count.
|
||||
The most important thing for the health, performance and stability of your node and the overall network is the strength of your node's network connectivity / peer count.
|
||||
|
||||
See [here](./networking.md) for our networking related tips and tricks.
|
||||
|
||||
## Keep track of your attestation effectiveness
|
||||
|
||||
Attestation effectiveness is a metric that directly affects your validator rewards.
|
||||
In simple terms, an attestation is more valuable the sooner it is put into a block and included in the chain.
|
||||
|
||||
This interval is called the *inclusion distance* of an attestation.
|
||||
The smaller it is, the more profitable your validator will be.
|
||||
For a deeper understanding we highly recommend reading [Attestant's wonderful blog post](https://www.attestant.io/posts/defining-attestation-effectiveness/#:~:text=Stakers%20looking%20to%20maximize%20their,provide%20clear%20metrics%20for%20performance.) on the matter.
|
||||
The interval between a validator performing its duty and an attestation is called the *inclusion distance* of an attestation.
|
||||
As long as your validator is within the allowed inclusion distance, you will get the full reward.
|
||||
|
||||
You can verify your validator's effectiveness on the [beaconcha.in](https://beaconcha.in/) website.
|
||||
|
||||
|
|
@ -19,7 +17,7 @@ You can verify your validator's effectiveness on the [beaconcha.in](https://beac
|
|||
|
||||
Ideally you want to see a value above 95%.
|
||||
|
||||
While attestation effectiveness depends on a variety of factors - attestation network propagation, your network connectivity, and the peers you are connected to - your network connectivity is likely the most important factors you can control to improve this metric.
|
||||
While attestation effectiveness depends on a variety of factors — attestation network propagation, your network connectivity, and the peers you are connected to — your network connectivity is likely the most important factors you can control to improve this metric.
|
||||
Apart from the tips outlined on this guide, you could also experiment with [subscribing to all subnets](./profits.md#subscribe-to-all-subnets).
|
||||
|
||||
## Monitor your system's network I/O usage
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Historical data
|
||||
|
||||
!!! note ""
|
||||
This feature is available from `v23.1.0` onwards.
|
||||
This feature is available from Nimbus `v23.1.0` onwards.
|
||||
|
||||
In order for the network to remain healthy, each node must keep a minimum of 5 months of historical block data.
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ As noted above, the database will not shrink in size.
|
|||
To reclaim space, perform a [trusted node sync](./trusted-node-sync.md) on a fresh database instead.
|
||||
|
||||
!!! warning "Backwards compatiblity"
|
||||
Versions prior to v23.1.0 do not fully support pruned databases!
|
||||
Versions prior to Nimbus `v23.1.0` do not fully support pruned databases!
|
||||
To downgrade, you may need to perform a [trusted node sync](./trusted-node-sync.md).
|
||||
|
||||
When switching to `archive` mode, the node will start keeping history from the most recent prune point, but will not recreate deep history.
|
||||
|
|
|
|||
|
|
@ -6,6 +6,11 @@ The Nimbus beacon node runs on Linux, macOS, Windows, and Android.
|
|||
|
||||
Check that your machine matches the [minimal system requirements](./hardware.md).
|
||||
|
||||
## Build prerequisites
|
||||
|
||||
You will need to install developer tools (C compiler, Make, Bash, Git) and [CMake](https://cmake.org/).
|
||||
See the [build guide](./build.md).
|
||||
|
||||
## Time
|
||||
|
||||
The beacon chain relies on your computer having the correct time set (±0.5 seconds).
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
|
||||
The standardized [Keymanager API](https://ethereum.github.io/keymanager-APIs/) can be used to add, remove, or [migrate](./migration.md) validators on the fly while the beacon node is running.
|
||||
|
||||
As of `v1.7.0` it supports `web3signer` keystores.
|
||||
|
||||
## Configuration
|
||||
|
||||
By default, we disable the Keymanager API.
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ NOT 2022-07-19 17:36:37.578+02:00 Keystore imported
|
|||
After importing keys, it's time to [restart the node](./connect-eth2.md) and check that the keys have been picked up by the beacon node.
|
||||
|
||||
!!! info "All the keys"
|
||||
You can read more about the different types of keys [here](https://blog.ethereum.org/2020/05/21/keys/) — the `deposit import` command will import the **signing key** only.
|
||||
You can read more about the different types of keys [here](https://blog.ethereum.org/2020/05/21/keys/) — the `deposits import` command will import the **signing key** only.
|
||||
|
||||
## Command line
|
||||
|
||||
|
|
|
|||
|
|
@ -43,6 +43,8 @@ nim_gc_heap_instance_occupied_bytes{type_name="seq[TrustedAttestation]"} 29728.0
|
|||
Metrics are by default only accessible from the same machine as the beacon node is running on.
|
||||
To fetch metrics from a remote machine, an SSH tunnel is recommended.
|
||||
|
||||
<!-- TODO: Create a reference page with all metrics for each of the products (beacon node and validator client) -->
|
||||
|
||||
The metrics server offers one snapshot in time of the state of the beacon node.
|
||||
Metrics, however, are at their most useful when collected over time — for this, we'll need to set up two more pieces of software: Prometheus and Grafana.
|
||||
|
||||
|
|
@ -56,12 +58,13 @@ The following steps will take you through how to use Prometheus and Grafana to s
|
|||
|
||||
Use your favourite package manager to download Prometheus: for example `apt-get install prometheus` on Ubuntu, or `brew install prometheus` on MacOS, should do the trick.
|
||||
|
||||
> If you don't use a package manager, you can download the [latest release](https://prometheus.io/download/) of directly from Prometheus website. To extract it, run:
|
||||
>
|
||||
> ```
|
||||
> tar xvfz prometheus-*.tar.gz
|
||||
> cd prometheus-*
|
||||
> ```
|
||||
!!! note
|
||||
If you don't use a package manager, you can download the [latest release](https://prometheus.io/download/) of directly from Prometheus website. To extract it, run:
|
||||
|
||||
```
|
||||
tar xvfz prometheus-*.tar.gz
|
||||
cd prometheus-*
|
||||
```
|
||||
|
||||
|
||||
#### 2. Copy the binary
|
||||
|
|
@ -106,7 +109,7 @@ level=info ts=2021-01-22T14:52:10.604Z caller=main.go:673 msg="Server is ready t
|
|||
|
||||
#### 4. Download Grafana
|
||||
|
||||
[Download the latest release]((https://grafana.com/grafana/download?platform=linux)) of Grafana for your platform.
|
||||
[Download the latest release](https://grafana.com/grafana/download?platform=linux) of Grafana for your platform.
|
||||
You need version 7.2 or newer.
|
||||
|
||||
!!! note
|
||||
|
|
@ -210,9 +213,3 @@ The good news is that you don't need to use all these tools, as long as you take
|
|||
|
||||
See [here](https://github.com/metanull-operator/eth2-grafana/tree/master/nimbus) for a detailed guide explaining how to use it.
|
||||
|
||||
## Enabling mobile alerts
|
||||
|
||||
### Telegram
|
||||
|
||||
TODO
|
||||
|
||||
|
|
|
|||
|
|
@ -200,8 +200,3 @@ For a quick guide on how to set up a systemd service, see [here](./beacon-node-s
|
|||
If you are unsure of the safety of a step, please get in touch with us directly on [discord](https://discord.gg/nnNEBvHu3m).
|
||||
Additionally, we recommend testing the migration works correctly on a testnet before going ahead on mainnet.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -18,8 +18,8 @@ Enabling UPnP is usually as simple as checking a box in your router's configurat
|
|||
## Monitor your Peer count
|
||||
|
||||
!!! note
|
||||
As of `v1.7.0`, peer scoring has been fine-tuned.
|
||||
As such `--max-peers` should not be set below 70. Note that Lowering `max-peers` does not significantly improve bandwidth usage, but does increase the risk of missed attestations.
|
||||
The `--max-peers` setting should not be set below 70.
|
||||
Lowering `max-peers` does not significantly improve bandwidth usage, but does increase the risk of missed attestations.
|
||||
|
||||
If your Peer count is low (less than `15`) and/or you repeatedly see either of the following warnings:
|
||||
|
||||
|
|
@ -41,6 +41,8 @@ The first step however, is to check for incoming connections.
|
|||
|
||||
To check if you have incoming connections set, run:
|
||||
|
||||
<!-- TODO: It would be very sweet if we can create some kind of CI tests that verify that these instructions work -->
|
||||
|
||||
```
|
||||
curl -s http://localhost:8008/metrics | grep libp2p_open_streams
|
||||
```
|
||||
|
|
|
|||
|
|
@ -10,9 +10,6 @@ Both execution and consensus clients must be fully synced to perform validation
|
|||
!!! info "Running without execution client"
|
||||
Nimbus continues to sync optimistically when the execution client is not available thanks to its built-in execution payload verifier.
|
||||
|
||||
This feature is available from `v23.1.0` onwards.
|
||||
A preview of the feature could be enabled with `--optimistic` in earlier versions - this flag is no longer needed.
|
||||
|
||||
## Identifying optimistic sync
|
||||
|
||||
An optimistically synced node can be identified by examining the "Slot start" log message.
|
||||
|
|
|
|||
|
|
@ -261,18 +261,33 @@ Once you're done, `ssh` back into your Pi.
|
|||
|
||||
### 11. Install the beacon node
|
||||
|
||||
Open the [Nimbus eth2 releases page](https://github.com/status-im/nimbus-eth2/releases/latest) and copy the link for the file that starts with `nimbus-eth2_Linux_arm64v8`.
|
||||
=== "Manual installation"
|
||||
|
||||
Run this in your home directory to download nimbus-eth2:
|
||||
Open the [Nimbus eth2 releases page](https://github.com/status-im/nimbus-eth2/releases/latest) and copy the link for the file that starts with `nimbus-eth2_Linux_arm64v8`.
|
||||
|
||||
Run this in your home directory to download nimbus-eth2:
|
||||
|
||||
```sh
|
||||
mkdir nimbus-eth2
|
||||
wget <insert download link here>
|
||||
tar -xzf nimbus-eth2_Linux_arm64v8*.tar.gz -C nimbus-eth2
|
||||
rm nimbus-eth2_Linux_arm64v8*.tar.gz
|
||||
```
|
||||
|
||||
Now you can find the software in the nimbus-eth2 directory.
|
||||
|
||||
=== "Using package manager"
|
||||
|
||||
1. Add Status APT repository to your system.
|
||||
Follow [this guide](https://apt.status.im).
|
||||
|
||||
2. Install Nimbus using APT:
|
||||
|
||||
```sh
|
||||
sudo apt-get install nimbus-beacon-node
|
||||
```
|
||||
|
||||
```sh
|
||||
mkdir nimbus-eth2
|
||||
wget <insert download link here>
|
||||
tar -xzf nimbus-eth2_Linux_arm64v8*.tar.gz -C nimbus-eth2
|
||||
rm nimbus-eth2_Linux_arm64v8*.tar.gz
|
||||
```
|
||||
|
||||
Now you can find the software in the nimbus-eth2 directory.
|
||||
|
||||
### 12. Copy signing key over to Pi
|
||||
|
||||
|
|
|
|||
|
|
@ -21,21 +21,21 @@ Mainnet is the main Ethereum network where real assets are at stake, while testn
|
|||
If this is the first time you're setting up your node, it is recommended you run it on a testnet first.
|
||||
Later, when everything is working, you can easily switch to mainnet.
|
||||
|
||||
### Testnet
|
||||
=== "Testnet"
|
||||
|
||||
To start syncing the `prater` testnet from the `nimbus-eth2` repository, run:
|
||||
To start syncing the `prater` testnet from the `nimbus-eth2` repository, run:
|
||||
|
||||
```
|
||||
./run-prater-beacon-node.sh
|
||||
```
|
||||
```
|
||||
./run-prater-beacon-node.sh
|
||||
```
|
||||
|
||||
### Mainnet
|
||||
=== "Mainnet"
|
||||
|
||||
To start syncing the Ethereum beacon chain mainnet, run:
|
||||
To start syncing the Ethereum beacon chain mainnet, run:
|
||||
|
||||
```
|
||||
./run-mainnet-beacon-node.sh
|
||||
```
|
||||
```
|
||||
./run-mainnet-beacon-node.sh
|
||||
```
|
||||
|
||||
## Log output
|
||||
|
||||
|
|
|
|||
|
|
@ -124,6 +124,8 @@ Please check that your setup matches our [system requirements](./hardware.md).
|
|||
|
||||
### Eth1 chain monitor failure
|
||||
|
||||
<!-- TODO: This error message has changed -->
|
||||
|
||||
If you see an error that looks like the following:
|
||||
|
||||
```
|
||||
|
|
@ -133,7 +135,7 @@ If you see an error that looks like the following:
|
|||
It is because your node can't connect to the web3 provider you have specified.
|
||||
Please double check that you've correctly specified your provider.
|
||||
|
||||
If you haven't done so already, we recommend [adding a backup](web3-backup.md).
|
||||
If you haven't done so already, we recommend [allowing multiple execution clients](./eth1.md#running-multiple-execution-clients).
|
||||
|
||||
### Discovered new external address warning log
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,5 @@
|
|||
# Sync from a trusted node
|
||||
|
||||
!!! note ""
|
||||
This feature is available from `v1.7.0` onwards.
|
||||
|
||||
When you [start the beacon node](./quick-start.md) for the first time, it connects to the beacon chain network and starts syncing automatically — a process that can take several days.
|
||||
|
||||
Trusted node sync allows you to get started more quickly by fetching a recent checkpoint from a trusted node — you can get started in minutes instead of days.
|
||||
|
|
@ -92,14 +89,11 @@ The `--trusted-block-root` option enables you to leverage the Nimbus light clien
|
|||
|
||||
### Sync deposit history
|
||||
|
||||
!!! note ""
|
||||
This feature is available from `v22.12.0` onwards.
|
||||
|
||||
The `--with-deposit-snapshot` allows syncing deposit history via REST, avoiding the need to search the execution client for this information and thus allowing the client to more quickly start producing blocks.
|
||||
|
||||
!!! note
|
||||
The API endpoint for downloading this information was recently added to the Beacon API specification and is available on nodes running Nimbus v22.12.0 and later.
|
||||
For other checkpoint sources, consult their documentation with regards to the `/eth/v1/beacon/deposit_snapshot` endpoint.
|
||||
The API endpoint for downloading this information is a relatively recent addition to the Beacon API specification.
|
||||
It is available on nodes running Nimbus, but if you're using other checkpoint sources, consult their documentation with regards to the `/eth/v1/beacon/deposit_snapshot` endpoint.
|
||||
|
||||
!!! tip
|
||||
It's safe to always specify this option.
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ The Nimbus beacon node supports both its own and third-party validator clients v
|
|||
|
||||
## Setup
|
||||
|
||||
To run a separate validator client, you must first make sure that your beacon node has its REST API enabled - start it with the `--rest` option.
|
||||
To run a separate validator client, you must first make sure that your beacon node has its REST API enabled: start it with the `--rest` option.
|
||||
|
||||
Next, choose a data directory for the validator client and import the keys there:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,5 @@
|
|||
# Validator monitoring
|
||||
|
||||
!!! note
|
||||
This feature is available from `v23.1.0` onwards.
|
||||
Earlier Nimbus versions included a preview version this feature behind a feature flag without enabling it by default.
|
||||
|
||||
The validator monitoring feature allows for tracking the life cycle and performance of one or more validators in detail.
|
||||
Monitoring can be carried out for any validator, with slightly more detail for validators that are running in the same beacon node.
|
||||
|
||||
|
|
@ -80,6 +76,8 @@ It may happen that the same message is counted more than once under certain cond
|
|||
|
||||
## Monitoring metrics
|
||||
|
||||
For instructions on how to use Prometheus and Grafana, see [these instructions](./metrics-pretty-pictures.md).
|
||||
|
||||
The full list of metrics supported by the validator monitoring feature can be seen in the [source code](https://github.com/status-im/nimbus-eth2/blob/unstable/beacon_chain/validators/validator_monitor.nim) or by examining the metrics output:
|
||||
|
||||
```sh
|
||||
|
|
|
|||
|
|
@ -1,17 +0,0 @@
|
|||
# Backup web3 provider
|
||||
|
||||
Nimbus supports using multiple web3 providers, in case one breaks or goes down.
|
||||
These web3 providers must share JWT secret and will be used in a fallback manner, meaning that when the first one fails, the second one will be used instead until the first one is back up.
|
||||
|
||||
Each beacon node requires at least one dedicated web3 provider.
|
||||
|
||||
!!! note
|
||||
The backup web3 provider must use the same JWT secret as the main provider, and will not be used until the main provider has failed.
|
||||
This may result in a gap in duties as the backup provider syncs.
|
||||
This gap will be addressed in future releases.
|
||||
|
||||
```sh
|
||||
./run-mainnet-beacon-node.sh \
|
||||
--web3-url="http://127.0.0.1:8551" \
|
||||
--web3-url="ws://backup:4444"
|
||||
```
|
||||
|
|
@ -1,14 +1,12 @@
|
|||
# Withdraw your staked funds
|
||||
|
||||
After the Capella hard-fork, activated on 12th of April 2023, all validators will be able to withdrawal their staked funds from the beacon chain.
|
||||
|
||||
Withdrawals are enabled for each validator once it's configured to use [0x01 withdrawal credentials](https://notes.ethereum.org/@launchpad/withdrawals-faq#Q-What-are-0x00-and-0x01-withdrawal-credentials-prefixes) which specify an execution layer address that will be the beneficiary of all withdrawn funds.
|
||||
|
||||
If your validator was created with 0x01 withdrawal credentials, it's already fully prepared for withdrawals and you can safely skip the next step.
|
||||
If your validator was created with `0x01` withdrawal credentials, it's already fully prepared for withdrawals and you can safely skip the next step.
|
||||
|
||||
## Updating your withdrawal credentials
|
||||
|
||||
To migrate your validator from BLS to 0x01 withdrawal credentials, you have to use the same third-party tool that was used to generate the BLS key.
|
||||
To migrate your validator from BLS to `0x01` withdrawal credentials, you have to use the same third-party tool that was used to generate the BLS key.
|
||||
You have to create a signed `BLS-to-Execution-Change` message that must be broadcast to the network (and eventually published in a beacon chain block) in order to execute the desired withdrawal credentials update.
|
||||
|
||||
If you have used the [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) tool (formerly known as `eth2.0-deposit-cli`), please follow the steps provided [here](https://launchpad.ethereum.org/en/btec/).
|
||||
|
|
@ -20,9 +18,6 @@ If you have used other software for generating your BLS withdrawal credentials,
|
|||
Your choice of withdrawal address is permanent.
|
||||
If you ever wish to switch it later, the only option is to exit your validator and then create a new one.
|
||||
|
||||
!!! note
|
||||
Nimbus will allow you to broadcast the `BLS-to-Execution-Change` message only after the Capella hard-fork is activated on 12th of April 2023.
|
||||
|
||||
!!! tip
|
||||
The specified withdrawal address doesn't need to match the [fee recipient address](./suggested-fee-recipient.md) used by your validator.
|
||||
|
||||
|
|
@ -38,7 +33,7 @@ If you have used other software for generating your BLS withdrawal credentials,
|
|||
|
||||
## Periodic withdrawals of staking rewards (partial withdrawals)
|
||||
|
||||
Once the validator is configured with 0x01 withdrawal credentials, all staking rewards will be periodically withdrawn as long as the validator balance is above 32 ETH.
|
||||
Once the validator is configured with `0x01` withdrawal credentials, all staking rewards will be periodically withdrawn as long as the validator balance is above 32 ETH.
|
||||
No user action is required.
|
||||
|
||||
!!! info
|
||||
|
|
@ -53,7 +48,7 @@ To withdrawal the entire staked balance of your validator, you must perform a vo
|
|||
You won't be able to validate again with the same key.
|
||||
|
||||
!!! warning
|
||||
Make sure you've migrated your validator to 0x01 withdrawal credentials before exiting.
|
||||
Make sure you've migrated your validator to `0x01` withdrawal credentials before exiting.
|
||||
|
||||
The time required for the withdrawal to complete depends on multiple factors such as the total number of validators in the network, the number of other validators attempting to exit at the moment and the current time in the periodic withdrawals cycle.
|
||||
Under typical conditions, it's expected to take 2 to 7 days.
|
||||
|
|
|
|||
Loading…
Reference in New Issue