From 0209a51155fbb5fcea3f3d4c3b798006358e6e11 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Wed, 2 Apr 2025 15:22:31 +0800 Subject: [PATCH 01/26] fix wrong name files --- .../{archived-key-management.md => archived_key_management.md} | 0 .../{archived-merge-migration.md => archived_merge_migration.md} | 0 2 files changed, 0 insertions(+), 0 deletions(-) rename book/src/{archived-key-management.md => archived_key_management.md} (100%) rename book/src/{archived-merge-migration.md => archived_merge_migration.md} (100%) diff --git a/book/src/archived-key-management.md b/book/src/archived_key_management.md similarity index 100% rename from book/src/archived-key-management.md rename to book/src/archived_key_management.md diff --git a/book/src/archived-merge-migration.md b/book/src/archived_merge_migration.md similarity index 100% rename from book/src/archived-merge-migration.md rename to book/src/archived_merge_migration.md From e2f8ed555c74d15632d8c0eba99b277330bb7e0c Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Wed, 2 Apr 2025 21:31:12 +0800 Subject: [PATCH 02/26] typo --- book/src/validator_management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/src/validator_management.md b/book/src/validator_management.md index 18abfb15381..3bfac37ac6b 100644 --- a/book/src/validator_management.md +++ b/book/src/validator_management.md @@ -151,7 +151,7 @@ ensure their `secrets-dir` is organised as below: ### Manual configuration The automatic validator discovery process works out-of-the-box with validators -that are created using the `lighthouse account validator new` command. The +that are created using the `lighthouse account validator create` command. The details of this process are only interesting to those who are using keystores generated with another tool or have a non-standard requirements. From 362c0f60daba95504d62ddab782148a011c741d5 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Thu, 3 Apr 2025 10:41:16 +0800 Subject: [PATCH 03/26] Add blobs disk space Electra --- book/src/advanced_blobs.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/book/src/advanced_blobs.md b/book/src/advanced_blobs.md index aa995b8e1d5..f711ca22df9 100644 --- a/book/src/advanced_blobs.md +++ b/book/src/advanced_blobs.md @@ -5,8 +5,8 @@ In the Deneb network upgrade, one of the changes is the implementation of EIP-48 ## FAQ 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: @@ -15,6 +15,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? From c479f768eabc16e7c90cd9417d2c1274ed167b91 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Fri, 4 Apr 2025 23:25:37 +0800 Subject: [PATCH 04/26] EL withdrawals --- book/src/advanced_blobs.md | 6 +-- book/src/archived.md | 2 +- book/src/archived_faq.md | 74 ++++++++++++++++++++++++++++ book/src/faq.md | 72 --------------------------- book/src/validator_sweep.md | 4 ++ book/src/validator_voluntary_exit.md | 3 ++ 6 files changed, 85 insertions(+), 76 deletions(-) create mode 100644 book/src/archived_faq.md diff --git a/book/src/advanced_blobs.md b/book/src/advanced_blobs.md index f711ca22df9..27f69aa5b7e 100644 --- a/book/src/advanced_blobs.md +++ b/book/src/advanced_blobs.md @@ -5,7 +5,7 @@ In the Deneb network upgrade, one of the changes is the implementation of EIP-48 ## FAQ 1. What is the storage requirement for blobs? - + 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: @@ -15,8 +15,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. + + 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? diff --git a/book/src/archived.md b/book/src/archived.md index 7b6e4b7e8ef..c39443656fb 100644 --- a/book/src/archived.md +++ b/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. diff --git a/book/src/archived_faq.md b/book/src/archived_faq.md new file mode 100644 index 00000000000..2cc53c1df91 --- /dev/null +++ b/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](Supply validator deposits on chain) 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! diff --git a/book/src/faq.md b/book/src/faq.md index a741834501c..3e224ea5460 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -17,7 +17,6 @@ ## [Validator](#validator-1) -- [Why does it take so long for a validator to be activated?](#vc-activation) - [Can I use redundancy in my staking setup?](#vc-redundancy) - [I am missing attestations. Why?](#vc-missed-attestations) - [Sometimes I miss the attestation head vote, resulting in penalty. Is this normal?](#vc-head-vote) @@ -204,77 +203,6 @@ This is a known [bug](https://github.com/sigp/lighthouse/issues/3707) that will ## Validator -### 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! - ### Can I use redundancy in my staking setup? You should **never** use duplicate/redundant validator keypairs or validator clients (i.e., don't diff --git a/book/src/validator_sweep.md b/book/src/validator_sweep.md index b707988e84c..f21266009cf 100644 --- a/book/src/validator_sweep.md +++ b/book/src/validator_sweep.md @@ -5,6 +5,10 @@ After the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12 - if a validator has a withdrawal credential type `0x00`, the rewards will continue to accumulate and will be locked in the beacon chain. - if a validator has a withdrawal credential type `0x01`, any rewards above 32ETH will be periodically withdrawn to the withdrawal address. This is also known as the "validator sweep", i.e., once the "validator sweep" reaches your validator's index, your rewards will be withdrawn to the withdrawal address. The validator sweep is automatic and it does not incur any fees to withdraw. +## Partial withdrawals via the execution layer + +With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x02 withdrawal credentials can partially withdraw the staked fund via the execution layer by sending a transaction using the withdrawal address. You can withdraw up until the validator balance is 32 ETH. For example, if the validator balance is 40 ETH, you can withdraw up to 8 ETH. You can use [Siren](./ui.md) or the Staking launchpad to execute partial withdrawals. + ## FAQ 1. How to know if I have the withdrawal credentials type `0x00` or `0x01`? diff --git a/book/src/validator_voluntary_exit.md b/book/src/validator_voluntary_exit.md index 6261f2e2675..d6e450ccad9 100644 --- a/book/src/validator_voluntary_exit.md +++ b/book/src/validator_voluntary_exit.md @@ -57,7 +57,10 @@ Current epoch: 29946, Exit epoch: 29951, Withdrawable epoch: 30207 Please keep your validator running till exit epoch Exit epoch in approximately 1920 secs ``` +## Exit via the execution layer +The voluntary exit above is via the consensus layer. With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x01 and 0x02 withdrawal credentials can also exit their validators via the execution layer by sending a transaction using the withdrawal address. You can use [Siren](./ui.md) or the Staking launchpad to exit validators. + ## Full withdrawal of staked fund After the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12th April 2023, if a user initiates a voluntary exit, they will receive the full staked funds to the withdrawal address, provided that the validator has withdrawal credentials of type `0x01`. For more information on how fund withdrawal works, please visit [Ethereum.org](https://ethereum.org/en/staking/withdrawals/#how-do-withdrawals-work) website. From b571270e50885d82014aa69eeb86ea3c4aea820b Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Sat, 5 Apr 2025 20:56:55 +0800 Subject: [PATCH 05/26] Add consolidation --- book/src/validator_consolidation.md | 29 ++++++++++++++++++++++++++++ book/src/validator_sweep.md | 2 +- book/src/validator_voluntary_exit.md | 5 +++-- 3 files changed, 33 insertions(+), 3 deletions(-) create mode 100644 book/src/validator_consolidation.md diff --git a/book/src/validator_consolidation.md b/book/src/validator_consolidation.md new file mode 100644 index 00000000000..5404b8b0512 --- /dev/null +++ b/book/src/validator_consolidation.md @@ -0,0 +1,29 @@ +# Consolidation + +With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, the effective balance of a validator can be up to 2048 ETH. This is done by updating the validator withdrawal credential to type 0x02. + +With 0x02 withdrawal credential, it is therefore possible to consolidate two or more validators into a single validator with a higher effective balance. Let's take a look at an example: Initially, validators A and B are both with 0x01 withdrawal credentials with 32 ETH. Say we want to consolidate the balance of validator B to the balance of validator A, so that the balance of validator A becomes 64 ETH. These are the steps: + +1. Update the withdrawal credential of validator A to 0x02. You can do this using [Siren](./ui.md) or the staking launchpad. Select: + - source validator: validator A + - target validator: validator A + > Note: A validator with withdrawal credential type 0x02 cannot be reverted to 0x01, except that the validator exits and make a fresh deposit. + +2. Perform consolidation by selecting: + - source validator: validator B + - target validator: validator A + and then execute the transaction. + + Depending on the exit and deposit queue, the process could take from a day to weeks. The outcome is: + - validator A has 64 ETH + - validator B has 0 ETH (i.e., validator B has exited the beacon chain) + +The consolidation process can be repeated to consolidate more validators into validator A. + +It is important to note that there are some conditions required to perform consolidation, a few common ones are: + +- the **withdrawal address** of the source and target validators **must be the same**. +- the _target validator_ **must** have a withdrawal credential **type 0x02**. The source validator could have a 0x01 or 0x02 withdrawal credential. +- the source validator must be active for at least 256 epochs to be able to perform consolidation. + +Note that if a user were to send a consolidation transaction that does not meet one or more of the conditions, the transaction can still be accepted by the execution layer. However, the consolidation will fail once it reaches the consensus layer (where the checks are performed). Therefore, it is recommended to check that the conditions are fulfilled before sending a consolidation transaction. diff --git a/book/src/validator_sweep.md b/book/src/validator_sweep.md index f21266009cf..9b2cdd5f2bc 100644 --- a/book/src/validator_sweep.md +++ b/book/src/validator_sweep.md @@ -7,7 +7,7 @@ After the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12 ## Partial withdrawals via the execution layer -With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x02 withdrawal credentials can partially withdraw the staked fund via the execution layer by sending a transaction using the withdrawal address. You can withdraw up until the validator balance is 32 ETH. For example, if the validator balance is 40 ETH, you can withdraw up to 8 ETH. You can use [Siren](./ui.md) or the Staking launchpad to execute partial withdrawals. +With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x02 withdrawal credentials can partially withdraw the staked fund via the execution layer by sending a transaction using the withdrawal address. You can withdraw up until the validator balance is 32 ETH. For example, if the validator balance is 40 ETH, you can withdraw up to 8 ETH. You can use [Siren](./ui.md) or the Staking launchpad to execute partial withdrawals. ## FAQ diff --git a/book/src/validator_voluntary_exit.md b/book/src/validator_voluntary_exit.md index d6e450ccad9..9b9f6c2b555 100644 --- a/book/src/validator_voluntary_exit.md +++ b/book/src/validator_voluntary_exit.md @@ -57,10 +57,11 @@ Current epoch: 29946, Exit epoch: 29951, Withdrawable epoch: 30207 Please keep your validator running till exit epoch Exit epoch in approximately 1920 secs ``` + ## Exit via the execution layer -The voluntary exit above is via the consensus layer. With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x01 and 0x02 withdrawal credentials can also exit their validators via the execution layer by sending a transaction using the withdrawal address. You can use [Siren](./ui.md) or the Staking launchpad to exit validators. - +The voluntary exit above is via the consensus layer. With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x01 and 0x02 withdrawal credentials can also exit their validators via the execution layer by sending a transaction using the withdrawal address. You can use [Siren](./ui.md) or the Staking launchpad to exit validators. + ## Full withdrawal of staked fund After the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12th April 2023, if a user initiates a voluntary exit, they will receive the full staked funds to the withdrawal address, provided that the validator has withdrawal credentials of type `0x01`. For more information on how fund withdrawal works, please visit [Ethereum.org](https://ethereum.org/en/staking/withdrawals/#how-do-withdrawals-work) website. From 24db0807ef90ae20a1043e4f3a9117c2143ec184 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 08:55:00 +0800 Subject: [PATCH 06/26] update book links --- .github/workflows/release.yml | 4 ++-- account_manager/src/validator/exit.rs | 2 +- beacon_node/client/src/notifier.rs | 4 ++-- book/src/faq.md | 2 +- book/src/validator_voluntary_exit.md | 2 +- scripts/tests/doppelganger_protection.sh | 4 ++-- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index cfba601fad6..d8a52dd0101 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -221,7 +221,7 @@ jobs: |Non-Staking Users| |---| *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` diff --git a/account_manager/src/validator/exit.rs b/account_manager/src/validator/exit.rs index ea1a24da1ff..8a2cdb8400a 100644 --- a/account_manager/src/validator/exit.rs +++ b/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") diff --git a/beacon_node/client/src/notifier.rs b/beacon_node/client/src/notifier.rs index d103d48dfb1..53c9c85c001 100644 --- a/beacon_node/client/src/notifier.rs +++ b/beacon_node/client/src/notifier.rs @@ -353,7 +353,7 @@ async fn bellatrix_readiness_logging( 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( 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" ); } diff --git a/book/src/faq.md b/book/src/faq.md index 3e224ea5460..26f00f0ae05 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -251,7 +251,7 @@ Another possible reason for missing the head vote is due to a chain "reorg". A r ### Can I submit a voluntary exit message without running a beacon node? -Yes. Beaconcha.in provides the tool to broadcast the message. You can create the voluntary exit message file with [ethdo](https://github.com/wealdtech/ethdo/releases/tag/v1.30.0) and submit the message via the [beaconcha.in](https://beaconcha.in/tools/broadcast) website. A guide on how to use `ethdo` to perform voluntary exit can be found [here](https://github.com/eth-educators/ethstaker-guides/blob/main/docs/voluntary-exit.md). +Yes. Beaconcha.in provides the tool to broadcast the message. You can create the voluntary exit message file with [ethdo](https://github.com/wealdtech/ethdo/releases/tag/v1.30.0) and submit the message via the [beaconcha.in](https://beaconcha.in/tools/broadcast) website. A guide on how to use `ethdo` to perform voluntary exit can be found [here](https://github.com/eth-educators/ethstaker-guides/blob/main/docs/validator_voluntary_exit.md). It is also noted that you can submit your BLS-to-execution-change message to update your withdrawal credentials from type `0x00` to `0x01` using the same link. diff --git a/book/src/validator_voluntary_exit.md b/book/src/validator_voluntary_exit.md index 9b9f6c2b555..e5035b97845 100644 --- a/book/src/validator_voluntary_exit.md +++ b/book/src/validator_voluntary_exit.md @@ -45,7 +45,7 @@ WARNING: WARNING: THIS IS AN IRREVERSIBLE OPERATION -PLEASE VISIT https://lighthouse-book.sigmaprime.io/voluntary-exit.html +PLEASE VISIT https://lighthouse-book.sigmaprime.io/validator_voluntary_exit.html TO MAKE SURE YOU UNDERSTAND THE IMPLICATIONS OF A VOLUNTARY EXIT. Enter the exit phrase from the above URL to confirm the voluntary exit: diff --git a/scripts/tests/doppelganger_protection.sh b/scripts/tests/doppelganger_protection.sh index 80070a07918..8e2eaa623a1 100755 --- a/scripts/tests/doppelganger_protection.sh +++ b/scripts/tests/doppelganger_protection.sh @@ -128,7 +128,7 @@ if [[ "$BEHAVIOR" == "success" ]]; then # Sleep three epochs, then make sure all validators were active in epoch 2. Use # `is_previous_epoch_target_attester` from epoch 3 for a complete view of epoch 2 inclusion. # - # See: https://lighthouse-book.sigmaprime.io/validator-inclusion.html + # See: https://lighthouse-book.sigmaprime.io/api_validator_inclusion.html echo "Waiting three epochs..." sleep $(( $SECONDS_PER_SLOT * 32 * 3 )) @@ -156,7 +156,7 @@ if [[ "$BEHAVIOR" == "success" ]]; then # Sleep two epochs, then make sure all validators were active in epoch 4. Use # `is_previous_epoch_target_attester` from epoch 5 for a complete view of epoch 4 inclusion. # - # See: https://lighthouse-book.sigmaprime.io/validator-inclusion.html + # See: https://lighthouse-book.sigmaprime.io/api_validator_inclusion.html echo "Waiting two more epochs..." sleep $(( $SECONDS_PER_SLOT * 32 * 2 )) for val in 0x*; do From e346bb80ee92dad54c6ef51c760ce8c465608c5c Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 09:43:42 +0800 Subject: [PATCH 07/26] Add Lighthouse architecture --- book/src/SUMMARY.md | 1 + book/src/developers_architecture.md | 4 ++++ book/src/imgs/developers_architecture.svg | 4 ++++ 3 files changed, 9 insertions(+) create mode 100644 book/src/developers_architecture.md create mode 100644 book/src/imgs/developers_architecture.svg diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index 3d09e3a6a5a..e16e5d38230 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -61,6 +61,7 @@ * [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) diff --git a/book/src/developers_architecture.md b/book/src/developers_architecture.md new file mode 100644 index 00000000000..c22f6ede9a5 --- /dev/null +++ b/book/src/developers_architecture.md @@ -0,0 +1,4 @@ +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) + diff --git a/book/src/imgs/developers_architecture.svg b/book/src/imgs/developers_architecture.svg new file mode 100644 index 00000000000..66c9c0ec892 --- /dev/null +++ b/book/src/imgs/developers_architecture.svg @@ -0,0 +1,4 @@ + + + +
p2p network
p2p network
rust-libp2p
rust-libp2p
lighthouse_network
lighthouse_network
gossipsub
gossipsub
http_api
http_api
validator client
validator client
crypto
crypto
bls
bls
blst
blst
kzg
kzg
ckzg
ckzg
discv5
discv5
slasher
slasher
store
store
execution_layer
execution_layer
execution client
execution client
operation_pool
operation_pool
mev-boost
mev-boost
builder_client
builder_client
beacon_processor
beacon_processor
tokio
tokio
network
network
gossip_methods
gossip_methods
rpc_methods
rpc_methods
sync
sync
beacon_chain
beacon_chain
block_verification
block_verification
attestation_verification
attestation_verificati...
blob_verification
blob_verification
blob_verification
blob_verification
light_client_*
light_client_*
block_verification
block_verification
import_block
import_block
produce_block
produce_block
Linux/macOS/Windows
Linux/macOS/Windows
Legend
Legend
= internal crate
= internal crate
= external crate
= external crate
= file
= file
= function/method
= function/method
= external service/component
= external service/compone...
consensus
consensus
types
types
state_processing
state_processing
ethereum_ssz
ethereum_ssz
tree_hash
tree_hash
milhouse
milhouse
fork_choice
fork_choice
merkle_proof
merkle_proof
sha2
sha2
leveldb
leveldb \ No newline at end of file From 36222ed2bcbcfeff78b73f174fc76a4d3cd3af15 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 10:00:35 +0800 Subject: [PATCH 08/26] Update database schema version --- book/src/advanced_database_migrations.md | 4 +++- book/src/developers_architecture.md | 1 - 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/book/src/advanced_database_migrations.md b/book/src/advanced_database_migrations.md index a9bfb00ccda..ea5be6c28be 100644 --- a/book/src/advanced_database_migrations.md +++ b/book/src/advanced_database_migrations.md @@ -16,7 +16,9 @@ validator client or the slasher**. | Lighthouse version | Release date | Schema version | Downgrade available? | |--------------------|--------------|----------------|----------------------| -| v6.0.0 | Nov 2024 | v22 | no | +| v7.0.0 | April 2025 | v22 | no | +| v6.0.1 | Dec 2024 | v22 | yes before Electra using <= 7.0.0 | +| v6.0.0 | Nov 2024 | v22 | yes before Electra using <= 7.0.0 | | v5.3.0 | Aug 2024 | v21 | yes | | v5.2.0 | Jun 2024 | v19 | no | | v5.1.0 | Mar 2024 | v19 | no | diff --git a/book/src/developers_architecture.md b/book/src/developers_architecture.md index c22f6ede9a5..cfda2dd34fc 100644 --- a/book/src/developers_architecture.md +++ b/book/src/developers_architecture.md @@ -1,4 +1,3 @@ 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) - From a3302686923c62fcdf1afdd83188d8946ffcbad3 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 10:02:37 +0800 Subject: [PATCH 09/26] Revise blob storage --- book/src/advanced_blobs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/src/advanced_blobs.md b/book/src/advanced_blobs.md index 27f69aa5b7e..524f70219f1 100644 --- a/book/src/advanced_blobs.md +++ b/book/src/advanced_blobs.md @@ -27,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 ` which keeps blobs for 4096+EPOCHS specified in the flag. From 2ad5bd98ea50e030b45c138fb6e2f92149b68ae3 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 10:59:07 +0800 Subject: [PATCH 10/26] Update delayed head block time component --- book/src/faq.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/book/src/faq.md b/book/src/faq.md index 26f00f0ae05..74a2a86cafc 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -189,13 +189,20 @@ This suggests that the computer resources are being overwhelmed. It could be due ### My beacon node logs `ERRO Aggregate attestation queue full`, what should I do? -An example of the full log is shown below: +Some examplex of the full log is shown below: ```text ERRO Aggregate attestation queue full, queue_len: 4096, msg: the system has insufficient resources for load, module: network::beacon_processor:1542 +ERRO Attestation delay queue is full msg: check system clock, queue_size: 16384, service: bproc ``` -This suggests that the computer resources are being overwhelmed. It could be due to high CPU usage or high disk I/O usage. This can happen, e.g., when the beacon node is downloading historical blocks, or when the execution client is syncing. The error will disappear when the resources used return to normal or when the node is synced. +This suggests that the computer resources are being overwhelmed. It could be due to high CPU usage or high disk I/O usage. Some common reasons are: +- when the beacon node is downloading historical blocks +- the execution client is syncing +- disk IO is being overwhelmed +- parallel API queries to the beacon node + +If the node is syncing or downloading historical blocks, the error should disappear when the resources used return to normal or when the node is synced. ### My beacon node logs `WARN Failed to finalize deposit cache`, what should I do? @@ -227,7 +234,7 @@ Another cause for missing attestations is the block arriving late, or there are An example of the log: (debug logs can be found under `$datadir/beacon/logs`): ```text -Delayed head block, set_as_head_time_ms: 27, imported_time_ms: 168, attestable_delay_ms: 4209, available_delay_ms: 4186, execution_time_ms: 201, blob_delay_ms: 3815, observed_delay_ms: 3984, total_delay_ms: 4381, slot: 1886014, proposer_index: 733, block_root: 0xa7390baac88d50f1cbb5ad81691915f6402385a12521a670bbbd4cd5f8bf3934, service: beacon, module: beacon_chain::canonical_head:1441 +Delayed head block, set_as_head_time_ms: 27, imported_time_ms: 168, attestable_delay_ms: 4209, available_delay_ms: 4186, execution_time_ms: 201, consensus_time: 211 ms, blob_delay_ms: 3815, observed_delay_ms: 3984, total_delay_ms: 4591, slot: 1886014, proposer_index: 733, block_root: 0xa7390baac88d50f1cbb5ad81691915f6402385a12521a670bbbd4cd5f8bf3934, service: beacon, module: beacon_chain::canonical_head:1441 ``` The field to look for is `attestable_delay`, which defines the time when a block is ready for the validator to attest. If the `attestable_delay` is greater than 4s which has past the window of attestation, the attestation will fail. In the above example, the delay is mostly caused by late block observed by the node, as shown in `observed_delay`. The `observed_delay` is determined mostly by the proposer and partly by your networking setup (e.g., how long it took for the node to receive the block). Ideally, `observed_delay` should be less than 3 seconds. In this example, the validator failed to attest the block due to the block arriving late. From ddd801723c78118abe0d22a364e677e289f27a2a Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 11:16:40 +0800 Subject: [PATCH 11/26] Update delayed log --- book/src/faq.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/book/src/faq.md b/book/src/faq.md index 74a2a86cafc..0495f765649 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -234,15 +234,16 @@ Another cause for missing attestations is the block arriving late, or there are An example of the log: (debug logs can be found under `$datadir/beacon/logs`): ```text -Delayed head block, set_as_head_time_ms: 27, imported_time_ms: 168, attestable_delay_ms: 4209, available_delay_ms: 4186, execution_time_ms: 201, consensus_time: 211 ms, blob_delay_ms: 3815, observed_delay_ms: 3984, total_delay_ms: 4591, slot: 1886014, proposer_index: 733, block_root: 0xa7390baac88d50f1cbb5ad81691915f6402385a12521a670bbbd4cd5f8bf3934, service: beacon, module: beacon_chain::canonical_head:1441 +DEBG Delayed head block, set_as_head_time_ms: 37, imported_time_ms: 1824, attestable_delay_ms: 3660, available_delay_ms: 3491, execution_time_ms: 78, consensus_time_ms: 161, blob_delay_ms: 3291, observed_delay_ms: 3250, total_delay_ms: 5352, slot: 11429888, proposer_index: 778696, block_root: 0x34cc0675ad5fd052699af2ff37b858c3eb8186c5b29fdadb1dabd246caf79e43, service: beacon, module: beacon_chain::canonical_head:1440 ``` -The field to look for is `attestable_delay`, which defines the time when a block is ready for the validator to attest. If the `attestable_delay` is greater than 4s which has past the window of attestation, the attestation will fail. In the above example, the delay is mostly caused by late block observed by the node, as shown in `observed_delay`. The `observed_delay` is determined mostly by the proposer and partly by your networking setup (e.g., how long it took for the node to receive the block). Ideally, `observed_delay` should be less than 3 seconds. In this example, the validator failed to attest the block due to the block arriving late. +The field to look for is `attestable_delay`, which defines the time when a block is ready for the validator to attest. If the `attestable_delay` is greater than 4s which has past the window of attestation, the attestation will fail. In the above example, the delay is mostly caused by late block observed by the node, as shown in `observed_delay`. The `observed_delay` is determined mostly by the proposer and partly by your networking setup (e.g., how long it took for the node to receive the block). Ideally, `observed_delay` should be less than 3 seconds. In this example, the validator failed to attest the block due to the block arriving late. Another example of log: ``` -DEBG Delayed head block, set_as_head_time_ms: 22, imported_time_ms: 312, attestable_delay_ms: 7052, available_delay_ms: 6874, execution_time_ms: 4694, blob_delay_ms: 2159, observed_delay_ms: 2179, total_delay_ms: 7209, slot: 1885922, proposer_index: 606896, block_root: 0x9966df24d24e722d7133068186f0caa098428696e9f441ac416d0aca70cc0a23, service: beacon, module: beacon_chain::canonical_head:1441 +DEBG Delayed head block, set_as_head_time_ms: 22, imported_time_ms: 312, attestable_delay_ms: 7052, available_delay_ms: 6874, execution_time_ms: 4694, +consensus_time_ms: 232, blob_delay_ms: 2159, observed_delay_ms: 2179, total_delay_ms: 7209, slot: 1885922, proposer_index: 606896, block_root: 0x9966df24d24e722d7133068186f0caa098428696e9f441ac416d0aca70cc0a23, service: beacon, module: beacon_chain::canonical_head:1441 /159.69.68.247/tcp/9000, service: libp2p, module: lighthouse_network::service:1811 ``` From eaec0d556baaa6e9c6f750ead91c04ead6b7b191 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 12:19:50 +0800 Subject: [PATCH 12/26] Update faq --- book/src/faq.md | 32 ++++++++------------------------ 1 file changed, 8 insertions(+), 24 deletions(-) diff --git a/book/src/faq.md b/book/src/faq.md index 0495f765649..4b87ab38526 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -111,10 +111,7 @@ After checkpoint forwards sync completes, the beacon node will start to download INFO Downloading historical blocks est_time: --, distance: 4524545 slots (89 weeks 5 days), service: slot_notifier ``` -If the same log appears every minute and you do not see progress in downloading historical blocks, you can try one of the followings: - -- Check the number of peers you are connected to. If you have low peers (less than 50), try to do port forwarding on the ports 9000 TCP/UDP and 9001 UDP to increase peer count. -- Restart the beacon node. +If the same log appears every minute and you do not see progress in downloading historical blocks, check the number of peers you are connected to. If you have low peers (less than 50), try to do port forwarding on the ports 9000 TCP/UDP and 9001 UDP to increase peer count. ### I proposed a block but the beacon node shows `could not publish message` with error `duplicate` as below, should I be worried? @@ -153,29 +150,16 @@ This is a normal behaviour. Since [v4.1.0](https://github.com/sigp/lighthouse/re ### My beacon node logs `WARN Error processing HTTP API request`, what should I do? -This warning usually comes with an http error code. Some examples are given below: - -1. The log shows: - ```text - WARN Error processing HTTP API request method: GET, path: /eth/v1/validator/attestation_data, status: 500 Internal Server Error, elapsed: 305.65µs - ``` - The error is `500 Internal Server Error`. This suggests that the execution client is not synced. Once the execution client is synced, the error will disappear. +An example of the log is shown below -1. The log shows: - - ```text - WARN Error processing HTTP API request method: POST, path: /eth/v1/validator/duties/attester/199565, status: 503 Service Unavailable, elapsed: 96.787µs - ``` - - The error is `503 Service Unavailable`. This means that the beacon node is still syncing. When this happens, the validator client will log: +```text +WARN Error processing HTTP API request method: GET, path: /eth/v1/validator/attestation_data, status: 500 Internal Server Error, elapsed: 305.65µs +``` - ```text - ERRO Failed to download attester duties err: FailedToDownloadAttesters("Some endpoints failed, num_failed: 2 http://localhost:5052/ => Unavailable(NotSynced), http://localhost:5052/ => RequestFailed(ServerMessage(ErrorMessage { code: 503, message: \"SERVICE_UNAVAILABLE: beacon node is syncing - ``` +This warning usually happens when the validator client sends a request to the beacon node, but the beacon node is unable to fulfil the request. This can be due to the execution client is not synced/is syncing and/or the beacon node is syncing. The error show go away when the node is synced. - This means that the validator client is sending requests to the beacon node. However, as the beacon node is still syncing, it is therefore unable to fulfil the request. The error will disappear once the beacon node is synced. ### My beacon node logs `WARN Error signalling fork choice waiter`, what should I do? @@ -259,7 +243,7 @@ Another possible reason for missing the head vote is due to a chain "reorg". A r ### Can I submit a voluntary exit message without running a beacon node? -Yes. Beaconcha.in provides the tool to broadcast the message. You can create the voluntary exit message file with [ethdo](https://github.com/wealdtech/ethdo/releases/tag/v1.30.0) and submit the message via the [beaconcha.in](https://beaconcha.in/tools/broadcast) website. A guide on how to use `ethdo` to perform voluntary exit can be found [here](https://github.com/eth-educators/ethstaker-guides/blob/main/docs/validator_voluntary_exit.md). +Yes. Beaconcha.in provides the tool to broadcast the message. You can create the voluntary exit message file with [ethdo](https://github.com/wealdtech/ethdo/releases) and submit the message via the [beaconcha.in](https://beaconcha.in/tools/broadcast) website. A guide on how to use `ethdo` to perform voluntary exit can be found [here](https://github.com/eth-educators/ethstaker-guides/blob/main/docs/validator_voluntary_exit.md). It is also noted that you can submit your BLS-to-execution-change message to update your withdrawal credentials from type `0x00` to `0x01` using the same link. @@ -281,7 +265,7 @@ If you do not want to stop `lighthouse vc`, you can use the [key manager API](./ ### How can I delete my validator once it is imported? -Lighthouse supports the [KeyManager API](https://ethereum.github.io/keymanager-APIs/#/Local%20Key%20Manager/deleteKeys) to delete validators and remove them from the `validator_definitions.yml` file. To do so, start the validator client with the flag `--http` and call the API. +You can use the `lighthouse vm delete` command to delete validator keys, see [validator manager delete](./validator_manager_api.md#delete). If you are looking to delete the validators in one node and import it to another, you can use the [validator-manager](./validator_manager_move.md) to move the validators across nodes without the hassle of deleting and importing the keys. From 2de28fb9a1cca3b7376599011516a771315bb310 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 13:19:57 +0800 Subject: [PATCH 13/26] revise --- book/src/advanced_database_migrations.md | 8 +------- book/src/archived_faq.md | 2 +- book/src/developers_architecture.md | 2 ++ book/src/faq.md | 4 +--- 4 files changed, 5 insertions(+), 11 deletions(-) diff --git a/book/src/advanced_database_migrations.md b/book/src/advanced_database_migrations.md index ea5be6c28be..f2e642d28ff 100644 --- a/book/src/advanced_database_migrations.md +++ b/book/src/advanced_database_migrations.md @@ -16,14 +16,9 @@ validator client or the slasher**. | Lighthouse version | Release date | Schema version | Downgrade available? | |--------------------|--------------|----------------|----------------------| -| v7.0.0 | April 2025 | v22 | no | +| v7.0.0 | Apr 2025 | v22 | no | | v6.0.1 | Dec 2024 | v22 | yes before Electra using <= 7.0.0 | | v6.0.0 | Nov 2024 | v22 | yes before Electra using <= 7.0.0 | -| 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). @@ -211,7 +206,6 @@ Here are the steps to prune historic states: | Lighthouse version | Release date | Schema version | Downgrade available? | |--------------------|--------------|----------------|-------------------------------------| -| v6.0.0 | Nov 2024 | v22 | no | | v5.3.0 | Aug 2024 | v21 | yes | | 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 | diff --git a/book/src/archived_faq.md b/book/src/archived_faq.md index 2cc53c1df91..e6f21708b2b 100644 --- a/book/src/archived_faq.md +++ b/book/src/archived_faq.md @@ -1,6 +1,6 @@ # Archived FAQ -Note: The following FAQ is valid for mainnet before Electra. After Electra, [EIP6110 Supply validator deposits on chain](Supply validator deposits on chain) is implemented and the time taken to activate a validator can be as fast as 13 minutes. +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? diff --git a/book/src/developers_architecture.md b/book/src/developers_architecture.md index cfda2dd34fc..3c6037f5c31 100644 --- a/book/src/developers_architecture.md +++ b/book/src/developers_architecture.md @@ -1,3 +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) diff --git a/book/src/faq.md b/book/src/faq.md index 4b87ab38526..c7e1a1c5323 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -150,8 +150,6 @@ This is a normal behaviour. Since [v4.1.0](https://github.com/sigp/lighthouse/re ### My beacon node logs `WARN Error processing HTTP API request`, what should I do? - - An example of the log is shown below ```text @@ -160,7 +158,6 @@ WARN Error processing HTTP API request method: GET, path: /eth/v1/validato This warning usually happens when the validator client sends a request to the beacon node, but the beacon node is unable to fulfil the request. This can be due to the execution client is not synced/is syncing and/or the beacon node is syncing. The error show go away when the node is synced. - ### My beacon node logs `WARN Error signalling fork choice waiter`, what should I do? An example of the full log is shown below: @@ -181,6 +178,7 @@ ERRO Attestation delay queue is full msg: check system clock, queue_size ``` This suggests that the computer resources are being overwhelmed. It could be due to high CPU usage or high disk I/O usage. Some common reasons are: + - when the beacon node is downloading historical blocks - the execution client is syncing - disk IO is being overwhelmed From d226fe6e31c1f392f14aec9852398282211bec05 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 13:27:51 +0800 Subject: [PATCH 14/26] update consolidation --- book/src/faq.md | 5 ++--- book/src/validator_consolidation.md | 11 ++++++----- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/book/src/faq.md b/book/src/faq.md index c7e1a1c5323..55e62ff3677 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -170,7 +170,7 @@ This suggests that the computer resources are being overwhelmed. It could be due ### My beacon node logs `ERRO Aggregate attestation queue full`, what should I do? -Some examplex of the full log is shown below: +Some examples of the full log is shown below: ```text ERRO Aggregate attestation queue full, queue_len: 4096, msg: the system has insufficient resources for load, module: network::beacon_processor:1542 @@ -224,8 +224,7 @@ The field to look for is `attestable_delay`, which defines the time when a block Another example of log: ``` -DEBG Delayed head block, set_as_head_time_ms: 22, imported_time_ms: 312, attestable_delay_ms: 7052, available_delay_ms: 6874, execution_time_ms: 4694, -consensus_time_ms: 232, blob_delay_ms: 2159, observed_delay_ms: 2179, total_delay_ms: 7209, slot: 1885922, proposer_index: 606896, block_root: 0x9966df24d24e722d7133068186f0caa098428696e9f441ac416d0aca70cc0a23, service: beacon, module: beacon_chain::canonical_head:1441 +DEBG Delayed head block, set_as_head_time_ms: 22, imported_time_ms: 312, attestable_delay_ms: 7052, available_delay_ms: 6874, execution_time_ms: 4694, consensus_time_ms: 232, blob_delay_ms: 2159, observed_delay_ms: 2179, total_delay_ms: 7209, slot: 1885922, proposer_index: 606896, block_root: 0x9966df24d24e722d7133068186f0caa098428696e9f441ac416d0aca70cc0a23, service: beacon, module: beacon_chain::canonical_head:1441 /159.69.68.247/tcp/9000, service: libp2p, module: lighthouse_network::service:1811 ``` diff --git a/book/src/validator_consolidation.md b/book/src/validator_consolidation.md index 5404b8b0512..e358d239a2c 100644 --- a/book/src/validator_consolidation.md +++ b/book/src/validator_consolidation.md @@ -1,17 +1,18 @@ # Consolidation -With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, the effective balance of a validator can be up to 2048 ETH. This is done by updating the validator withdrawal credential to type 0x02. +With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, a validator can hold a stake of up to 2048 ETH. This is done by updating the validator withdrawal credential to type 0x02. With 0x02 withdrawal credential, it is possible to consolidate two or more validators into a single validator with a higher stake. -With 0x02 withdrawal credential, it is therefore possible to consolidate two or more validators into a single validator with a higher effective balance. Let's take a look at an example: Initially, validators A and B are both with 0x01 withdrawal credentials with 32 ETH. Say we want to consolidate the balance of validator B to the balance of validator A, so that the balance of validator A becomes 64 ETH. These are the steps: +Let's take a look at an example: Initially, validators A and B are both with 0x01 withdrawal credentials with 32 ETH. Let's say we want to consolidate the balance of validator B to validator A, so that the balance of validator A becomes 64 ETH. These are the steps: -1. Update the withdrawal credential of validator A to 0x02. You can do this using [Siren](./ui.md) or the staking launchpad. Select: +1. Update the withdrawal credential of validator A to 0x02. You can do this using [Siren](./ui.md) or the [staking launchpad](https://launchpad.ethereum.org/en/). Select: - source validator: validator A - target validator: validator A - > Note: A validator with withdrawal credential type 0x02 cannot be reverted to 0x01, except that the validator exits and make a fresh deposit. + > Note: After the update, the withdrawal credential type 0x02 cannot be reverted to 0x01, except that the validator exits and make a fresh deposit. 2. Perform consolidation by selecting: - source validator: validator B - target validator: validator A + and then execute the transaction. Depending on the exit and deposit queue, the process could take from a day to weeks. The outcome is: @@ -26,4 +27,4 @@ It is important to note that there are some conditions required to perform conso - the _target validator_ **must** have a withdrawal credential **type 0x02**. The source validator could have a 0x01 or 0x02 withdrawal credential. - the source validator must be active for at least 256 epochs to be able to perform consolidation. -Note that if a user were to send a consolidation transaction that does not meet one or more of the conditions, the transaction can still be accepted by the execution layer. However, the consolidation will fail once it reaches the consensus layer (where the checks are performed). Therefore, it is recommended to check that the conditions are fulfilled before sending a consolidation transaction. +Note that if a user were to send a consolidation transaction that does not meet the conditions, the transaction can still be accepted by the execution layer. However, the consolidation will fail once it reaches the consensus layer (where the checks are performed). Therefore, it is recommended to check that the conditions are fulfilled before sending a consolidation transaction. From cbc6a2299b3f90b1c2c2510726c4c79d725a03f0 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 13:30:04 +0800 Subject: [PATCH 15/26] revise --- book/src/validator_consolidation.md | 2 +- book/src/validator_sweep.md | 2 +- book/src/validator_voluntary_exit.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/book/src/validator_consolidation.md b/book/src/validator_consolidation.md index e358d239a2c..d17a101c057 100644 --- a/book/src/validator_consolidation.md +++ b/book/src/validator_consolidation.md @@ -1,6 +1,6 @@ # Consolidation -With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, a validator can hold a stake of up to 2048 ETH. This is done by updating the validator withdrawal credential to type 0x02. With 0x02 withdrawal credential, it is possible to consolidate two or more validators into a single validator with a higher stake. +With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, a validator can hold a stake of up to 2048 ETH. This is done by updating the validator withdrawal credential to type 0x02. With 0x02 withdrawal credential, it is possible to consolidate two or more validators into a single validator with a higher stake. Let's take a look at an example: Initially, validators A and B are both with 0x01 withdrawal credentials with 32 ETH. Let's say we want to consolidate the balance of validator B to validator A, so that the balance of validator A becomes 64 ETH. These are the steps: diff --git a/book/src/validator_sweep.md b/book/src/validator_sweep.md index 9b2cdd5f2bc..260a4e2edac 100644 --- a/book/src/validator_sweep.md +++ b/book/src/validator_sweep.md @@ -7,7 +7,7 @@ After the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12 ## Partial withdrawals via the execution layer -With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x02 withdrawal credentials can partially withdraw the staked fund via the execution layer by sending a transaction using the withdrawal address. You can withdraw up until the validator balance is 32 ETH. For example, if the validator balance is 40 ETH, you can withdraw up to 8 ETH. You can use [Siren](./ui.md) or the Staking launchpad to execute partial withdrawals. +With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x02 withdrawal credentials can partially withdraw the staked fund via the execution layer by sending a transaction using the withdrawal address. You can withdraw up until the validator balance is 32 ETH. For example, if the validator balance is 40 ETH, you can withdraw up to 8 ETH. ## FAQ diff --git a/book/src/validator_voluntary_exit.md b/book/src/validator_voluntary_exit.md index e5035b97845..b50b1d14143 100644 --- a/book/src/validator_voluntary_exit.md +++ b/book/src/validator_voluntary_exit.md @@ -60,7 +60,7 @@ Exit epoch in approximately 1920 secs ## Exit via the execution layer -The voluntary exit above is via the consensus layer. With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x01 and 0x02 withdrawal credentials can also exit their validators via the execution layer by sending a transaction using the withdrawal address. You can use [Siren](./ui.md) or the Staking launchpad to exit validators. +The voluntary exit above is via the consensus layer. With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x01 and 0x02 withdrawal credentials can also exit their validators via the execution layer by sending a transaction using the withdrawal address. ## Full withdrawal of staked fund From 4c09068f6c3b341812169c87165e6619ea599bfb Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 13:53:55 +0800 Subject: [PATCH 16/26] Add summary --- book/src/SUMMARY.md | 1 + book/src/advanced_database_migrations.md | 2 +- book/src/validator_sweep.md | 2 +- book/src/validator_voluntary_exit.md | 2 +- 4 files changed, 4 insertions(+), 3 deletions(-) diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index e16e5d38230..44f08615643 100644 --- a/book/src/SUMMARY.md +++ b/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) diff --git a/book/src/advanced_database_migrations.md b/book/src/advanced_database_migrations.md index f2e642d28ff..00419b05ac6 100644 --- a/book/src/advanced_database_migrations.md +++ b/book/src/advanced_database_migrations.md @@ -18,7 +18,7 @@ validator client or the slasher**. |--------------------|--------------|----------------|----------------------| | v7.0.0 | Apr 2025 | v22 | no | | v6.0.1 | Dec 2024 | v22 | yes before Electra using <= 7.0.0 | -| v6.0.0 | Nov 2024 | v22 | yes before Electra using <= 7.0.0 | +| v6.0.0 | Nov 2024 | v22 | yes before Electra using <= 7.0.0 | > **Note**: All point releases (e.g. v4.4.1) are schema-compatible with the prior minor release > (e.g. v4.4.0). diff --git a/book/src/validator_sweep.md b/book/src/validator_sweep.md index 260a4e2edac..87ad8e92f61 100644 --- a/book/src/validator_sweep.md +++ b/book/src/validator_sweep.md @@ -7,7 +7,7 @@ After the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12 ## Partial withdrawals via the execution layer -With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x02 withdrawal credentials can partially withdraw the staked fund via the execution layer by sending a transaction using the withdrawal address. You can withdraw up until the validator balance is 32 ETH. For example, if the validator balance is 40 ETH, you can withdraw up to 8 ETH. +With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x02 withdrawal credentials can partially withdraw the staked fund via the execution layer by sending a transaction using the withdrawal address. You can withdraw up until the validator balance is 32 ETH. For example, if the validator balance is 40 ETH, you can withdraw up to 8 ETH. You can use [Siren](./ui.md) or the [staking launchpad](https://launchpad.ethereum.org/en/) to execute partial withdrawals. ## FAQ diff --git a/book/src/validator_voluntary_exit.md b/book/src/validator_voluntary_exit.md index b50b1d14143..db4e5b43879 100644 --- a/book/src/validator_voluntary_exit.md +++ b/book/src/validator_voluntary_exit.md @@ -60,7 +60,7 @@ Exit epoch in approximately 1920 secs ## Exit via the execution layer -The voluntary exit above is via the consensus layer. With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x01 and 0x02 withdrawal credentials can also exit their validators via the execution layer by sending a transaction using the withdrawal address. +The voluntary exit above is via the consensus layer. With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x01 and 0x02 withdrawal credentials can also exit their validators via the execution layer by sending a transaction using the withdrawal address. You can use [Siren](./ui.md) or the [staking launchpad](https://launchpad.ethereum.org/en/) to execute partial withdrawals. ## Full withdrawal of staked fund From f145d6e059d54c70f20a7c454ceed0e9bc42e1a8 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 13:58:10 +0800 Subject: [PATCH 17/26] fix link --- book/src/mainnet_validator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/src/mainnet_validator.md b/book/src/mainnet_validator.md index d21d49f0c90..1b706bc26b0 100644 --- a/book/src/mainnet_validator.md +++ b/book/src/mainnet_validator.md @@ -157,7 +157,7 @@ After you have successfully run and synced the execution client, beacon node and > **Important note:** Double check that the deposit contract for mainnet is `0x00000000219ab540356cBB839Cbe05303d7705Fa` before you confirm the transaction. -Once the deposit transaction is confirmed, it will take a minimum of ~16 hours to a few days/weeks for the beacon chain to process and activate your validator, depending on the queue. Refer to our [FAQ - Why does it take so long for a validator to be activated](./faq.md#why-does-it-take-so-long-for-a-validator-to-be-activated) for more info. +Once the deposit transaction is confirmed, it will take a minimum of ~13 minutes to a few days to activate your validator, depending on the queue. Once your validator is activated, the validator client will start to publish attestations each epoch: From 225191a1927ccf72b269bdebc66779004f204965 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 14:37:53 +0800 Subject: [PATCH 18/26] mdlint --- book/src/mainnet_validator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/src/mainnet_validator.md b/book/src/mainnet_validator.md index 1b706bc26b0..35eac2400f4 100644 --- a/book/src/mainnet_validator.md +++ b/book/src/mainnet_validator.md @@ -157,7 +157,7 @@ After you have successfully run and synced the execution client, beacon node and > **Important note:** Double check that the deposit contract for mainnet is `0x00000000219ab540356cBB839Cbe05303d7705Fa` before you confirm the transaction. -Once the deposit transaction is confirmed, it will take a minimum of ~13 minutes to a few days to activate your validator, depending on the queue. +Once the deposit transaction is confirmed, it will take a minimum of ~13 minutes to a few days to activate your validator, depending on the queue. Once your validator is activated, the validator client will start to publish attestations each epoch: From a844665bc7c93f4219927da63bb0e9f16d2c9c58 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 14:59:55 +0800 Subject: [PATCH 19/26] spellcheck --- wordlist.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/wordlist.txt b/wordlist.txt index 7adbfe90326..9feb07b67bc 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -66,6 +66,7 @@ Nethermind NodeJS NullLogger PathBuf +Pectra PowerShell PPA Pre @@ -236,6 +237,7 @@ validators validator's vc virt +walkthrough webapp withdrawable yaml From 10fc37fafc3bab67d3e9d375093e8645da73fb78 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Tue, 8 Apr 2025 17:03:31 +0800 Subject: [PATCH 20/26] summary --- book/src/SUMMARY.md | 1 + 1 file changed, 1 insertion(+) diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index 44f08615643..4c1d52f8f34 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -68,3 +68,4 @@ * [Merge Migration](./archived_merge_migration.md) * [Raspberry Pi 4](./archived_pi.md) * [Key Management](./archived_key_management.md) + * [FAQ](./archived_faq.md) From 179a45919e14a720d49516b1e32bc0d5e995226b Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Wed, 16 Apr 2025 07:24:03 +0800 Subject: [PATCH 21/26] Update log --- book/src/faq.md | 2 +- book/src/mainnet_validator.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/book/src/faq.md b/book/src/faq.md index 55e62ff3677..7fa24d616db 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -174,7 +174,7 @@ Some examples of the full log is shown below: ```text ERRO Aggregate attestation queue full, queue_len: 4096, msg: the system has insufficient resources for load, module: network::beacon_processor:1542 -ERRO Attestation delay queue is full msg: check system clock, queue_size: 16384, service: bproc +ERRO Attestation delay queue is full msg: system resources may be saturated, queue_size: 16384, service: bproc ``` This suggests that the computer resources are being overwhelmed. It could be due to high CPU usage or high disk I/O usage. Some common reasons are: diff --git a/book/src/mainnet_validator.md b/book/src/mainnet_validator.md index 35eac2400f4..5b17eef6cdb 100644 --- a/book/src/mainnet_validator.md +++ b/book/src/mainnet_validator.md @@ -151,9 +151,9 @@ Once this log appears (and there are no errors) the `lighthouse vc` application will ensure that the validator starts performing its duties and being rewarded by the protocol. -### Step 5: Submit deposit (32ETH per validator) +### Step 5: Submit deposit (a minimum of 32ETH to activate one validator) -After you have successfully run and synced the execution client, beacon node and validator client, you can now proceed to submit the deposit. Go to the mainnet [Staking launchpad](https://launchpad.ethereum.org/en/) (or [Holesky staking launchpad](https://holesky.launchpad.ethereum.org/en/) for testnet validator) and carefully go through the steps to becoming a validator. Once you are ready, you can submit the deposit by sending 32ETH per validator to the deposit contract. Upload the `deposit_data-*.json` file generated in [Step 1](#step-1-create-validator-keys) to the Staking launchpad. +After you have successfully run and synced the execution client, beacon node and validator client, you can now proceed to submit the deposit. Go to the mainnet [Staking launchpad](https://launchpad.ethereum.org/en/) (or [Holesky staking launchpad](https://holesky.launchpad.ethereum.org/en/) for testnet validator) and carefully go through the steps to becoming a validator. Once you are ready, you can submit the deposit by sending ETH to the deposit contract. Upload the `deposit_data-*.json` file generated in [Step 1](#step-1-create-validator-keys) to the Staking launchpad. > **Important note:** Double check that the deposit contract for mainnet is `0x00000000219ab540356cBB839Cbe05303d7705Fa` before you confirm the transaction. From 3d9249906bd0aa2970e92240be98340d7c8bf440 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Wed, 16 Apr 2025 08:25:36 +0800 Subject: [PATCH 22/26] Fix link --- book/src/mainnet_validator.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/src/mainnet_validator.md b/book/src/mainnet_validator.md index 5b17eef6cdb..ba35ba6f122 100644 --- a/book/src/mainnet_validator.md +++ b/book/src/mainnet_validator.md @@ -33,7 +33,7 @@ There are five primary steps to become a validator: 1. [Start an execution client and Lighthouse beacon node](#step-2-start-an-execution-client-and-lighthouse-beacon-node) 1. [Import validator keys into Lighthouse](#step-3-import-validator-keys-to-lighthouse) 1. [Start Lighthouse validator client](#step-4-start-lighthouse-validator-client) -1. [Submit deposit](#step-5-submit-deposit-32eth-per-validator) +1. [Submit deposit](#step-5-submit-deposit-a-minimum-of-32eth-to-activate-one-validator) > **Important note**: The guide below contains both mainnet and testnet instructions. We highly recommend *all* users to **run a testnet validator** prior to staking mainnet ETH. By far, the best technical learning experience is to run a testnet validator. You can get hands-on experience with all the tools and it's a great way to test your staking hardware. 32 ETH is a significant outlay and joining a testnet is a great way to "try before you buy". From 798adbe1ca6a1b14a90d72d245d13f757ddb5b6f Mon Sep 17 00:00:00 2001 From: Michael Sproul Date: Thu, 17 Apr 2025 10:36:29 +1000 Subject: [PATCH 23/26] Correct schema version docs --- book/src/advanced_database_migrations.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/book/src/advanced_database_migrations.md b/book/src/advanced_database_migrations.md index 00419b05ac6..3c56fcadc13 100644 --- a/book/src/advanced_database_migrations.md +++ b/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,9 +17,8 @@ validator client or the slasher**. | Lighthouse version | Release date | Schema version | Downgrade available? | |--------------------|--------------|----------------|----------------------| -| v7.0.0 | Apr 2025 | v22 | no | -| v6.0.1 | Dec 2024 | v22 | yes before Electra using <= 7.0.0 | -| v6.0.0 | Nov 2024 | v22 | yes before Electra using <= 7.0.0 | +| v7.0.0 | Apr 2025 | v22 | no | +| v6.0.0 | Nov 2024 | v22 | no | > **Note**: All point releases (e.g. v4.4.1) are schema-compatible with the prior minor release > (e.g. v4.4.0). @@ -206,7 +206,9 @@ Here are the steps to prune historic states: | Lighthouse version | Release date | Schema version | Downgrade available? | |--------------------|--------------|----------------|-------------------------------------| -| v5.3.0 | Aug 2024 | v21 | yes | +| v7.0.0 | Apr 2025 | v22 | no | +| v6.0.0 | Nov 2024 | v22 | no | +| 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 | From 7ecdeb78515ae9565c2dcc891658fec9cf84a505 Mon Sep 17 00:00:00 2001 From: chonghe <44791194+chong-he@users.noreply.github.com> Date: Thu, 17 Apr 2025 13:56:00 +0800 Subject: [PATCH 24/26] Apply suggestions from code review Co-authored-by: Michael Sproul --- book/src/archived.md | 2 +- book/src/developers_architecture.md | 2 +- book/src/faq.md | 2 +- book/src/validator_consolidation.md | 6 +++--- book/src/validator_sweep.md | 2 +- book/src/validator_voluntary_exit.md | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/book/src/archived.md b/book/src/archived.md index c39443656fb..d37cd9aa154 100644 --- a/book/src/archived.md +++ b/book/src/archived.md @@ -1,3 +1,3 @@ # Archived -This section keeps the topics that are deprecated. Documentation in this section are for informational purposes only and will not be maintained. +This section keeps the topics that are deprecated. Documentation in this section is for informational purposes only and will not be maintained. diff --git a/book/src/developers_architecture.md b/book/src/developers_architecture.md index 3c6037f5c31..11505255120 100644 --- a/book/src/developers_architecture.md +++ b/book/src/developers_architecture.md @@ -1,5 +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) +A technical walkthrough of Lighthouse's architecture can be found at: [Lighthouse technical walkthrough](https://www.youtube.com/watch?v=pLHhTh_vGZ0) ![Lighthouse architecture](imgs/developers_architecture.svg) diff --git a/book/src/faq.md b/book/src/faq.md index 7fa24d616db..13c73b4636e 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -219,7 +219,7 @@ An example of the log: (debug logs can be found under `$datadir/beacon/logs`): DEBG Delayed head block, set_as_head_time_ms: 37, imported_time_ms: 1824, attestable_delay_ms: 3660, available_delay_ms: 3491, execution_time_ms: 78, consensus_time_ms: 161, blob_delay_ms: 3291, observed_delay_ms: 3250, total_delay_ms: 5352, slot: 11429888, proposer_index: 778696, block_root: 0x34cc0675ad5fd052699af2ff37b858c3eb8186c5b29fdadb1dabd246caf79e43, service: beacon, module: beacon_chain::canonical_head:1440 ``` -The field to look for is `attestable_delay`, which defines the time when a block is ready for the validator to attest. If the `attestable_delay` is greater than 4s which has past the window of attestation, the attestation will fail. In the above example, the delay is mostly caused by late block observed by the node, as shown in `observed_delay`. The `observed_delay` is determined mostly by the proposer and partly by your networking setup (e.g., how long it took for the node to receive the block). Ideally, `observed_delay` should be less than 3 seconds. In this example, the validator failed to attest the block due to the block arriving late. +The field to look for is `attestable_delay`, which defines the time when a block is ready for the validator to attest. If the `attestable_delay` is greater than 4s then it is missed the window for attestation, and the attestation will fail. In the above example, the delay is mostly caused by a late block observed by the node, as shown in `observed_delay`. The `observed_delay` is determined mostly by the proposer and partly by your networking setup (e.g., how long it took for the node to receive the block). Ideally, `observed_delay` should be less than 3 seconds. In this example, the validator failed to attest to the block due to the block arriving late. Another example of log: diff --git a/book/src/validator_consolidation.md b/book/src/validator_consolidation.md index d17a101c057..04a052dcf19 100644 --- a/book/src/validator_consolidation.md +++ b/book/src/validator_consolidation.md @@ -1,13 +1,13 @@ # Consolidation -With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, a validator can hold a stake of up to 2048 ETH. This is done by updating the validator withdrawal credential to type 0x02. With 0x02 withdrawal credential, it is possible to consolidate two or more validators into a single validator with a higher stake. +With the [Pectra](https://ethereum.org/en/history/#pectra) upgrade, a validator can hold a stake of up to 2048 ETH. This is done by updating the validator withdrawal credentials to type 0x02. With 0x02 withdrawal credentials, it is possible to consolidate two or more validators into a single validator with a higher stake. Let's take a look at an example: Initially, validators A and B are both with 0x01 withdrawal credentials with 32 ETH. Let's say we want to consolidate the balance of validator B to validator A, so that the balance of validator A becomes 64 ETH. These are the steps: -1. Update the withdrawal credential of validator A to 0x02. You can do this using [Siren](./ui.md) or the [staking launchpad](https://launchpad.ethereum.org/en/). Select: +1. Update the withdrawal credentials of validator A to 0x02. You can do this using [Siren](./ui.md) or the [staking launchpad](https://launchpad.ethereum.org/en/). Select: - source validator: validator A - target validator: validator A - > Note: After the update, the withdrawal credential type 0x02 cannot be reverted to 0x01, except that the validator exits and make a fresh deposit. + > Note: After the update, the withdrawal credential type 0x02 cannot be reverted to 0x01, unless the validator exits and makes a fresh deposit. 2. Perform consolidation by selecting: - source validator: validator B diff --git a/book/src/validator_sweep.md b/book/src/validator_sweep.md index 87ad8e92f61..0755c06d51c 100644 --- a/book/src/validator_sweep.md +++ b/book/src/validator_sweep.md @@ -7,7 +7,7 @@ After the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12 ## Partial withdrawals via the execution layer -With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x02 withdrawal credentials can partially withdraw the staked fund via the execution layer by sending a transaction using the withdrawal address. You can withdraw up until the validator balance is 32 ETH. For example, if the validator balance is 40 ETH, you can withdraw up to 8 ETH. You can use [Siren](./ui.md) or the [staking launchpad](https://launchpad.ethereum.org/en/) to execute partial withdrawals. +With the [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x02 withdrawal credentials can partially withdraw staked funds via the execution layer by sending a transaction using the withdrawal address. You can withdraw down to a validator balance of 32 ETH. For example, if the validator balance is 40 ETH, you can withdraw up to 8 ETH. You can use [Siren](./ui.md) or the [staking launchpad](https://launchpad.ethereum.org/en/) to execute partial withdrawals. ## FAQ diff --git a/book/src/validator_voluntary_exit.md b/book/src/validator_voluntary_exit.md index db4e5b43879..c17c0f4fc44 100644 --- a/book/src/validator_voluntary_exit.md +++ b/book/src/validator_voluntary_exit.md @@ -60,7 +60,7 @@ Exit epoch in approximately 1920 secs ## Exit via the execution layer -The voluntary exit above is via the consensus layer. With [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x01 and 0x02 withdrawal credentials can also exit their validators via the execution layer by sending a transaction using the withdrawal address. You can use [Siren](./ui.md) or the [staking launchpad](https://launchpad.ethereum.org/en/) to execute partial withdrawals. +The voluntary exit above is via the consensus layer. With the [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x01 and 0x02 withdrawal credentials can also exit their validators via the execution layer by sending a transaction using the withdrawal address. You can use [Siren](./ui.md) or the [staking launchpad](https://launchpad.ethereum.org/en/) to send an exit transaction. ## Full withdrawal of staked fund From e984ff9d2ff7abb195d95a4c9a1e79433908f7b2 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Thu, 17 Apr 2025 13:57:16 +0800 Subject: [PATCH 25/26] delete archived_faq.md --- book/src/SUMMARY.md | 1 - book/src/archived_faq.md | 74 ---------------------------------------- book/src/faq.md | 2 +- 3 files changed, 1 insertion(+), 76 deletions(-) delete mode 100644 book/src/archived_faq.md diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index 4c1d52f8f34..44f08615643 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -68,4 +68,3 @@ * [Merge Migration](./archived_merge_migration.md) * [Raspberry Pi 4](./archived_pi.md) * [Key Management](./archived_key_management.md) - * [FAQ](./archived_faq.md) diff --git a/book/src/archived_faq.md b/book/src/archived_faq.md deleted file mode 100644 index e6f21708b2b..00000000000 --- a/book/src/archived_faq.md +++ /dev/null @@ -1,74 +0,0 @@ -# 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! diff --git a/book/src/faq.md b/book/src/faq.md index 13c73b4636e..b0dd6969026 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -219,7 +219,7 @@ An example of the log: (debug logs can be found under `$datadir/beacon/logs`): DEBG Delayed head block, set_as_head_time_ms: 37, imported_time_ms: 1824, attestable_delay_ms: 3660, available_delay_ms: 3491, execution_time_ms: 78, consensus_time_ms: 161, blob_delay_ms: 3291, observed_delay_ms: 3250, total_delay_ms: 5352, slot: 11429888, proposer_index: 778696, block_root: 0x34cc0675ad5fd052699af2ff37b858c3eb8186c5b29fdadb1dabd246caf79e43, service: beacon, module: beacon_chain::canonical_head:1440 ``` -The field to look for is `attestable_delay`, which defines the time when a block is ready for the validator to attest. If the `attestable_delay` is greater than 4s then it is missed the window for attestation, and the attestation will fail. In the above example, the delay is mostly caused by a late block observed by the node, as shown in `observed_delay`. The `observed_delay` is determined mostly by the proposer and partly by your networking setup (e.g., how long it took for the node to receive the block). Ideally, `observed_delay` should be less than 3 seconds. In this example, the validator failed to attest to the block due to the block arriving late. +The field to look for is `attestable_delay`, which defines the time when a block is ready for the validator to attest. If the `attestable_delay` is greater than 4s then it has missed the window for attestation, and the attestation will fail. In the above example, the delay is mostly caused by a late block observed by the node, as shown in `observed_delay`. The `observed_delay` is determined mostly by the proposer and partly by your networking setup (e.g., how long it took for the node to receive the block). Ideally, `observed_delay` should be less than 3 seconds. In this example, the validator failed to attest to the block due to the block arriving late. Another example of log: From 3c9572ffef60aa8b02fe29ff94c37b92612430b1 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Thu, 17 Apr 2025 13:59:39 +0800 Subject: [PATCH 26/26] revise to pending consolidation --- book/src/validator_consolidation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/src/validator_consolidation.md b/book/src/validator_consolidation.md index 04a052dcf19..10ab5bd97d0 100644 --- a/book/src/validator_consolidation.md +++ b/book/src/validator_consolidation.md @@ -15,7 +15,7 @@ Let's take a look at an example: Initially, validators A and B are both with 0x0 and then execute the transaction. - Depending on the exit and deposit queue, the process could take from a day to weeks. The outcome is: + Depending on the exit queue and pending consolidations, the process could take from a day to weeks. The outcome is: - validator A has 64 ETH - validator B has 0 ETH (i.e., validator B has exited the beacon chain)