From 7381592d85554b15780034ce713a588211383b59 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Mon, 2 Sep 2024 10:11:02 +0800 Subject: [PATCH 1/4] Update manual checkpiont sync --- book/src/checkpoint-sync.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/book/src/checkpoint-sync.md b/book/src/checkpoint-sync.md index 2bf028acfec..d0112cd6d4a 100644 --- a/book/src/checkpoint-sync.md +++ b/book/src/checkpoint-sync.md @@ -158,9 +158,9 @@ curl -H "Accept: application/octet-stream" "http://localhost:5052/eth/v2/beacon/ curl -H "Accept: application/octet-stream" "http://localhost:5052/eth/v1/beacon/blob_sidecars/$SLOT" > blobs.ssz ``` -where `$SLOT` is the slot number. It can be specified as `head` or `finalized` as well. +where `$SLOT` is the slot number. It can be specified as `finalized`, or a slot where `slot % 32 == 0` (i.e., first slot of an epoch). -_Both_ the state and block must be provided and the state **must** match the block. The +If the block contains blobs, all state, block and blobs must be provided and the state **must** match the block. The state may be from the same slot as the block (unadvanced), or advanced to an epoch boundary, in which case it will be assumed to be finalized at that epoch. From 03ac9c231a51a4dabcc9d592c714aed0a92406f3 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Mon, 2 Sep 2024 10:23:54 +0800 Subject: [PATCH 2/4] Update faq --- book/src/faq.md | 35 +---------------------------------- 1 file changed, 1 insertion(+), 34 deletions(-) diff --git a/book/src/faq.md b/book/src/faq.md index 4c58c2e16d1..08dd576ad62 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -14,7 +14,6 @@ - [My beacon node logs `WARN Error signalling fork choice waiter`, what should I do?](#bn-fork-choice) - [My beacon node logs `ERRO Aggregate attestation queue full`, what should I do?](#bn-queue-full) - [My beacon node logs `WARN Failed to finalize deposit cache`, what should I do?](#bn-deposit-cache) -- [My beacon node logs `WARN Could not verify blob sidecar for gossip`, what does it mean?](#bn-blob) ## [Validator](#validator-1) @@ -203,16 +202,6 @@ This suggests that the computer resources are being overwhelmed. It could be due This is a known [bug](https://github.com/sigp/lighthouse/issues/3707) that will fix by itself. -### My beacon node logs `WARN Could not verify blob sidecar for gossip`, what does it mean? - -An example of the full log is shown below: - -```text -Jun 07 23:05:12.170 WARN Could not verify blob sidecar for gossip. Ignoring the blob sidecar, commitment: 0xaa97…6f54, index: 1, root: 0x93b8…c47c, slot: 9248017, error: PastFinalizedSlot { blob_slot: Slot(9248017), finalized_slot: Slot(9248032) }, module: network::network_beacon_processor::gossip_methods:720 -``` - -The `PastFinalizedSlot` indicates that the time at which the node received the blob has past the finalization period. This could be due to a peer sending an earlier blob. The log will be gone when Lighthouse eventually drops the peer. - ## Validator ### Why does it take so long for a validator to be activated? @@ -281,29 +270,7 @@ limit](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beac 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 is summarised in the table below: - -
- -| Number of active validators | Validators activated per epoch | Validators activated per day | -|----------------|----|------| -| 327679 or less | 4 | 900 | -| 327680-393215 | 5 | 1125 | -| 393216-458751 | 6 | 1350 | -| 458752-524287 | 7 | 1575 | -| 524288-589823 | 8 | 1800 | -| 589824-655359 | 9 | 2025 | -| 655360-720895 | 10 | 2250 | -| 720896-786431 | 11 | 2475 | -| 786432-851967 | 12 | 2700 | -| 851968-917503 | 13 | 2925 | -| 917504-983039 | 14 | 3150 | -| 983040-1048575 | 15 | 3375 | - -
- -For example, the number of active validators on Mainnet is about 574000 on May 2023. This means that 8 validators can be activated per epoch or 1800 per day (it is noted that the same applies to the exit queue). If, for example, there are 9000 validators waiting to be activated, this means that the waiting time can take up to 5 days. - +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! From ef091ddade6600d45c123023f2f5b83479c7a219 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Mon, 2 Sep 2024 10:45:18 +0800 Subject: [PATCH 3/4] Minor revision --- book/src/checkpoint-sync.md | 2 +- book/src/faq.md | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/book/src/checkpoint-sync.md b/book/src/checkpoint-sync.md index d0112cd6d4a..41d12382d1e 100644 --- a/book/src/checkpoint-sync.md +++ b/book/src/checkpoint-sync.md @@ -158,7 +158,7 @@ curl -H "Accept: application/octet-stream" "http://localhost:5052/eth/v2/beacon/ curl -H "Accept: application/octet-stream" "http://localhost:5052/eth/v1/beacon/blob_sidecars/$SLOT" > blobs.ssz ``` -where `$SLOT` is the slot number. It can be specified as `finalized`, or a slot where `slot % 32 == 0` (i.e., first slot of an epoch). +where `$SLOT` is the slot number. A slot which is an epoch boundary slot (i.e., first slot of an epoch) should always be used for manual checkpoint sync. If the block contains blobs, all state, block and blobs must be provided and the state **must** match the block. The state may be from the same slot as the block (unadvanced), or advanced to an epoch boundary, diff --git a/book/src/faq.md b/book/src/faq.md index 08dd576ad62..04e5ce5bc8f 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -270,7 +270,8 @@ limit](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beac 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. +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! From 7464bdca7d8772298fe2223e3af6d2ab09bf49e3 Mon Sep 17 00:00:00 2001 From: Tan Chee Keong Date: Mon, 2 Sep 2024 12:43:38 +0800 Subject: [PATCH 4/4] Minor revision --- book/src/checkpoint-sync.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/book/src/checkpoint-sync.md b/book/src/checkpoint-sync.md index 41d12382d1e..8dd63f77c9b 100644 --- a/book/src/checkpoint-sync.md +++ b/book/src/checkpoint-sync.md @@ -160,7 +160,7 @@ curl -H "Accept: application/octet-stream" "http://localhost:5052/eth/v1/beacon/ where `$SLOT` is the slot number. A slot which is an epoch boundary slot (i.e., first slot of an epoch) should always be used for manual checkpoint sync. -If the block contains blobs, all state, block and blobs must be provided and the state **must** match the block. The +If the block contains blobs, all state, block and blobs must be provided and must point to the same slot. The state may be from the same slot as the block (unadvanced), or advanced to an epoch boundary, in which case it will be assumed to be finalized at that epoch.