How are apps and infras affected by Aztec block times and how to handle re-orgs

Aztec
1

Re-orgs on Aztec work similarly to Ethereum, due to Aztec being decentralized and using POS). This post talks about how to consider finality of a block on Aztec and what to do an someone building an app or infra on top of Aztec.

We will very briefly explore

  • How finality on Aztec works and where a re-org may happen
  • What should infra providers and apps do

We will NOT explore

  • What a re-org is
  • All the reasons a re-org can happen on Aztec
  • Economics of aztec’s decentralized sequencer and prover that prevent malicious activity

If you don’t know what a re-org is or why they happen, here is a good article.

Section 1: Finality on Aztec and re-orgs

Journey of an Aztec block

  • An L2 block is expected to be created every ~30s by a sequencer - this is preconfirmation.
  • Every block is posted to L1 and attested by a committee of validators to assess correctness.
  • Like all zkRollups, instead of posting a proof per L2 block, a prover batches 32 L2 blocks together and creates a proof for them.
  • Once a prover posts a proof for it and it is verified on the rollup contract, we call these blocks “proven”
  • Provers have a “window” upto which they can post a proof of the block. Currently this window is configured to be the time to build the epoch + 63 L2 blocks.
  • On average, a transaction on Ethereum is considered final after ~12 mins or two Ethereum epochs. At this point, the proven L2 blocks are considered finalized.

Nomenclature

  • This time period (of waiting for a batch of blocks) is called an aztec epoch.
  • There are 32 blocks in every epoch, meaning an epoch is ~16 minutes long.
  • The chain being built on latest blocks (that aren’t proven) is called the “pending chain” (since it is not final or proven but its correctness is simply attested by validators).
  • Proof submission window is therefore almost 2 aztec epochs after the first epoch (the one to be proven) is posted to L1.

Note that due to Aztec’s permissionless nature, if you have a transaction in a block on the pending chain and can’t wait for the entire epoch, you can just go and prove the pending chain till this point and verify the proof on our L1 Rollup Contract forcing the block to achieve proven (and subsequently finalized) status quicker.

A summary in a (not so) pretty diagram

image
image1330×482 39.5 KB

Where can a reorg happen on Aztec

  1. Pending chain (i.e. all blocks not proven or finalized) - at max, this is last 95 blocks (first epoch (32 blocks) + 63 blocks is the proof submission window). This can be because:
    a. no provers were able to post a proof
    b. epoch has invalid blocks
    c. bugs in the prover node
    d. bugs in the sequencer creating invalid blocks
  2. Proven blocks (i.e. all blocks that were proved on L1) - only if there is a re-org on L1.

How do I check the block status?

Aztec node has an RPC method called node_getL2Tips which return the latest L2 block number in all 3 phases:

[22:34:00.321] DEBUG: json-rpc:client result node_getL2Tips {
  jsonrpc: '2.0',
  id: 15,
  result: {
    latest: {
      number: 598,
      hash: '0x1456fa91b13142de3a8088857a1a2fe315397bfe629f9b80483328fec41aa8b0'
    },
    proven: {
      number: 556,
      hash: '0x0ceb877098e81c56066e7ed2320fa1a17119da14b06c9d6ffa9dffebb4f0389c'
    },
    finalized: {
      number: 556,
      hash: '0x0ceb877098e81c56066e7ed2320fa1a17119da14b06c9d6ffa9dffebb4f0389c'
    }
  }
}

Here blocks 557-598 are in the pending chain. All blocks till 556 are proven and finalized on L1.
:warning:
As of April 2025, proven and finalized mean the same thing. We will soon change it to imply finalized = ~12 mins after the proven blocks are verified on L1.

What should I do as an app or infra builder?

  1. Decide if you are happy with sequencer preconfirmation or proven or finalized?
  2. Detect a re-org by checking if your node block number has reduced. Convey to the users as their transactions may have been undone.

Block Explorers

All blocks should show one of 3 status:

  • preconfirmation / soft finality
  • proven on L1
  • finalized on L1
    You can get the status via the node_getL2Tips RPC call.

When in re-org show an alert and mention affected block range (typically all unproven blocks)

Supplemental Reading

For brevity, this document only explored the happy path (when sequencers create their blocks and aren’t malicious and when provers submit proofs). To know about slashing and how Aztec achieves censorship resistance, consider reading Request For Comments: Aztec's Block Production System

Disclaimer

The published request for proposal and ideas herein are explicitly published as discussion points to invite community feedback in the community forums. Robust design and developer discussion is the best way for the community to collectively secure and govern the network as well as ensure cross-chain interoperability. Any ultimate governance and cross-chain designs will be a result of the analysis and feedback of the community.The information set out herein is for discussion purposes only and does not represent any binding indication or commitment by Aztec Labs and/or affiliates and their employees//consultants to take any action whatsoever, including relating to the structure and/or any potential operation of the Aztec protocol or the protocol roadmap. In particular: (i) nothing in this post (and any response to this post) is intended to create any contractual or other form of legal, investment, financial, tax or advisory relationship between Aztec Labs or third parties who engage with such posts (including, without limitation, by submitting comments, a proposal and/or responding to posts including any medium such as X, Discord, etc), (ii) by engaging with any post, the relevant persons are consenting to Aztec Labs’ use and publication of such engagement and related information on an open-source basis (and agree that Aztec Labs will not treat such engagement and related information as confidential), and (iii) Aztec Labs is not under any duty to consider any or all engagements, and that consideration of such engagements and any decision to award grants or other rewards for any such engagement is entirely at Aztec Labs’ sole discretion. Please do not rely on any information on this forum for any purpose - the development, release, and timing of any products, features or functionality remains subject to change and is currently entirely hypothetical. Nothing on this forum post should be treated as an offer to sell any security or any other asset by Aztec Labs or its affiliates, and you should not rely on any forum posts or content for advice of any kind, including legal, investment, financial, tax or other professional advice.

1 Like
2

Thanks for the post, Rahul.

It is possible for finality to take longer than 12 minutes. Will the Aztec sequencer/full node implementation take this edge case into account? The implementation could use eth_getBlockByNumber with the finalized label to track the finalized Ethereum head, rather than merely waiting for ~12 minutes and hoping Ethereum reaches finality.

If block 556 is already finalized, wouldn’t the pending chain be composed of blocks 557-598?

3

Correct on 557-598 - corrected!

It is possible for finality to take longer than 12 minutes.

Clarified - this is on average - ofcourse if your transaction is at the start of an ethereum epoch, then you should wait for 3 epochs for finality. The full node definitely won’t just wait for ~12 minutes to hope ethereum reaches finality.

Also currently, the full node makes no distinction between proven and finalized. That will change soon!

1 Like