book: add trusted node sync to index

...and some doc updates

docs/the_nimbus_book/src/SUMMARY.md

@@ -8,11 +8,11 @@
 - [Run the beacon node](./quick-start.md)
 - [Run a validator](./run-a-validator.md)
 
-
 # How-to (beacon node)
 - [Install dependencies](./install.md)
 - [Build the beacon node](./build.md)
 - [Sync the beacon node](./start-syncing.md)
+  - [Trusted node sync](./trusted-node-sync.md)
 - [Add a backup web3 provider](./web3-backup.md)
 
 # How-to (validator)
@@ -47,7 +47,6 @@
 - [Migrate from another client](./migration.md)
 - [Validate with a Raspberry Pi](./pi-guide.md)
 
-
 # Downloads
 - [Download binaries](./binaries.md)
 - [Download Docker images](./docker.md)

docs/the_nimbus_book/src/start-syncing.md

@@ -1,12 +1,14 @@
 
 # Start syncing
 
-To minimize the amount of downtime, you should ensure that your beacon node is [completely synced](./keep-an-eye.md#keep-track-of-your-syncing-progress) before submitting your deposit.  If it's not fully synced you will miss attestations and proposals until it becomes synced.
+To minimize the amount of downtime, you should ensure that your beacon node is [completely synced](./keep-an-eye.md#keep-track-of-your-syncing-progress) before submitting your deposit.  If it's not fully synced you will miss attestations and proposals until it as finished syncing.
 
 This is particularly important if you are joining a network that's been running for a while since the sync could take some time.
 
 > **N.B.** In order to process incoming validator deposits from the eth1 chain, you'll need to run an eth1 client (**web3 provider**) in parallel to your eth2 client. See [here](./eth1.md) for instructions on how to do so.
 
+If you have access to a node that you trust, you can get started more quickly using [trusted node sync](./trusted-node-sync.md).
+
 ### Testnet
 
 To start syncing the `prater` testnet , from the `nimbus-eth2` repository, run:

docs/the_nimbus_book/src/trusted-node-sync.md

@@ -2,21 +2,13 @@
 
 When you start the beacon node 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 getting started more quickly by syncing with a single trusted node.
+Trusted node sync allows you to get started more quickly with Nimbus by fetching a recent checkpoint from a trusted node.
 
-To use trusted node sync, you must have access to a node that you trust completely that exposes the REST HTTP API. Should this node or your connection to it be compromised, your node will not be able to detect an attack, thus it is important that you use a node and a connection that you trust, for example a locally running node or an SSH tunnel.
+To use trusted node sync, you must have access to a node that you trust that exposes the REST HTTP API, for example a locally running backup node.
 
-## Verifying that you synced the correct chain
-
-When performing a trusted node sync, you can manually verify that the correct chain was synced by comparing the head hash  with other sources, such as friends, forums, chats and web sites. You can retrieve the current head from the node using:
-
-```
-# Make sure to enabled the `--rest` option when running your node:
+Should this node or your connection to it be compromised, your node will not be able to detect that it's being served false information.
 
-curl http://localhost:5052/eth/v1/beacon/blocks/head/root
-```
-
-The `head` root is also printed in the log output at regular intervals.
+It is possibly to use trusted node sync with a third-party API provider - follow the steps below to verify that the chain you were given corresponds to the canonical chain at the time.
 
 ## Performing a trusted node sync
 
@@ -38,15 +30,27 @@ build/nimbus_beacon_node trustedNodeSync --network:mainnet \
 
 **NOTE**
 
-Because trusted node sync by default copies all blocks via REST, if you use a service such as Infura, you might hit API limits - see the `--backfill` option.
+Because trusted node sync by default copies all blocks via REST, if you use a third-party service to sync from, you may hit API limits - see the `--backfill` option.
+
+## Verifying that you synced the correct chain
+
+When performing a trusted node sync, you can manually verify that the correct chain was synced by comparing the head hash with other sources, such as friends, forums, chats and web sites. You can retrieve the current head from the node using:
+
+```
+# Make sure to enabled the `--rest` option when running your node:
+
+curl http://localhost:5052/eth/v1/beacon/blocks/head/root
+```
+
+The `head` root is also printed in the log output at regular intervals.
 
 ## Block history
 
 By default, both the state and the full block history will be downloaded from the trusted node.
 
 It is possible to get started more quickly by delaying the backfill of the block history using the `--backfill=false` parameter. In this case, the beacon node will first sync to the current head so that it can start performing its duties, then backfill the blocks from the network.
 
-While backfilling blocks from the network, the node will not be conforming to the protocol and may be disconnected or lose reputation with other nodes.
+While it's backfilling blocks from the network, the node will be violating the beacon chain protocol and may be disconnected or lose reputation with other nodes.
 
 ## Sync point
 
@@ -64,12 +68,12 @@ If you have a state and a block file available, you can instead start the node u
 ```
 # Obtain a state and a block from a REST API - these must be in SSZ format:
 
-wget -o state.32000.ssz http://localhost:5052/eth/v2/debug/beacon/states/32000
-wget -o block.32000.ssz http://localhost:5052/eth/v2/beacon/blocks/32000
+curl -o state.32000.ssz -H 'Accept: application/octet-stream' http://localhost:5052/eth/v2/debug/beacon/states/32000
+curl -o block.32000.ssz -H 'Accept: application/octet-stream' http://localhost:5052/eth/v2/beacon/blocks/32000
 
 build/nimbus_beacon_node --data-dir:trusted --finalized-checkpoint-block=block.32000.ssz --finalized-checkpoint-state=state.32000.ssz
 ```
 
 ## Caveats
 
-A node synced using trusted node sync will not be able to serve historical requests from before the checkpoint. Future versions will resolve this issue.
+A node synced using trusted node sync will not be able to serve historical requests via the REST API from before the checkpoint. Future versions will resolve this issue.