Owner: @Youngjoon Lee

Synchronization Strategies

<aside> 💬

Reference: Ethereum Beacon Chain - Checkpoint Sync

• The sync protocol is not defined in the Ethereum consensus specifications. Instead, it is client-specific. https://lighthouse-book.sigmaprime.io/checkpoint-sync.html https://docs.prylabs.network/docs/prysm-usage/checkpoint-sync

• All the following mechanisms were obtained by: Code Investigation: https://github.com/sigp/lighthouse. </aside>

• Full sync: Syncing blocks from the genesis by re-executing every transaction.

  • Time-consuming and resource-intensive. But still, this is an option for someone who wants to verify all historic transactions and states.
  • This is implemented using the range sync described below.
  • This has a risk of long-range attacks in Ethereum.
    • An attacker can build a fake chain from a certain block in the past by stealing or purchasing signing keys of past validators who have already exited. If a newly joining node receives blocks from the attacker, he doesn’t have enough context to distinguish whether those blocks are on the fake chain or not. If the fake chain wins other chains according to the fork-choice rule, the syncing node will end up following a wrong chain.
      • https://youtu.be/-gISJtRlTK8?si=5k1UOFQPPMdcWJti
      • Ethereum introduces the checkpoint sync to avoid this risk.

• Range Sync: A mechanism used internally by Full Sync and Checkpoint Sync.

  • Whenever a new peer is connected, check the chain status (head, etc.) of the peer and determine whether a syncing should be started: Range Sync.
  • If so, request blocks by range to the peer and apply them to the local chain.
  • If there are multiple peers that can provide the same set of blocks, split the request into small batches, distribute them to the peers, and merge blocks responded.
  • If there are multiple peers that provide different chains, accept and keep all of them.

• Checkpoint sync: Fetching a recently finalized checkpoint, including the associated block and anything necessary (e.g. state), from a trusted node (or via file import), and starting syncing forward to the head of the chain.

  • This is the default option for most Ethereum consensus implementations.
  • Much faster (minutes to sync) than full sync (days to weeks).
  • The checkpoint sync is basically done by two simple HTTP calls: GET finalized_block and GET finalized_state
    • The checkpoint providers responds with a recently finalized checkpoint (the last slot/state of the finalized epoch).
  • The loaded checkpoint should be verified in a lightweight way (e.g. comparing the root hash with the one from a trusted block explorer).
  • The forward sync is done by the range sync described above, once the checkpoint sync is completed.
  • A validator can start its duty once the forward sync is done.
  • (Optional) Backfilling: Once the forward sync is completed, the node can optionally start the backfilling sync to download the blocks from the checkpoint back to the genesis or a certain point. This should be rate-limited to not affect node performance.
  • The endpoints of checkpoint providers can be provided as https://eth-clients.github.io/checkpoint-sync-endpoints/.
  • Downsides compared to full sync
    • Relies on a trusted checkpoint provider.
    • Does not contain the full chain history. Only starts from a recent finalized checkpoint.
      • This may be fine unless a user wants to run an archive node.
  • In Ethereum, the checkpoint sync is considered more secure than the full sync, thanks to the protections against long-range attacks afforded by weak subjectivity.

Code Investigation: https://github.com/sigp/lighthouse

Checkpoint Sync

• When the lighthouse process is started, if the --checkpoint-sync-url is set,

  https://github.com/sigp/lighthouse/blob/029b4f21047c37d1ffde51c554737b1aa0880f97/beacon_node/client/src/builder.rs#L385-L385

  • Connect to the checkpoint provider via HTTP and request a recent finalized checkpoint (block and state).
  • Let the forward sync started by the regular Range Sync.
  • This is exactly the same as the explanation in https://lighthouse-book.sigmaprime.io/checkpoint-sync.html.

Range Sync

Requester

