diff --git a/docs/the_nimbus_book/src/SUMMARY.md b/docs/the_nimbus_book/src/SUMMARY.md index e8b1ed447..b62e2fd78 100644 --- a/docs/the_nimbus_book/src/SUMMARY.md +++ b/docs/the_nimbus_book/src/SUMMARY.md @@ -28,7 +28,7 @@ # How-to (misc) - [Upgrade / downgrade Nimbus](./keep-updated.md) -- [Run an eth1 node](./eth1.md) +- [Run an Execution layer node](./eth1.md) - [Obtain Goerli ETH](./goerli-eth.md) - [Set up a systemd service](./beacon-node-systemd.md) - [Set up log rotation](./log-rotate.md) diff --git a/docs/the_nimbus_book/src/eth1.md b/docs/the_nimbus_book/src/eth1.md index 8069b1257..6153b68bf 100644 --- a/docs/the_nimbus_book/src/eth1.md +++ b/docs/the_nimbus_book/src/eth1.md @@ -1,15 +1,13 @@ -# Run an eth1 node +# Run an Execution layer node -In order to process incoming validator deposits from the eth1 chain, you'll need to run an eth1 client in parallel to your eth2 client. +In order to process incoming validator deposits from the Execution layer, you'll need to run an EL client in parallel to your CL client. -Validators are responsible for including new deposits when they propose blocks. And an eth1 client is needed to ensure your validator performs this task correctly. - -On this page we provide instructions for using Geth (however, any reputable eth1 client should do the trick). +On this page we provide instructions for using Geth (however, any reputable EL client shOuld do the trick). > **Note:** If you have a > 500GB SSD, and your [hardware](./hardware.md) can handle it, we strongly recommend running your own eth1 client. This will help ensure the network stays as decentralised as possible. If you can't however, the next best option is to set up a 3rd part provider like [infura](./infura-guide.md). ## Nimbus -In parallel to `nimbus-eth2` we are working hard on our [our exectution client](https://github.com/status-im/nimbus-eth1). While this is very much a project in development (i.e. not yet ready for public consumption), we welcome you to experiment with it. +In parallel to `nimbus-eth2` we are working hard on our [our EL client](https://github.com/status-im/nimbus-eth1). While this is very much a project in development (i.e. not yet ready for public consumption), we welcome you to experiment with it. ## Nethermind *TBC* diff --git a/docs/the_nimbus_book/src/keymanager-api.md b/docs/the_nimbus_book/src/keymanager-api.md index d2e0d36ba..e5e0e5210 100644 --- a/docs/the_nimbus_book/src/keymanager-api.md +++ b/docs/the_nimbus_book/src/keymanager-api.md @@ -4,6 +4,8 @@ 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. To enable it, start the beacon node with the `--keymanager` option enabled: diff --git a/docs/the_nimbus_book/src/networking.md b/docs/the_nimbus_book/src/networking.md index 66e4aa921..7cbe140ca 100644 --- a/docs/the_nimbus_book/src/networking.md +++ b/docs/the_nimbus_book/src/networking.md @@ -16,6 +16,8 @@ With this brand, you will also need to edit individual connections - in "Home Ne ## 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. + If your Peer count is low (less than `15`) and/or you repeatedly see either of the following warnings: `Peer count low, no new peers discovered...` diff --git a/docs/the_nimbus_book/src/pi-guide.md b/docs/the_nimbus_book/src/pi-guide.md index 93b1b68b5..c233a9ada 100644 --- a/docs/the_nimbus_book/src/pi-guide.md +++ b/docs/the_nimbus_book/src/pi-guide.md @@ -316,7 +316,7 @@ https://status-im.github.io/nimbus-eth2/eth1.html Please enter a Web3 provider URL: ``` -Enter your own secure websocket (`wss`) [endpoint](eth1.md). +Enter your web3 [endpoint](eth1.md). ### 15. Check for successful connection diff --git a/docs/the_nimbus_book/src/preparation.md b/docs/the_nimbus_book/src/preparation.md index a20d27c8d..81b07af4d 100644 --- a/docs/the_nimbus_book/src/preparation.md +++ b/docs/the_nimbus_book/src/preparation.md @@ -7,9 +7,9 @@ Please check that you are running the latest stable [Nimbus software release](ht > **Note:** If you are setting up your client before launch, it is your responsibility to check for any new software releases in the run up to launch. At the minimum you should check the [release page](https://github.com/status-im/nimbus-eth2/releases) weekly. -## More than 50 peers +## More than 15 peers -Please check that your node has at least 50 peers. To monitor your peer count, pay attention to the [`Slot start` messages in your logs](keep-an-eye.md#keep-track-of-your-syncing-progress). +Please check that your node has at least 15 peers. To monitor your peer count, pay attention to the [`Slot start` messages in your logs](keep-an-eye.md#keep-track-of-your-syncing-progress). ## Validator attached diff --git a/docs/the_nimbus_book/src/troubleshooting.md b/docs/the_nimbus_book/src/troubleshooting.md index 2b4e00a25..03b9cc8f8 100644 --- a/docs/the_nimbus_book/src/troubleshooting.md +++ b/docs/the_nimbus_book/src/troubleshooting.md @@ -38,7 +38,7 @@ No peers for topic, skipping publish... This means you've missed an attestation because either your peer count is too low, or the quality of your peers is lacking. -There can be several reasons behind why this is the case. The first thing to check is that your max peer count (`--max-peers`) hasn't been set too low. In order to ensure your attestations are published correctly, we recommend setting `--max-peers` to 60, at the *very least*. +There can be several reasons behind why this is the case. The first thing to check is that your max peer count (`--max-peers`) hasn't been set too low. In order to ensure your attestations are published correctly, `--max-peers` should be set to 70, at the *very least*. > Note that Nimbus manages peers slightly differently to other clients (we automatically connect to more peers than we actually use, in order not to have to do costly reconnects). As such, `--max-peers` is set to 160 by default. diff --git a/docs/the_nimbus_book/src/trusted-node-sync.md b/docs/the_nimbus_book/src/trusted-node-sync.md index 7e04fed70..6528fb999 100644 --- a/docs/the_nimbus_book/src/trusted-node-sync.md +++ b/docs/the_nimbus_book/src/trusted-node-sync.md @@ -1,5 +1,7 @@ # 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 will connect to the beacon chain network and start syncing automatically, a process that can take several days. Trusted node sync allows you to get started more quickly with Nimbus by fetching a recent checkpoint from a trusted node (we will expect it will save you 1 to 2 days). diff --git a/docs/the_nimbus_book/src/voluntary-exit.md b/docs/the_nimbus_book/src/voluntary-exit.md index bc0c740fe..1c8bd6908 100644 --- a/docs/the_nimbus_book/src/voluntary-exit.md +++ b/docs/the_nimbus_book/src/voluntary-exit.md @@ -24,5 +24,8 @@ build/nimbus_beacon_node deposits exit \ > **Note:** Make sure your `` is prefixed with `0x`. In other words the public key should look like `0x95e3...` +## `rest-url` parameter + +As of `v1.7.0` the `deposits exit` command can accept a `--rest-url` parameter. This means you can issue exits with any [REST API](./rest-api.md) compatible beacon node diff --git a/docs/the_nimbus_book/src/web3-backup.md b/docs/the_nimbus_book/src/web3-backup.md index d6cebd0d9..fda06cafc 100644 --- a/docs/the_nimbus_book/src/web3-backup.md +++ b/docs/the_nimbus_book/src/web3-backup.md @@ -2,7 +2,9 @@ It's a good idea to add a backup web3 provider in case your main one goes down. You can do this by simply repeating the `--web3-url` parameter on launch. -For example, if your primary eth1 node is a [local Geth](./eth1.md#geth), but you want to use [Infura](./infura-guide.md) as a backup you would run: +> Warning: As of `v1.7.0` Nimbus will no longer automagically rewrite HTTP(S) web3 URLs to their respective WebSocket alternatives. + +For example, if your primary EL client is a [local Geth](./eth1.md#geth), but you want to use [Infura](./infura-guide.md) as a backup you would run: ``` ./run-mainnet-beacon-node.sh \