AZIP 4: Add L1 Block info to public and private context by joeandrews · Pull Request #13 · AztecProtocol/governance

joeandrews · 2026-04-17T10:41:47Z

Draft AZIP to discuss adding L1 block info including storage roots to L2 private and public context.

This AZIP introduces L1 block roots into the Noir contract execution context, enabling trustless reads of L1 state, transactions, and receipts. It outlines the specification for accessing these roots and their implications for various stakeholders.

This AZIP proposal updates the context for accessing L1 block header data in Noir contracts, enhancing the ability to read Ethereum state without oracles. It introduces a new structure for L1 block header fields, optimizing the protocol for trustless reads and reducing gas costs.

Updated the 'discussions-to' field in the AZIP preamble to include a link to the relevant GitHub discussion.

critesjosh

Assigned as AZIP-4 and a couple of nits

critesjosh · 2026-04-21T18:59:12Z

+
+| `azip` | `title`                | `description`                                                                            | `author`                                      | `discussions-to`                                           | `status` | `category` | `created`  |
+| ------ | ---------------------- | ---------------------------------------------------------------------------------------- | --------------------------------------------- | ---------------------------------------------------------- | -------- | ---------- | ---------- |
+| TBD    | L1 Block Header Access | Make L1 block header data available to Noir contracts via a single Poseidon2 commitment. | Joe Andrews (@joeandrews, joe@aztec-labs.com) | https://github.com/AztecProtocol/governance/discussions/12 | Draft    | Core       | 2026-04-17 |


critesjosh · 2026-04-21T19:00:23Z

+
+As Aztec is an Ethereum rollup. Every checkpoint already references an L1 block. This AZIP exposes that block's header to contracts, so any L1 state can be proven with a Merkle-Patricia trie proof in Noir, with no trust beyond L1 consensus.
+
+Rather than adding six fields to `GlobalVariables` (six Fields in every `BlockHeader` hash, six AVM opcodes, six fields through the rollup circuits), we commit them behind a single Poseidon2 hash. Contracts provide the preimage as a witness and open it — one hash check. One Field, one opcode, and extensible: adding header fields later requires only a preimage struct update.


The template.md requires a Rationale section, distinct from Motivation. I think this line would make sense to include in the Rationale section

critesjosh · 2026-04-21T19:00:39Z

+
+New fields in `GlobalVariables`, `BlockHeader`, `CheckpointConstantData`, `CheckpointHeader`, and `ProposedHeader` break the block format. Upgrade via AZUP. Existing contracts unaffected.
+
+## Testing


Suggested change

## Testing

## Test Cases

for consistency

just-mitch · 2026-04-26T16:50:49Z

I investigated the cost of doing an SSZ proof of an EL state root within an CL block hash https://github.com/just-mitch/ssz

Looks like it is roughly 110k gates. Compared to basically a no-op "hello world" transaction (which models the case where the EL state root is provided in the global variables directly), the inclusion proof generation time is

backend	hello_world	verify_el_state_root	delta	ratio
wasm	16.0 s	16.8 s	744 ms	1.05x
native	7.1 s	7.7 s	571 ms	1.08x

Based on this, I think we ought to only include the beacon block hash.

iAmMichaelConnor · 2026-04-27T07:37:20Z

Based on this, I think we ought to only include the beacon block hash.

Cool exploration! I'm not sure I agree with the tradeoff though (yet) -- a 5%-8% slow-down for a slightly tidier design.

My mind might be swayed if:

Proving system optimisations in Q2 are fruitful
We realise that the design of copying-over ~6 L1 block header fields would slow down the rollup (I think the extra sha256 constraints in the parity circuits will not be a bottleneck, but that would need to be checked).

just-mitch · 2026-04-28T10:56:47Z

Cool exploration! I'm not sure I agree with the tradeoff though (yet) -- a 5%-8% slow-down for a slightly tidier design.

No problem. I didn't know what any hard requirements were here. Are you saying that the EL state root must be available for free to applications? I would be willing to make applications that want to use the EL state root "pay" an additional second to save the protocol extra hashing and reduce the time to market and risk of bugs. If we found that users were making heavy use of this feature, we could always bring the hashing in-protocol later.

We probably ought to include a list of requirements we intend to meet at the top of these AZIPs, otherwise it will devolve into gut-checks of what individuals like more on a given day.

iAmMichaelConnor · 2026-04-28T12:12:26Z

@just-mitch I cc'd you on a refactored version of this AZIP, including a list of "cons" that need to be considered -- cons which are likely more of a sticking point than the above discussion.

