AZIP 4: 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.

[mralj]

Unless I'm missing the following adds additional DX complexity.
As @iAmMichaelConnor noted:

Historical L1 access is sparse, not continuous.
get_block_header_at lets apps read the L1 block header that was committed by a past Aztec checkpoint -- one L1 block per checkpoint, roughly one every 72 seconds.
Apps that need to prove an L1 fact from a specific L1 block that happens not to have been the one committed at any Aztec checkpoint (for example, proving the price at exactly L1 block 17,432,108 to settle an auction denominated in an L1 pool, or proving a specific L1 receipt emitted between Aztec checkpoints) have no direct way to do so under this AZIP.
Coverage of L1 history is therefore roughly one L1 block in six under current parameters; the other five are unreachable. Apps needing denser coverage must either (a) proactively mirror the L1 state they care about onto the Aztec side before the relevant L1 block passes, or (b) wait for a future AZIP that exposes parentHash and supports chain-walking back through L1 history (see parentHash in the Rationale's "plausible for inclusion" list).

In addition to above, unless I'm missing something the following could be pain point: how is caller gonna know which L1 blocks Aztec has commited to?
So, for example let's say we have follwowing noir code:

    #[external("public")]
    fn prove_deposit(
        recipient: AztecAddress,
        amount: u128,
        l1_header: L1BlockHeaderData,
        deposit_proof: BridgeDepositProof,
    ) {
        let receipts_root = l1_header.receipts_root;
        let l1_timestamp = l1_header.timestamp;

        let current_commitment = self.context.l1_block_header_data_commitment();
        let opened_commitment =
            compute_l1_block_header_data_commitment(l1_header);

        let header_matches_current_checkpoint =
            opened_commitment == current_commitment;
        assert(
            header_matches_current_checkpoint,
            "Wrong L1 header for current checkpoint",
        );

        let deposit_is_real = verify_bridge_deposit(
            receipts_root,
            deposit_proof,
            recipient,
            amount,
        );
        assert(deposit_is_real, "Missing deposit receipt on Ethereum");
    }

In order to call it we need to provide l1_header & deposit_proof (for which we need to know blockNumber).
I guess in private context we could do following:

1. Have some getter which exposes anchor block's L1 block number
2. Use this to read L1 block number from Aztec, and pass it into RPC call to L1 node which will provide L1 header & proof.

A bit ugly, but doable.
On public side this becomes tricky.

Public context has no historical lookup need as the sequencer is executing and the proof is constructed later when the l1_block_header_data_commitment is known.

So let's say we are sending tx at start of new checkpoint, how can caller of prove_deposit know to which L1 block Sequencer decided to commit to?

[mrzeszutko]

That is a really good question. One more related question @iAmMichaelConnor:

Timing within a checkpoint. Public functions can read the current checkpoint's l1_block_header_data_commitment from the first block of the checkpoint onwards -- the sequencer has it in GlobalVariables as soon as the checkpoint's first block is being built. Private functions prove block-header membership against the archive tree; the archive tree at the start of block K contains headers up to block K-1. A private function executed in the first block of a checkpoint therefore cannot witness its own checkpoint's commitment -- the earliest private access to a checkpoint's new l1_block_header_data_commitment is the second block of that checkpoint. Private functions in the first block can still read any earlier checkpoint's commitment.

I understand how PXE can get access to a checkpoint's new l1_block_header_data_commitment but without the 'l1BlockNumber' the commitment is not usable - I don't understand how can we open it later?. Is there any way to access 'l1BlockNumber' other than propose() calldata? Should this be added to L2Block headers? Or do we assume that PXE can only reference previous checkpoints?

I might be missing something but how is the public function execution supposed to work? how can we actually use the commitment without knowing which L1 block is referenced (we cannot provide the valid proof to the public function without knowing in advance what is L1 Block Number - this is exactly what @mralj is asking about. What is more even if we update the design (for example adding L1BlockNumber to L2 block headers) then we still have the problem in the first slot of the new checkpoint - not sure if this can be solved but seems like it will not be possible to execute the transaction within the first L2 slot as we will get access to L1BlockNumber starting from the second L2 block.

[mralj]

One more thing, regarding Historical lookups.

This example

fn verify_l1_storage(
    context: &mut PrivateContext,
    l2_block_number: u32,
    l1_block_header_data: L1BlockHeaderData,
    account: EthAddress,
    slot: Field,
    expected_value: Field,
    account_proof: MPTProof,
    storage_proof: MPTProof,
) {
    let header = context.get_block_header_at(l2_block_number);
    assert(poseidon2_hash(l1_block_header_data.serialize()) == header.global_variables.l1_block_header_data_commitment);
    let acct = mpt::verify_account(l1_block_header_data.state_root, account, account_proof);
    mpt::verify_storage(acct.storage_root, slot, expected_value, storage_proof);
}

Implies caller to have access to ethereum archive node, because one can pass in pretty old l2_block_number. Since archive nodes are pretty expensive and not that widely used (at least not compared to the regular nodes) I'd stress this out in this seciton.

[mrzeszutko]

On prevRandao as an entropy source — the freshness window enables grinding

Worth flagging more explicitly that prevRandao exposed via this AZIP is materially weaker than prevRandao read directly on L1, and the doc currently sells it as "public entropy from the beacon chain; useful for randomness-sensitive apps" without warning app developers about the grinding surface.

MAX_L1_BLOCK_LAG = 12 means the Aztec proposer picks which L1 block's prevRandao to commit, from up to 12 candidates, at zero marginal cost beyond ordinary block selection. For an app reading randomness from the commitment, this is up to 12 independent draws — the proposer keeps the most favorable one.

Worked example: a prevRandao % 100 == 0 lottery has a base win rate of 1%. A self-dealing sequencer proposing the checkpoint that includes their own ticket sees 1 − 0.99^12 ≈ 11.4% — an ~11x grind, undetectable on-chain since all 12 candidates are valid L1 blocks.

This is a specialization of the MEV surface already noted in con no 5, but I think it deserves its own callout because the affected audience (randomness consumers — lotteries, fair mints, randomized auctions, gaming) is exactly the audience the field's description invites.

There is a viable in-AZIP fallback for apps that need grinding-resistant randomness: don't read the committed prevRandao directly — instead, use the also-committed parent_beacon_block_root to open an SSZ proof to a finalized epoch's randao_mixes[] entry. That reduces the proposer's grinding window to essentially zero, at a cost of ~600k gates per the AZIP's own beacon-proof estimate.

Two ways forward seem reasonable:

1. Drop prevRandao from the committed set. It's a footgun whose only safe use already routes through parent_beacon_block_root. Removing it shrinks the preimage and removes an attractive-but-misleading API surface. Apps that want grinding-biased entropy as a seed can still get it via a copier contract.
2. Keep it, but document the limitations. Reword line 252 to frame prevRandao as a biasable public seed (not fair randomness), and add a note in Security Considerations that any application using it for value-bearing randomness MUST layer commit-reveal, a VRF, or the SSZ-to-finalized-RANDAO path on top.

[mrzeszutko]

A few personal remarks on the proposal:

• I think I'd like the prevRandao to be removed from the initial set of fields (rationale in my previous comment)
• parentHash seems to me to be useful - maybe we can include it in the initial set of fields
• I'm not sure if I like the TODOs (U256 representation and canonical serialisation) - they can be deferred to the implementation PR but seem like important decisions so including them in the AZIP will open the discussion.

[joeandrews]

I think this makes sense especially if advanced users can still access via parent_beacon_block_root or similar.

[mrzeszutko]

Gap: attestor-side checkpoint validation is unspecified

The AZIP carefully spells out the L1 propose() checks (§"L1 verification in propose()") and the rollup-circuit constraints (§"Rollup circuit constraints"), but is silent on what attestors verify before signing a proposed checkpoint. That seems like a real omission — attestors are the last filter before a malformed checkpoint wastes a slot via L1 revert, and they're the only actor that can catch a proposer whose L1 view diverges from the rest of the network before propose() lands.

Concretely, I think attestors need to perform:

1. L1 header authenticity against their own L1 view. Independently fetch the block at l1BlockNumber via their own RPC and verify keccak256(rlpL1BlockHeader) matches. This is the one check the on-chain propose() cannot replicate ahead of time — it's the whole reason for doing it at the attestor layer.
2. Freshness (l1BlockNumber >= block.number - MAX_L1_BLOCK_LAG) against the attestor's own L1 tip.
3. Monotonicity (l1BlockNumber > previousProposedHeader.l1BlockNumber).
4. Commitment binding. Re-extract the six fields from the RLP, recompute both sha256ToField and poseidon2_hash, and verify each matches the proposer's claimed ProposedHeader.l1BlockHeaderDataCommitmentSha256 and the value the proposer will publish in GlobalVariables.
5. (Soft) reorg conservatism. Attestor-side enforcement of l1BlockNumber <= currentL1Tip - MIN_ATTESTOR_LAG. This is where the "sequencer client defaults MUST ship this conservatism" language from con no 4 (azip-4.md:48) actually gets teeth — without an attestor check it's purely honor-system on the proposer.

Open question: should any of these be slashable? My instinct is to split them:

• Slashable: signing on non-monotonic l1BlockNumber, signing on a header whose sha256ToField doesn't bind to the claimed six fields, signing on a header whose keccak doesn't match blockhash(n). These are objectively verifiable from the signed payload alone — there's no "I had a different L1 view" defense.
• Not slashable: L1-view disagreement (their RPC was lagging, or they were briefly on a transient L1 fork) and the reorg-conservatism soft check. Slashing here creates a perverse incentive for attestors to refuse to sign anything risky, which converts a safety mechanism into a liveness drag.

Related design choice this surfaces: the AZIP currently argues against specifying MIN_L1_BLOCK_LAG at the protocol level (azip-4.md:52), on the theory that sensible client defaults suffice and a follow-up AZIP can add it later non-breakingly. If we're already opening up the attestor-validation surface in this AZIP, it might be cheaper to fold a small MIN_L1_BLOCK_LAG in now rather than ship the attestor spec twice. Worth deciding explicitly either way.

[iAmMichaelConnor]

Great points! I think I agree to all of them, and to your proposed split of slashing conditions.

[joeandrews]

A simpler idea (credit to @iAmMichaelConnor for the original out of protocol design) would be to use a portal and slashing incentive to achieve a similar result via L1 --> L2 messages. Separately work could be done to speed up the L1 -- L2 message lag.

The design

1. An L1 portal contract calls blockhash(block.number - 1) and sends it as an L1→L2 message to a storage root contract on L2.
2. Proposers must include this call in their checkpoint multicall. A new slashing condition is created and enforced by node software. If they do not a small slash would occur.
3. An L2 contract consumes the message and stores the block hash.
4. Any contract can verify L1 state by checking an RLP header against the stored hash and running MPT proofs against the extracted roots.

This does require an AZIP for the slashing condition changes and a new "L2" protocol contract and portal that all sequencers must reference.

The gas costs of this approach are substantially higher, but the benefits are large. No protocol / L1 contract changes or new audits of critical code, no circuit changes, and no AVM changes.

In protocol: ~10k gas per checkpoint
Portal: ~20k - ~50k gas per checkpoint depending on if the message box was used already between checkpoints.

Rewards could be adjusted as a result if this is deemed meaningful.

[mralj]

@joeandrews, just so I'm sure I got it correct.
Let's say the current proposer is P and the next one is P'.

1. When calling propose, P batches (multicall) the tx, which enqueues the L1->L2 message with blockhash.
2. P pays L1 gas fees for this
3. P' picks it up as part of consuming the Inbox

How do we cover the costs of P?

---

Is the above correct?

[joeandrews]

Sorry for the delay, yes this is correct. The additional gas fees are just born by P. Their job just got harder. If this is deemed to be too costly, we can increase the block reward to compensate.

[joeandrews]

The main change would be that the protocol slashing rules are updated to enforce this call.