Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update manual checkpoint sync content in Lighthouse book #6338

Merged
merged 4 commits into from
Sep 3, 2024
Merged

Update manual checkpoint sync content in Lighthouse book #6338

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
7381592
Update manual checkpiont sync
chong-he Sep 2, 2024
03ac9c2
Update faq
chong-he Sep 2, 2024
ef091dd
Minor revision
chong-he Sep 2, 2024
7464bdc
Minor revision
chong-he Sep 2, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions book/src/checkpoint-sync.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
34 changes: 1 addition & 33 deletions book/src/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)

Expand Down Expand Up @@ -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?
Expand Down Expand Up @@ -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!
Expand Down
Loading