• Whenever a new peer is connected, check if a syncing needs to be started: https://github.com/sigp/lighthouse/blob/029b4f21047c37d1ffde51c554737b1aa0880f97/beacon_node/network/src/sync/manager.rs#L753-L753.
  • A newly connected peer sends us a status message. First of all, check if the peer is relevant to us, meaning that the peer is not on a different chain: https://github.com/sigp/lighthouse/blob/bf955c7543dac8911a6f6c334b5b3ca4ef728d9c/beacon_node/network/src/network_beacon_processor/rpc_methods.rs#L115.
  • If the peer is relevant, we determine a sync type by comparing their chain info with ours: https://github.com/sigp/lighthouse/blob/bf955c7543dac8911a6f6c334b5b3ca4ef728d9c/beacon_node/network/src/sync/manager.rs#L390-L390.
    • Here, we need head_slot as well as head_root. Also, finalized_epoch and finalized_root.
    • If peer.head_slot > local.head_slot + 32, we consider that the peer is sufficient ahead from us and start a range sync: https://github.com/sigp/lighthouse/blob/bf955c7543dac8911a6f6c334b5b3ca4ef728d9c/beacon_node/network/src/sync/manager.rs#L378-L378
      • Or, if peer.finalized_epoch > local.finalized_epoch, also start a range sync but with a different type.
• All on-going range syncs are managed by the RangeSync struct: https://github.com/sigp/lighthouse/blob/029b4f21047c37d1ffde51c554737b1aa0880f97/beacon_node/network/src/sync/range_sync/range.rs#L67-L67.
  • Determine the sync type again: https://github.com/sigp/lighthouse/blob/bf955c7543dac8911a6f6c334b5b3ca4ef728d9c/beacon_node/network/src/sync/range_sync/range.rs#L131-L131.
    • A sync is always started from the start slot of a certain epoch: https://github.com/sigp/lighthouse/blob/bf955c7543dac8911a6f6c334b5b3ca4ef728d9c/beacon_node/network/src/sync/range_sync/range.rs#L155-L155 and https://github.com/sigp/lighthouse/blob/bf955c7543dac8911a6f6c334b5b3ca4ef728d9c/beacon_node/network/src/sync/range_sync/range.rs#L188.
• Individual syncing is managed by the SyncingChain struct, which is held in the RangeSync struct: https://github.com/sigp/lighthouse/blob/029b4f21047c37d1ffde51c554737b1aa0880f97/beacon_node/network/src/sync/range_sync/range.rs#L67-L67.
  • The SyncingChain struct contains all meaningful methods.
    • Requesting the next batches from the peer: https://github.com/sigp/lighthouse/blob/029b4f21047c37d1ffde51c554737b1aa0880f97/beacon_node/network/src/sync/range_sync/chain.rs#L1053-L1053
      • If there are multiple peers that agree on the target head as a canonical chain (i.e. if multiple peers have been added to the SyncingChain), shuffle the peers, distribute the batch requests across them, and merge responses. The length of a batch is 2-epoch. Each peer is requested for a single batch: https://github.com/sigp/lighthouse/blob/029b4f21047c37d1ffde51c554737b1aa0880f97/beacon_node/network/src/sync/range_sync/chain.rs#L1098

Responder

• Handles requests: https://github.com/sigp/lighthouse/blob/029b4f21047c37d1ffde51c554737b1aa0880f97/beacon_node/network/src/router.rs#L213-L213
  • Core logic: https://github.com/sigp/lighthouse/blob/bf955c7543dac8911a6f6c334b5b3ca4ef728d9c/beacon_node/network/src/network_beacon_processor/rpc_methods.rs#L648-L648
    • Open an iterator from the start slot specified in the request to the chain head. If there is a skipped slot, the iterator returns the same block ID as the previous. Take this iterator while a slot returned from the iteration is smaller than req.start_slot + req.count because some requests are not for syncing to the chain head.
    • Even though the requester requests all blocks by range, the responder responds multiple times for each block separately: https://github.com/sigp/lighthouse/blob/029b4f21047c37d1ffde51c554737b1aa0880f97/beacon_node/network/src/network_beacon_processor/rpc_methods.rs#L788-L788.

Requester, again

• The response is handled by https://github.com/sigp/lighthouse/blob/029b4f21047c37d1ffde51c554737b1aa0880f97/beacon_node/network/src/router.rs#L343-L343 and https://github.com/sigp/lighthouse/blob/029b4f21047c37d1ffde51c554737b1aa0880f97/beacon_node/network/src/sync/manager.rs#L762-L762.
  • Because responders responds with each block separately, the requester gathers all responses and processes them once all blocks requested are received completely: https://github.com/sigp/lighthouse/blob/029b4f21047c37d1ffde51c554737b1aa0880f97/beacon_node/network/src/sync/network_context.rs#L514-L514

Backfilling

• Calculating the weak subjectivity point in which to backfill blocks to: https://github.com/sigp/lighthouse/blob/bf955c7543dac8911a6f6c334b5b3ca4ef728d9c/beacon_node/beacon_chain/src/builder.rs#L882-L882