Not actually sure of the most elegant way to incorporate those thoughts here. A PR into Joe's branch? Kind of ugly.

We probably ought to include a list of requirements we intend to meet at the top of these AZIPs

I think that's what the Motivation section is for.

just-mitch · 2026-04-28T13:57:51Z

refactored version

👍 Thanks Mike

mralj · 2026-04-29T10:26:24Z

@just-mitch I cc'd you on a refactored version of this AZIP, including a list of "cons" that need to be considered -- cons which are likely more of a sticking point than the above discussion.

Not actually sure of the most elegant way to incorporate those thoughts here. A PR into Joe's branch? Kind of ugly.

We probably ought to include a list of requirements we intend to meet at the top of these AZIPs

I think that's what the Motivation section is for.

Maybe we should close this PR and you, @iAmMichaelConnor, open the PR with updated AZIP-4 referencig this (would be closed PR)
I see your PR as an improved version/superset of @joeandrews version, so I don't think anything material would be lost.
And it wuld streamline giving feedback & future discussion :)

iAmMichaelConnor · 2026-04-30T15:58:55Z

@iAmMichaelConnor, open the PR with updated AZIP-4 referencig this (would be closed PR)

Good idea, I'll open a PR shortly

joeandrews · 2026-04-30T16:06:13Z

All good to close mine @iAmMichaelConnor. Thanks for refactoring. @just-mitch we also need to account for the mana cost of ssz, maybe its negligible but I imagine a lot of use cases will defer the SSZ to a public function to do. Maybe thats a good for fees though :D

iAmMichaelConnor · 2026-04-30T16:13:17Z

As per above, closing and continuing discussion here: #24

joeandrews added 3 commits April 15, 2026 15:54

Add discussions link to AZIP preamble

e3f9105

Updated the 'discussions-to' field in the AZIP preamble to include a link to the relevant GitHub discussion.

joeandrews requested a review from a team April 17, 2026 10:41

joeandrews added 2 commits April 17, 2026 12:45

Format AZIP-4 for improved readability

d4ad6fc

Rename azip-4 to azip-4.md

623e77f

critesjosh approved these changes Apr 21, 2026

View reviewed changes

	\| TBD \| L1 Block Header Access \| Make L1 block header data available to Noir contracts via a single Poseidon2 commitment. \| Joe Andrews (@joeandrews, joe@aztec-labs.com) \| https://github.com/AztecProtocol/governance/discussions/12 \| Draft \| Core \| 2026-04-17 \|
	\| 4 \| L1 Block Header Access \| Make L1 block header data available to Noir contracts via a single Poseidon2 commitment. \| Joe Andrews (@joeandrews, joe@aztec-labs.com) \| https://github.com/AztecProtocol/governance/discussions/12 \| Draft \| Core \| 2026-04-17 \|


		As Aztec is an Ethereum rollup. Every checkpoint already references an L1 block. This AZIP exposes that block's header to contracts, so any L1 state can be proven with a Merkle-Patricia trie proof in Noir, with no trust beyond L1 consensus.

		Rather than adding six fields to `GlobalVariables` (six Fields in every `BlockHeader` hash, six AVM opcodes, six fields through the rollup circuits), we commit them behind a single Poseidon2 hash. Contracts provide the preimage as a witness and open it — one hash check. One Field, one opcode, and extensible: adding header fields later requires only a preimage struct update.


		New fields in `GlobalVariables`, `BlockHeader`, `CheckpointConstantData`, `CheckpointHeader`, and `ProposedHeader` break the block format. Upgrade via AZUP. Existing contracts unaffected.

		## Testing

Conversation

joeandrews commented Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

critesjosh left a comment

Choose a reason for hiding this comment

Uh oh!

critesjosh Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

critesjosh Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

critesjosh Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

just-mitch commented Apr 26, 2026

Uh oh!

iAmMichaelConnor commented Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

just-mitch commented Apr 28, 2026

Uh oh!

iAmMichaelConnor commented Apr 28, 2026

Uh oh!

just-mitch commented Apr 28, 2026

Uh oh!

mralj commented Apr 29, 2026

Uh oh!

iAmMichaelConnor commented Apr 30, 2026

Uh oh!

joeandrews commented Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iAmMichaelConnor commented Apr 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

joeandrews commented Apr 17, 2026 •

edited

Loading

iAmMichaelConnor commented Apr 27, 2026 •

edited

Loading

joeandrews commented Apr 30, 2026 •

edited

Loading