A node starts from genesis or a trusted weak-subjectivity checkpoint. It finds
fork-compatible peers, completes status, downloads a bounded chain prefix,
and imports only blocks and sidecars that pass consensus validation. Gossip
keeps the imported head current after initial sync.
Status and target selection
On connection the dialing client sends status/1. The exchange contains the
current wall-clock fork digest, finalized root and epoch, head root and slot. A
peer with a mismatched digest or an irreconcilable finalized checkpoint is
disconnected.
The peer with the lower finalized epoch, or lower head slot when finality ties,
requests blocks from the other peer.
The status exchange includes status/2 with earliest_available_slot.
earliest_available_slot states where the peer can serve all required blocks
and sidecars. It prevents a node from assuming that a recent block range also
has its blob or column data.
Range and root sync
beacon_blocks_by_range/1 requests a slot interval and returns one successful
chunk per block. Empty slots have no chunk. The server returns one canonical
fork-choice chain in ascending slot order, with matching parent roots, and may
stop after fork choice changes.
The block request limit is 1,024 items.
beacon_blocks_by_root/1 repairs a missing parent or block. The response may
omit an unknown root but must return a known valid block.
The method set includes beacon_blocks_by_range/2 and
beacon_blocks_by_root/2; each successful response carries a fork-digest
chunk. The context selects the fork-specific SSZ type.
The block request limit is 128 items.
The required recent serving range is
[max(GENESIS_EPOCH, current_epoch - compute_min_epochs_for_block_requests()), current_epoch], where
compute_min_epochs_for_block_requests() is
MIN_VALIDATOR_WITHDRAWABILITY_DELAY + CHURN_LIMIT_QUOTIENT // 2. A peer that
cannot serve that range responds with 3: ResourceUnavailable and may be
downscored or disconnected. A weak-subjectivity node must backfill and validate
the range before it can claim full serving compliance.
Sidecar and column recovery
Sync must recover blob sidecars for blocks in the sidecar serving window. A requester checks the block-root binding, proposer header signature, KZG commitment inclusion proof, and KZG proof before importing a sidecar.
data_column_sidecars_by_range/1 and
data_column_sidecars_by_root/1 recover columns. The network uses 128 column
subnets and a 4,096-epoch minimum column serving window. A data-column response
is checked for index and lengths, its fork-specific block binding, and cell
KZG proofs. The server sends complete known columns for each block it includes
and keeps them in (slot, column_index) order. See
data-availability networking for the full
sidecar lifecycle.
Import progression
The sync process verifies proposer signatures, parent links, finalized ancestry, fork-specific operation limits, and state transitions before import. It may follow an optimistic head while execution or data availability remains unverified, but it must not mark that block finalized or serve it as validated. Finality advances only after the local fork-choice and state-transition rules accept the checkpoint. A node rechecks its target when peer heads or fork choice show that it followed a stale branch.
Failure handling
A partial stream advances only the verified prefix. Invalid SSZ, context,
signature, parent, sidecar proof, or state transition stops that stream and
triggers peer retry or pruning according to local policy. ResourceUnavailable
selects another peer or a narrower range. An omitted slot is not treated as an
empty slot without chain evidence, and an omitted sidecar or column does not
prove that the block lacked data.
Scope and status
This page defines status, block range and root sync, and sidecar recovery. A payload-envelope sync method is a separate surface from these block-sync guarantees.