Update manual checkpoint sync content in Lighthouse book (#6338)

* Update manual checkpiont sync * Update faq * Minor revision * Minor revision
sigp · Sep 3, 2024 · 84f0011 · 84f0011
1 parent ed7cd3b
commit 84f0011
Show file tree

Hide file tree

Showing 2 changed files with 3 additions and 35 deletions.
diff --git 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. A slot which is an epoch boundary slot (i.e., first slot of an epoch) should always be used for manual checkpoint sync.
 
-_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 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.
 

diff --git 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.
 
-### <a name="bn-blob"></a> 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
 
 ### <a name="vc-activation"></a> Why does it take so long for a validator to be activated?
@@ -281,28 +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:
-
-<div align="center" style="text-align: center;">
-
-| 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 |
-
-</div>
-
-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!