diff --git a/book/src/advanced-datadir.md b/book/src/advanced-datadir.md index 9f81112bdd..074857346e 100644 --- a/book/src/advanced-datadir.md +++ b/book/src/advanced-datadir.md @@ -55,5 +55,5 @@ In this case, the user could solve this warn by following these steps: 1. Restarting the BN process Although there are no known issues with using backwards compatibility functionality, having split -directories is likely to cause confusion for users. Therefore, we recommend affected users migrate +directories is likely to cause confusion for users. Therefore, we recommend that affected users migrate to a consolidated directory structure. diff --git a/book/src/advanced_networking.md b/book/src/advanced_networking.md index 71155a1c23..d6fcb82a6b 100644 --- a/book/src/advanced_networking.md +++ b/book/src/advanced_networking.md @@ -22,7 +22,7 @@ Having a large peer count means that your node must act as an honest RPC server to all your connected peers. If there are many that are syncing, they will often be requesting a large number of blocks from your node. This means your node must perform a lot of work reading and responding to these peers. If your -node is over-loaded with peers and cannot respond in time, other Lighthouse +node is overloaded with peers and cannot respond in time, other Lighthouse peers will consider you non-performant and disfavour you from their peer stores. Your node will also have to handle and manage the gossip and extra bandwidth that comes from having these extra peers. Having a non-responsive @@ -63,7 +63,7 @@ settings allow you construct your initial ENR. Their primary intention is for setting up boot-like nodes and having a contactable ENR on boot. On normal operation of a Lighthouse node, none of these flags need to be set. Setting these flags incorrectly can lead to your node being incorrectly added to the -global DHT which will degrades the discovery process for all Ethereum consensus peers. +global DHT which will degrade the discovery process for all Ethereum consensus peers. The ENR of a Lighthouse node is initially set to be non-contactable. The in-built discovery mechanism can determine if your node is publicly accessible, diff --git a/book/src/faq.md b/book/src/faq.md index 6692d61495..5bfae3fa87 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -1,14 +1,14 @@ # Frequently Asked Questions - [Why does it take so long for a validator to be activated?](#why-does-it-take-so-long-for-a-validator-to-be-activated) -- [Do I need to set up any port mappings](#do-i-need-to-set-up-any-port-mappings) +- [Do I need to set up any port mappings?](#do-i-need-to-set-up-any-port-mappings) - [I have a low peer count and it is not increasing](#i-have-a-low-peer-count-and-it-is-not-increasing) - [What should I do if I lose my slashing protection database?](#what-should-i-do-if-i-lose-my-slashing-protection-database) - [How do I update lighthouse?](#how-do-i-update-lighthouse) - [I can't compile lighthouse](#i-cant-compile-lighthouse) -- [What is "Syncing deposit contract block cache"](#what-is-syncing-deposit-contract-block-cache) +- [What is "Syncing deposit contract block cache"?](#what-is-syncing-deposit-contract-block-cache) - [Can I use redundancy in my staking setup?](#can-i-use-redundancy-in-my-staking-setup) -- [How can I monitor my validators](#how-can-i-monitor-my-validators) +- [How can I monitor my validators?](#how-can-i-monitor-my-validators) ### Why does it take so long for a validator to be activated? @@ -86,7 +86,7 @@ repeats until the queue is cleared. Once a validator has been activated, there's no more waiting! It's time to produce blocks and attestations! -### Do I need to set up any port mappings +### Do I need to set up any port mappings? It is not strictly required to open any ports for Lighthouse to connect and participate in the network. Lighthouse should work out-of-the-box. However, if @@ -154,7 +154,7 @@ You will just also need to make sure the code you have checked out is up to date See [here.](./installation-source.md#troubleshooting) -### What is "Syncing deposit contract block cache" +### What is "Syncing deposit contract block cache"? ``` Nov 30 21:04:28.268 WARN Syncing deposit contract block cache est_blocks_remaining: initializing deposits, service: slot_notifier diff --git a/book/src/redundancy.md b/book/src/redundancy.md index d4156832bd..dae7ac51fe 100644 --- a/book/src/redundancy.md +++ b/book/src/redundancy.md @@ -42,7 +42,7 @@ There are a few interesting properties about the list of `--beacon-nodes`: - *Synced is preferred*: the validator client prefers a synced beacon node over one that is still syncing. - *Failure is sticky*: if a beacon node fails, it will be flagged as offline - and wont be retried again for the rest of the slot (12 seconds). This helps prevent the impact + and won't be retried again for the rest of the slot (12 seconds). This helps prevent the impact of time-outs and other lengthy errors. > Note: When supplying multiple beacon nodes the `http://localhost:5052` address must be explicitly @@ -51,7 +51,7 @@ There are a few interesting properties about the list of `--beacon-nodes`: ### Configuring a redundant Beacon Node -In our previous example we listed `http://192.168.1.1:5052` as a redundant +In our previous example, we listed `http://192.168.1.1:5052` as a redundant node. Apart from having sufficient resources, the backup node should have the following flags: