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

Update stale sections of the book (#3671)

Browse Source 
## Issue Addressed

Which issue # does this PR address?

## Proposed Changes

* Add v3.2 and v3.3 to database migrations table
* Remove docs on `--subscribe-all-subnets` and `--import-all-attestations` from redundancy docs
* Clarify that the merge has already occurred on the merge migration page
This commit is contained in:
Michael Sproul 2022-11-07 06:48:32 +00:00
parent 0655006e87
commit 253767ebc1
3 changed files with 18 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
book/src/database-migrations.md
View File

@ -24,6 +24,8 @@ validator client or the slasher**.
| v2.5.0 | Aug 2022 | v11 | yes |
| v3.0.0 | Aug 2022 | v11 | yes |
| v3.1.0 | Sep 2022 | v12 | yes |
| v3.2.0 | Oct 2022 | v12 | yes |
| v3.3.0 | TBD | v13 | yes |
> **Note**: All point releases (e.g. v2.3.1) are schema-compatible with the prior minor release
> (e.g. v2.3.0).

14
book/src/merge-migration.md
View File

@ -1,9 +1,8 @@
# Merge Migration
This document provides detail for users who want to run a merge-ready Lighthouse node.
This document provides detail for users who want to run a Lighthouse node on post-merge Ethereum.
> The merge is occurring on mainnet in September. You _must_ have a merge-ready setup by September 6
> 2022.
> The merge occurred on mainnet in September 2022.
## Necessary Configuration
@ -27,12 +26,9 @@ engine to a merge-ready version.
You must configure your node to be merge-ready before the Bellatrix fork occurs on the network
on which your node is operating.
* **Mainnet**: the Bellatrix fork is scheduled for epoch 144896, September 6 2022 11:34 UTC.
You must ensure your node configuration is updated before then in order to continue following
the chain. We recommend updating your configuration now.
* **Goerli (Prater)**, **Ropsten**, **Sepolia**, **Kiln**: the Bellatrix fork has already occurred.
You must have a merge-ready configuration right now.
* **Gnosis**: the Bellatrix fork has not yet been scheduled.
* **Mainnet**, **Goerli (Prater)**, **Ropsten**, **Sepolia**, **Kiln**: the Bellatrix fork has
already occurred. You must have a merge-ready configuration right now.
## Connecting to an execution engine

37
book/src/redundancy.md
View File

@ -55,42 +55,27 @@ 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:
- `--staking`: starts the HTTP API server and ensures the execution chain is synced.
- `--http`: starts the HTTP API server.
- `--http-address 0.0.0.0`: this allows *any* external IP address to access the
HTTP server (a firewall should be configured to deny unauthorized access to port
`5052`). This is only required if your backup node is on a different host.
- `--subscribe-all-subnets`: ensures that the beacon node subscribes to *all*
subnets, not just on-demand requests from validators.
- `--import-all-attestations`: ensures that the beacon node performs
aggregation on all seen attestations.
- `--execution-endpoint`: see [Merge Migration](./merge-migration.md).
- `--execution-jwt`: see [Merge Migration](./merge-migration.md).
Subsequently, one could use the following command to provide a backup beacon
node:
For example one could use the following command to provide a backup beacon node:
```bash
lighthouse bn \
--staking \
--http \
--http-address 0.0.0.0 \
--subscribe-all-subnets \
--import-all-attestations
--execution-endpoint http://localhost:8551 \
--execution-jwt /secrets/jwt.hex
```
### Resource usage of redundant Beacon Nodes
The `--subscribe-all-subnets` and `--import-all-attestations` flags typically
cause a significant increase in resource consumption. A doubling in CPU
utilization and RAM consumption is expected.
The increase in resource consumption is due to the fact that the beacon node is
now processing, validating, aggregating and forwarding *all* attestations,
whereas previously it was likely only doing a fraction of this work. Without
these flags, subscription to attestation subnets and aggregation of
attestations is only performed for validators which [explicitly request
subscriptions][subscribe-api].
There are 64 subnets and each validator will result in a subscription to *at
least* one subnet. So, using the two aforementioned flags will result in
resource consumption akin to running 64+ validators.
Prior to v3.2.0 fallback beacon nodes also required the `--subscribe-all-subnets` and
`--import-all-attestations` flags. These flags are no longer required as the validator client will
now broadcast subscriptions to all connected beacon nodes by default. This broadcast behaviour
can be disabled using the `--disable-run-on-all` flag for `lighthouse vc`.
## Redundant execution nodes