Block Verification

Blocks in the execution layer are verified indirectly through the consensus layer. Each BeaconBlock contains an executionPayload that embeds the corresponding execution-layer block data. Core information such as blockNumber, blockHash, and transactions can therefore be validated directly by verifying the BeaconBlock itself. Other execution-layer elements, including stateRoot, receiptsRoot, and contract-related data, require additional Merkle proofs from the execution layer to establish full validity.

Consensus-Layer Validation

The validation of a BeaconBlock starts from a trusted checkpoint — a verified state from which the validator set can be deterministically derived. From this checkpoint, the validator set is updated through a continuous sequence of validator transitions recorded in the consensus layer. Each transition defines the next active validator set used to form the subsequent Sync Committee.

A Sync Committee contains 512 validator public keys that rotate every period of approximately 27 hours (8192 slots). The colibri.stateless client maintains or reconstructs the current validator set by verifying these transitions and ensuring that each Sync Committee is derived from previously verified data.

Once the correct validator set and Sync Committee are established, the client verifies the aggregated BLS signature included in the block’s sync aggregate. This signature confirms that a majority of the committee members have attested to the block root. Successful verification of this signature proves that the block belongs to the canonical chain.

This process ensures that each verified BeaconBlock is cryptographically anchored in a verified sequence of validator transitions, providing full consensus-layer integrity without requiring full chain synchronization.

Verification of Historical Blocks

To verify older block hashes or transaction data, the client can use a BeaconState corresponding to an earlier period and generate a Merkle proof for the historical roots. The Ethereum consensus specification defines a long-term storage mechanism for these roots. The list of historical roots has a maximum length defined as:

HISTORICAL_ROOTS_LIMIT = 2 ** 40  # ≈ 52,262 years

Since the Capella Fork, the BeaconState includes HistoricalSummary entries containing both block roots and state roots. This enables Merkle proofs for any block root within the historical data structure, providing long-term verifiability of execution data.

Future Specification Work

The current Ethereum Beacon API does not yet expose endpoints to request proofs for historical roots or related data. A dedicated EIP is planned to extend the API with endpoints for proof generation and retrieval, allowing stateless clients to request and verify historical consensus data natively.