This EIP defines a mechanism for syncing light client data between beacon nodes.
Light client data is collected by beacon nodes to assist light clients to sync with the network. The sync protocol defines a mechanism to sync forward in time. However, it cannot be used to sync backward.
Collecting light client data is challenging because beacon nodes need to have access to the corresponding BeaconState and SignedBeaconBlock. BeaconState objects are not available before the initially synced checkpoint state, and SignedBeaconBlock objects have a limited retention period on libp2p.
Furthermore, each sync committee period consists of EPOCHS_PER_SYNC_COMMITTEE_PERIOD * SLOTS_PER_EPOCH slots. To support archive services such as Portal network to provide a consistent view regardless of backend, it is necessary to choose a single canonical slot for which to derive the representative light client data for that period. Such data should be verifiable to be canonical and optimal in a decentralized and independent manner.
To support light client data backfill, this EIP proposes to track the canonical and optimal SyncAggregate in the BeaconState. This minimal addition allows proving that derived LightClientUpdate and LightClientBootstrap are also canonical and optimal.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
SyncDataBeaconStateNew fields are added to the end of BeaconState from the activating fork onward to track the current and previous sync committee period's best sync data.
default_sync_dataprocess_sync_committee_updatesOn sync committee boundaries, current period data is moved to previous period. This allows proving that light client data for the previous period is canonical.
Block processing is extended to track the optimal light client data for the current period. Due to the possibility for empty slots this must be tracked before the block header is overwritten; this allows tracking the exact block after which next_sync_committee becomes finalized.
process_best_sync_dataSyncAggregate?The EIP reuses the is_better_update function from existing specs.
Once the data is available in the BeaconState, a light client data backfill protocol could be defined that serves, for past periods:
LightClientUpdate from requested period + 1 that proves that the entirety of period is finalized.BeaconState.historical_summaries[period].block_summary_root at (1)'s attested_header.beacon.state_root + Merkle proof.period, the corresponding LightClientHeader + Merkle multi-proof for the block's inclusion into (2)'s block_summary_root.beacon.slot within period, the current_sync_committee_branch + Merkle proof for constructing LightClientBootstrap.period's current_sync_committee.LightClientUpdate from period, if one exists, + Merkle proof that its sync_aggregate + signature_slot is selected as the canonical best one in (1)'s attested_header.beacon.state_root.Only the proof in (6) depends on BeaconState tracking the best light client data. This modification would enshrine the logic of a subset of is_better_update, but does not require adding any LightClientXyz data structures to the BeaconState.
This EIP requires a hard fork as it introduces new consensus validation rules.
Only light client data following the hard fork can be proven to be canonical and optimal. However, after finalization of the fork transition block, earlier light client data can no longer change and could be locked in using a hash.
None
Copyright and related rights waived via CC0.