Update on Proving Coordination

[amin]

It’s been 9 months since the RFC on block production was posted to the forum. Today, we’re sharing a significant update to how sequencers interact with provers to finalize blocks on the Aztec network. This post outlines what’s changed and why.

For readability, I opt to summarize as much as possible and use bullet points instead of prose. I’m happy to expand on any particular topics and we’re open to feedback on this revised proposal.

Recap of the previous proposal

We initially proposed a two-phase sequencer-prover coordination model:

Phase 1: Proof Claim

• Provers pre-register by posting a large bond in a hypothetical ERC20 token.
• Only bonded provers can submit proofs.
• At the end of epoch N, bonded provers privately submit bids (quotes) to sequencers in epoch N+1, including a proposed fee (as a % of epoch N’s total fees + inflation).
• The first sequencer in epoch N+1 can accept a bid and register it on-chain. This locks the prover into producing a proof, or they risk losing their bond. If the first sequencer does not finalize a proving quote during their L2 slot, the next sequencer may finalize a proving quote in their L2 slot and so on.
• If no bid is accepted during the first 13 L2 slots of epoch N+1, all blocks from epoch N and the first 13 blocks of N+1 are pruned and the chain restarts from the tip of the proven chain.

Phase 2: Proof Submission

• The chosen prover has until the end of epoch N+1 to submit a proof for epoch N.
• If they succeed, they earn their quoted reward. If not, they forfeit their bond.

Why It Didn’t Work

Misaligned Incentives

• Sequencers in epoch N+1 negotiate proofs for epoch N, but they don’t benefit from epoch N fees or inflation.
• This opens the door for collusion: sequencers can accept high-fee bids and receive off-chain kickbacks without any cost to themselves.

High Barrier to Entry

• The required proving bond was projected to be very high to mitigate the cost of potential reorgs.
• Even well-capitalized operators flagged this as a major blocker to participating in proving.

Poor Bridging UX

• Users had to wait until the entire epoch was proven to bridge assets.
• A transaction submitted early in epoch N might wait until the end of epoch N+1 for finality, due to lack of support for fast or proofs of partial epochs.

The New Proving Design

The prover coordination proposal was overhauled with simplicity, permissionlessness, and user experience in mind.

No Coordination with Sequencers

• No pre-registration. No bonds.
• Anyone can submit proofs permissionlessly to the rollup contract.
• The rollup accepts multiple proofs per epoch, from different provers.
• Rewards are equally split amongst provers who submit valid proofs in time (with some caveats below).

Proving Rewards Are Governance-Defined

• Sequencers vote (via governance) to:
  • Set a fixed % of block inflation allocated to provers.
  • Set a proving fee per mana (L2 gas unit) paid by each transaction.
• This lets sequencers signal demand for proving resources while retaining control over protocol costs.

No Bonds, No Monopoly

• Since there’s no exclusive proof assignment, there’s no need for a large bond.
• This model relies on the assumption that rewards are sufficient to attract at least one honest prover.

Partial Epoch Proving = Better UX

• The rollup now accepts partial epoch proofs.
• Provers can submit proofs for any number of contiguous blocks from the current chain tip.
• This allows faster finality and enables immediate bridging—no need to wait for epoch boundaries.

Example: A market maker makes a bridging transaction at block k+2. They can submit a proof for blocks k+1 to k+2 without waiting for the rest of the epoch to be built or proven, immediately finalizing their transaction.

Superseded Proofs Are Disqualified

• If Alice proves blocks k+1 and k+2, but Bob later submits a proof for k+1 through k+5, only Bob gets the reward.
• Only the longest valid proof submitted for a given epoch is eligible for proving rewards.

Reward Function Encourages Consistency

• Because the proving system is permissionless, individual provers can’t know their reward share in advance.
• To mitigate this uncertainty, we propose an exponentially rising reward function based on consistency.
• Provers who continuously submit proofs over multiple epochs receive a larger share of rewards.

Feedback Welcome

We believe this design better aligns incentives, reduces barriers to entry, and drastically improves UX for bridging and proving. Please share your thoughts, feedback, and concerns.

[jimwavefive]

Thanks Amin, a new set of games to think about!

The game that comes to my mind as the easiest to break into for conversation purposes is the reward streak.

What sort of timeframe are we thinking about for the exponential function? I suppose we want a balance between attracting new provers to participate, despite lower earning potential compared to incumbents while their streak ramps up and rewarding incumbents for consistency. Is this something that should be decided via governance?

The change around the rollup accepting multiple proofs per epoch - does this introduce MEV games? Or maybe intensify games that already existed? Can proof submission be sniped?

[Starny]

Your proposal for proving coordination in Aztec is strong, especially with clear sequencer/prover separation and effective staking/slashing mechanisms.

Here are a few suggestions:

1. dynamic fee models

Dynamic fee models and open prover markets are being actively researched and piloted in projects like zkSync and Starknet. zkSync is decentralizing its prover network by allowing multiple independent prover pools to compete, with fees and participation determined by market dynamics, which has already led to lower costs and increased resilience for the network. zkSync has already tested this model, with a 30-40% cost reduction.

Similarly, research on mechanism design for ZK-rollup prover markets lays out how user fees and prover competition can create efficient, incentive-compatible systems where the lowest-cost, most reliable provers are selected through market-based bidding, addressing exactly the efficiency and incentive alignment you suggest.

2. Fallback mechanisms

such as backup pools or alternative provers stepping in if the primary fails—are a standard resilience strategy in distributed systems. Starknet and other rollups discuss protocols where, if a prover fails or is too slow, another can take over to ensure blocks are not delayed ensuring a liveness if 99.9%. This approach has proven effective in maintaining liveness and network reliability.

The Bad:
dynamic fees could make the protocol more complex, or fallbacks could add operational costs.