> For the complete documentation index, see [llms.txt](https://corpus-core.gitbook.io/specification-colibri-stateless/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://corpus-core.gitbook.io/specification-colibri-stateless/introduction/architecture/blocks.md).

# 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.