# 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**](https://ethereum.github.io/consensus-specs/specs/capella/beacon-chain/#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](https://ethereum.github.io/beacon-APIs/) 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://corpus-core.gitbook.io/specification-colibri-stateless/introduction/architecture/blocks.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.