book updates (#3388)

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)

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*

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:

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...`

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
 

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
 

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.
 

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).

docs/the_nimbus_book/src/voluntary-exit.md

@@ -24,5 +24,8 @@ build/nimbus_beacon_node deposits exit \
 
 > **Note:** Make sure your `<VALIDATOR_PUBLIC_KEY>` 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 
 
 

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 \