Add L1 Block Info to L2 context

[joeandrews]

Aztec contracts can't read Ethereum state directly. If you want to verify an L1 balance, check a Uniswap price, or confirm a bridge deposit landed, you either trust an oracle or must send a message through the L1→L2 inbox.

Aztec is an Ethereum rollup so access to this data is easy to include directly from L1.

Proposal

Add a single Poseidon2 commitment to six L1 block header fields (state_root, receipts_root, block_number, timestamp, prev_randao, parent_beacon_block_root) as one Field l1_block-hash in GlobalVariables. L2 Contracts can open the commitment with a preimage and use the raw fields for MPT proofs, receipt proofs, or beacon chain state proofs.

The mechanism piggybacks on the existing L1→L2 message infrastructure using the same dual-hash pattern (SHA256 on L1, Poseidon2 in circuits), same block root first rollup integration point, same propagation through merges. The addition costs ~10k gas per checkpoint

Motivation

Trustless L1 state reads — verify any account, balance, storage slot, or contract code via MPT proof against state_root
Event proofs — prove an L1 event was emitted via receipts_root, enabling trust-minimized bridge designs
Beacon chain access — prove validator sets, staking balances, and consensus-layer data via parent_beacon_block_root
L1 clock + randomness — timestamp for freshness enforcement, prev_randao for public entropy

Feedback wanted

The AZIP excludes transactions_root, parent_hash and gas fields. Should any of these be included?
Is the freshness bound (MAX_L1_BLOCK_LAG) of ~144 seconds needed / correct?

Are there use cases we're missing that would change the design?

[joeandrews]

Draft AZIP here: https://github.com/joeandrews/governance/blob/623e77ff0e1726b3ddac87204bdb0f9d594ccced/AZIPs/azip-4.md

[mralj]

@joeandrews there are parts that are a bit confusing.
Here we define L1BlockHeader as a struct with 6 fields.

Then in propose verification you state:

The proposer submits the RLP-encoded L1 block header and l1BlockNumber as calldata. propose() verifies:

1. keccak256(rlpHeader) == blockhash(l1BlockNumber) — the header is real.
2. l1BlockNumber >= block.number - MAX_L1_BLOCK_LAG — the header is fresh.
3. sha256ToField(extracted_fields) == ProposedHeader.l1BlockHash — the commitment matches.

Without the freshness check, a sequencer could reference any block within the 256-block blockhash window (~51 minutes of staleness) and manipulate oracles. MAX_L1_BLOCK_LAG SHOULD be 2 * AZTEC_SLOT_DURATION / ETHEREUM_SLOT_DURATION (currently 12 blocks, ~144 seconds). block.number costs 2 gas, no storage required.

l1BlockNumber is calldata-only — not stored, not in ProposedHeader. It's already committed inside the sha256ToField as one of the six fields. ProposedHeader gains a single field: l1BlockHash (bytes32).

So I assume in propose section, RLP-encoded L1 block header is full, real Ethereum L1 block header and not the one previously defined in struct L1BlockHeader - otherwise blockhash would not match, am I correct?

Furthermore, naming here again is bit confusing:

sha256ToField(extracted_fields) == ProposedHeader.l1BlockHash

I assume l1BlockHash is not really the real L1 Block Hash, but hash of the fields as defined in the struct L1BlockHeader?

Finally in order to have extracted_fields - we'd need decode RLP - there is no mention of this in AZIP - contract logic will have to be up to date with latest L1 fork in order for RLP parsing to work correctly.

[mralj]

@joeandrews @The-CTra1n (Conor) had an interesting idea - instead of relying on 6 fields, we do rely only on parent_beacon_block_root + block_number. And then use SSZ proofs to get excetution block header fields.