cerc-io/lighthouse
16
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity

Fixing a few typos / documentation (#3531)

Browse Source 
Fixing a few typos in the documentation
This commit is contained in:
omahs 2022-09-05 04:50:48 +00:00
parent cae40731a2
commit 95c56630a6
4 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
book/src/advanced-datadir.md
View File

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

4
book/src/advanced_networking.md
View File

@ -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,

10
book/src/faq.md
View File

@ -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

4
book/src/redundancy.md
View File

@ -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: