gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-04-17 21:08:32 +00:00
Code Issues 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
Download Patch File Download Diff File Expand all files Collapse all files

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,