Update Lighthouse Book for Electra features

.github/workflows/release.yml

@@ -221,7 +221,7 @@ jobs:
                   |Non-Staking Users| <TODO>|---|
 
                   *See [Update
-                  Priorities](https://lighthouse-book.sigmaprime.io/installation-priorities.html)
+                  Priorities](https://lighthouse-book.sigmaprime.io/installation_priorities.html)
                   more information about this table.*
 
                   ## All Changes
@@ -230,7 +230,7 @@ jobs:
 
                   ## Binaries
 
-                  [See pre-built binaries documentation.](https://lighthouse-book.sigmaprime.io/installation-binaries.html)
+                  [See pre-built binaries documentation.](https://lighthouse-book.sigmaprime.io/installation_binaries.html)
 
                   The binaries are signed with Sigma Prime's PGP key: `15E66D941F697E28F49381F426416DC3F30674B0`
 

account_manager/src/validator/exit.rs

@@ -27,7 +27,7 @@ pub const PASSWORD_PROMPT: &str = "Enter the keystore password";
 
 pub const DEFAULT_BEACON_NODE: &str = "http://localhost:5052/";
 pub const CONFIRMATION_PHRASE: &str = "Exit my validator";
-pub const WEBSITE_URL: &str = "https://lighthouse-book.sigmaprime.io/voluntary-exit.html";
+pub const WEBSITE_URL: &str = "https://lighthouse-book.sigmaprime.io/validator_voluntary_exit.html";
 
 pub fn cli_app() -> Command {
     Command::new("exit")

beacon_node/client/src/notifier.rs

@@ -353,7 +353,7 @@ async fn bellatrix_readiness_logging<T: BeaconChainTypes>(
         if !beacon_chain.is_time_to_prepare_for_capella(current_slot) {
             error!(
                 info = "you need an execution engine to validate blocks, see: \
-                https://lighthouse-book.sigmaprime.io/merge-migration.html",
+                https://lighthouse-book.sigmaprime.io/archived_merge_migration.html",
                 "Execution endpoint required"
             );
         }
@@ -433,7 +433,7 @@ async fn capella_readiness_logging<T: BeaconChainTypes>(
         if !beacon_chain.is_time_to_prepare_for_deneb(current_slot) {
             error!(
                 info = "you need a Capella enabled execution engine to validate blocks, see: \
-                           https://lighthouse-book.sigmaprime.io/merge-migration.html",
+                           https://lighthouse-book.sigmaprime.io/archived_merge_migration.html",
                 "Execution endpoint required"
             );
         }

book/src/SUMMARY.md

@@ -22,6 +22,7 @@
   * [Doppelganger Protection](./validator_doppelganger.md)
   * [Suggested Fee Recipient](./validator_fee_recipient.md)
   * [Validator Graffiti](./validator_graffiti.md)
+  * [Consolidation](./validator_consolidation.md)
 * [APIs](./api.md)
   * [Beacon Node API](./api_bn.md)
     * [Lighthouse API](./api_lighthouse.md)
@@ -61,8 +62,10 @@
   * [Development Environment](./contributing_setup.md)
 * [FAQs](./faq.md)
 * [Protocol Developers](./developers.md)
+  * [Lighthouse Architecture](./developers_architecture.md)
 * [Security Researchers](./security.md)
 * [Archived](./archived.md)
   * [Merge Migration](./archived_merge_migration.md)
   * [Raspberry Pi 4](./archived_pi.md)
   * [Key Management](./archived_key_management.md)
+  * [FAQ](./archived_faq.md)

book/src/advanced_blobs.md

@@ -6,7 +6,7 @@ In the Deneb network upgrade, one of the changes is the implementation of EIP-48
 
 1. What is the storage requirement for blobs?
 
-   We expect an additional increase of ~50 GB of storage requirement for blobs (on top of what is required by the consensus and execution clients database). The calculation is as below:
+   After Deneb, we expect an additional increase of ~50 GB of storage requirement for blobs (on top of what is required by the consensus and execution clients database). The calculation is as below:
 
    One blob is 128 KB in size. Each block can carry a maximum of 6 blobs. Blobs will be kept for 4096 epochs and pruned afterwards. This means that the maximum increase in storage requirement will be:
 
@@ -16,6 +16,8 @@ In the Deneb network upgrade, one of the changes is the implementation of EIP-48
 
    However, the blob base fee targets 3 blobs per block and it works similarly to how EIP-1559 operates in the Ethereum gas fee. Therefore, practically it is very likely to average to 3 blobs per blocks, which translates to a storage requirement of 48 GB.
 
+   After Electra, the target blobs is increased to 6 blobs per block. This means blobs storage is expected to use ~100GB of disk space.
+
 1. Do I have to add any flags for blobs?
 
    No, you can use the default values for blob-related flags, which means you do not need add or remove any flags.
@@ -25,7 +27,7 @@ In the Deneb network upgrade, one of the changes is the implementation of EIP-48
    Use the flag `--prune-blobs false` in the beacon node. The storage requirement will be:
 
    ```text
-   2**17 bytes * 3 blobs / block * 7200 blocks / day * 30 days = 79GB / month or 948GB / year
+   2**17 bytes * 6 blobs / block * 7200 blocks / day * 30 days = 158GB / month or 1896GB / year
    ```
 
    To keep blobs for a custom period, you may use the flag `--blob-prune-margin-epochs <EPOCHS>` which keeps blobs for 4096+EPOCHS specified in the flag.

book/src/advanced_database_migrations.md

@@ -7,7 +7,8 @@ been applied automatically and in a _backwards compatible_ way.
 
 However, backwards compatibility does not imply the ability to _downgrade_ to a prior version of
 Lighthouse after upgrading. To facilitate smooth downgrades, Lighthouse v2.3.0 and above includes a
-command for applying database downgrades.
+command for applying database downgrades. If a downgrade is available _from_ a schema version,
+it is listed in the table below under the "Downgrade available?" header.
 
 **Everything on this page applies to the Lighthouse _beacon node_, not to the
 validator client or the slasher**.
@@ -16,12 +17,8 @@ validator client or the slasher**.
 
 | Lighthouse version | Release date | Schema version | Downgrade available? |
 |--------------------|--------------|----------------|----------------------|
+| v7.0.0             | Apr 2025     | v22            | no                   |
 | v6.0.0             | Nov 2024     | v22            | no                   |
-| v5.3.0             | Aug 2024     | v21            | yes                  |
-| v5.2.0             | Jun 2024     | v19            | no                   |
-| v5.1.0             | Mar 2024     | v19            | no                   |
-| v5.0.0             | Feb 2024     | v19            | no                   |
-| v4.6.0             | Dec 2023     | v19            | no                   |
 
 > **Note**: All point releases (e.g. v4.4.1) are schema-compatible with the prior minor release
 > (e.g. v4.4.0).
@@ -209,8 +206,9 @@ Here are the steps to prune historic states:
 
 | Lighthouse version | Release date | Schema version | Downgrade available?                |
 |--------------------|--------------|----------------|-------------------------------------|
+| v7.0.0             | Apr 2025     | v22            | no                                  |
 | v6.0.0             | Nov 2024     | v22            | no                                  |
-| v5.3.0             | Aug 2024     | v21            | yes                                 |
+| v5.3.0             | Aug 2024     | v21            | yes before Electra using <= v7.0.0  |
 | v5.2.0             | Jun 2024     | v19            | yes before Deneb using <= v5.2.1    |
 | v5.1.0             | Mar 2024     | v19            | yes before Deneb using <= v5.2.1    |
 | v5.0.0             | Feb 2024     | v19            | yes before Deneb using <= v5.2.1    |

book/src/archived.md

@@ -1,3 +1,3 @@
 # Archived
 
-This section keeps the topics that are deprecated or less applicable for archived purposes.
+This section keeps the topics that are deprecated. Documentation in this section are for informational purposes only and will not be maintained.

book/src/archived_faq.md

@@ -0,0 +1,74 @@
+# Archived FAQ
+
+Note: The following FAQ is valid for mainnet before Electra. After Electra, [EIP6110 Supply validator deposits on chain](https://ethereum.org/en/roadmap/pectra/#6110) is implemented and the time taken to activate a validator can be as fast as 13 minutes.
+
+## Why does it take so long for a validator to be activated?
+
+After validators create their execution layer deposit transaction there are two waiting
+periods before they can start producing blocks and attestations:
+
+1. Waiting for the beacon chain to recognise the execution layer block containing the
+   deposit (generally takes ~13.6 hours).
+1. Waiting in the queue for validator activation.
+
+Detailed answers below:
+
+### 1. Waiting for the beacon chain to detect the execution layer deposit
+
+Since the beacon chain uses the execution layer for validator on-boarding, beacon chain
+validators must listen to event logs from the deposit contract. Since the
+latest blocks of the execution chain are vulnerable to re-orgs due to minor network
+partitions, beacon nodes follow the execution chain at a distance of 2048 blocks
+(~6.8 hours) (see
+[`ETH1_FOLLOW_DISTANCE`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/validator.md#process-deposit)).
+This follow distance protects the beacon chain from on-boarding validators that
+are likely to be removed due to an execution chain re-org.
+
+Now we know there's a 6.8 hours delay before the beacon nodes even _consider_ an
+execution layer block. Once they _are_ considering these blocks, there's a voting period
+where beacon validators vote on which execution block hash to include in the beacon chain. This
+period is defined as 64 epochs (~6.8 hours, see
+[`ETH1_VOTING_PERIOD`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#time-parameters)).
+During this voting period, each beacon block producer includes an
+[`Eth1Data`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#eth1data)
+in their block which counts as a vote towards what that validator considers to
+be the head of the execution chain at the start of the voting period (with respect
+to `ETH1_FOLLOW_DISTANCE`, of course). You can see the exact voting logic
+[here](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/validator.md#eth1-data).
+
+These two delays combined represent the time between an execution layer deposit being
+included in an execution data vote and that validator appearing in the beacon chain.
+The `ETH1_FOLLOW_DISTANCE` delay causes a minimum delay of ~6.8 hours and
+`ETH1_VOTING_PERIOD` means that if a validator deposit happens just _before_
+the start of a new voting period then they might not notice this delay at all.
+However, if the validator deposit happens just _after_ the start of the new
+voting period the validator might have to wait ~6.8 hours for next voting
+period. In times of very severe network issues, the network may even fail
+to vote in new execution layer blocks, thus stopping all new validator deposits and causing the wait to be longer.
+
+### 2. Waiting for a validator to be activated
+
+If a validator has provided an invalid public key or signature, they will
+_never_ be activated.
+They will simply be forgotten by the beacon chain! But, if those parameters were
+correct, once the execution layer delays have elapsed and the validator appears in the
+beacon chain, there's _another_ delay before the validator becomes "active"
+(canonical definition
+[here](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#is_active_validator)) and can start producing blocks and attestations.
+
+Firstly, the validator won't become active until their beacon chain balance is
+equal to or greater than
+[`MAX_EFFECTIVE_BALANCE`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#gwei-values)
+(32 ETH on mainnet, usually 3.2 ETH on testnets). Once this balance is reached,
+the validator must wait until the start of the next epoch (up to 6.4 minutes)
+for the
+[`process_registry_updates`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#registry-updates)
+routine to run. This routine activates validators with respect to a [churn
+limit](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#get_validator_churn_limit);
+it will only allow the number of validators to increase (churn) by a certain
+amount. If a new validator isn't within the churn limit from the front of the queue,
+they will need to wait another epoch (6.4 minutes) for their next chance. This
+repeats until the queue is cleared. The churn limit for validators joining the beacon chain is capped at 8 per epoch or 1800 per day. If, for example, there are 9000 validators waiting to be activated, this means that the waiting time can take up to 5 days.
+
+Once a validator has been activated, congratulations! It's time to
+produce blocks and attestations!

book/src/developers_architecture.md

@@ -0,0 +1,5 @@
+# Lighthouse architecture
+
+A technical walkthrough on Lighthouse based on a Lighthouse architecture below can be found at: [Lighthouse technical walkthrough](https://www.youtube.com/watch?v=pLHhTh_vGZ0)
+
+![Lighthouse architecture](imgs/developers_architecture.svg)