As part of the changes for Alpha, we are tweaking our block building to produce multiple blocks per slot. Given this change impacts not just node operators but also end users, we wanted to share some insights on how it works.
How things work today on Ignition
Today, the Aztec Network splits time in 72s slots. During each slot, a proposer drafted at random from the staker set is given exclusive block-proposal rights. The proposer is expected to assemble a block proposal, and broadcast it via the p2p network. A block proposal contains a list of tx identifiers to be included, as well as the expected state after executing them.
The proposer then collects attestations for its block proposal. These attestations are produced by an attestation committee, again drafted at random from the staker set. The committee’s reponsibility is attesting to 1) the availability of the txs included in the proposal, and 2) the state root resulting from executing them.
Once the proposer has collected enough attestations, it pushes the block to the Aztec Rollup Contract on L1 (Ethereum). The rest of the network then syncs this block by downloading it from L1, validates the attestations from the committee members, and adds the block to its view of the chain.
Why this is not optimal
Because we have 72s blocks. That’s not good user experience. We want the user to get a quicker assurance that their tx has been included in a block.
We briefly considered a flavor of inclusion preconfirmations so we could let the user know immediately that their tx would be included. However, we decided against it, and for a good reason. Transactions in Aztec have what’s called an anchor block. This is the block used for all merkle inclusion proofs done as part of private execution. To illustrate, let’s say you want to consume a note as part of your tx: you have to include in your zk proof that said note is part of the chain state, and you do that by showing a merkle inclusion proof against a known root - the anchor block. This means that, if you want to consume a note that was just created, you need the block in which it was included. So this means that, even if we had preconfirmations, if a user sent a tx, they’d still have to wait 72s to be able to use whatever came out of that tx. Still poor user experience.
Multiple blocks per slot
The solution is then producing more than a single block per slot. During the slot, the proposer assembles multiple blocks, one after the other, and broadcasts them via the p2p network. Nodes grab these block proposals and reexecute them, adding them immediately to their view of the chain. Nearing the end of the slot, the proposer signals the end and sends a request for attestations, which is replied to by the committee as it does today. The difference here is that the committee attests to the validity of all block proposals in the slot.
Once the proposer has collected the attestations, they submit all block proposals to L1 in what we call a checkpoint. Nodes in the network sync the checkpoint from L1, and reconcile their view of the chain with it, in case they failed to reexecute the block proposals as they were sent via p2p. This gives us much smaller user-perceived latency, by producing more blocks at smaller intervals.
What this means for tx finalization
This new design directly affects transaction finalization, meaning how confident you can be that your tx, once included, will not be reorg’d out of the chain. We now have 4 different finalization stages:
- Proposed: Your transaction is in a block proposal that has been gossipped on the p2p network by the current proposer, and your node has reviewed as valid. The time-to-proposed depends on the block time. A proposed tx may be rolled back if there is too much L1 congestion, and does not get checkpointed within the 72s slot, in which case it needs to be picked up in a new block in a new slot.
- Checkpointed: Your transaction has been checkpointed to the L1 rollup contract. The time-to-checkpointed depends on the slot time (72s). A checkpointed tx may be rolled back if it does not get proven in time within the next epoch.
- Proven: Your transaction has been proven by a rollup validity proof submitted by a prover (we’re a validity rollup[1], so everything gets proven!). If your tx included an exit to L1, this exit is now executable. The time-to-proven depends on the duration of an Aztec epoch, usually 32 L2 slots (about 40 minutes). A proven tx may be rolled back if there’s a significant enough L1 reorg that all validity proofs are removed.
- Finalized: Your transaction will not be removed, since it has been proven on L1, and the L1 block that contains the proof has been L1-finalized (as defined by Casper).
Validity rollups are often referred to as zk rollups. But there’s nothing zero-knowledge about proving the validity of executing a set of transactions to convince L1 of its correctness. Note that Aztec does have zk-proofs, but those are generated in your wallet to produce private txs. ↩︎