AZUP-3 is Ready for Proposal

v6 Upgrade (AZUP-3)

The v6 protocol code is complete. v6 is a new rollup: it brings L1-to-L2 messages into L2 in seconds rather than minutes, lets staking providers exit positions they operate, gives governance a protocol fee margin and a pluggable sequencer reward calculator, and prepares the fee model for Ethereum’s Glamsterdam fork. The upgrade payload also keeps v5 sequenced and proven for 30 days after v6 becomes canonical, so users still migrating are not stranded.

AZIPs Bundled in AZUP-3

The upgrade includes 12 governance proposals (AZIPs):

AZIP Title
AZIP-22 Fast Inbox
AZIP-23 Protocol fee margin
AZIP-24 Track first prover attribution for checkpoints
AZIP-25 Activity score for full epoch proofs
AZIP-26 Transaction effects tree in block headers
AZIP-27 Rate-limited exits by staking providers
AZIP-29 Protocol nullifier refinement
AZIP-30 Deploy v6 with a 90% sequencer reward share
AZIP-31 Pluggable sequencer reward calculator
AZIP-33 Raise the GSE proof-of-possession gas cap to 300k
AZIP-34 Sustain the v5 rollup after v6 becomes canonical
AZIP-35 Glamsterdam gas constants

The full package, including every payload action, is in AZUP-3.

Governance and Launch Process

The governance follows the v5 model:

  1. Anyone may deploy the v6 contracts to Ethereum using the provided forge script
  2. Sequencers signal support for the payload
  3. Token holders vote
  4. After the execution delay, the payload is executed and v6 becomes canonical

The payload can only be executed on a UK weekday between 08:00 and 17:00 London time, and only while v5 is still the canonical rollup.

Deployment Instructions

The rollup verifier and protocol constants for v6 are pinned in the repository, and the script deploys that pinned verifier rather than building one.

git clone --depth 1 --branch v6 https://github.com/AztecProtocol/aztec-packages.git
cd aztec-packages
git submodule update --init --recursive --depth 1 -- l1-contracts/lib
cd l1-contracts
export PRIVATE_KEY=0x...
export RPC_URL=https://...
export ETHERSCAN_API_KEY=...
export FOUNDRY_SOLC_VERSION=0.8.30
export REGISTRY_ADDRESS=0x35b22e09Ee0390539439E24f06Da43D83f90e298

# confirm the pinned verifier before anything else
grep -m1 VK_HASH script/deploy/HonkVerifier.sol

# dry run: deploys and simulates against live state, sends nothing
forge script script/deploy/DeployRollupForUpgradeV6.s.sol \
  --sig 'run()' --rpc-url "$RPC_URL" --private-key "$PRIVATE_KEY" -vvv

# deploy
forge script script/deploy/DeployRollupForUpgradeV6.s.sol \
  --sig 'run()' --rpc-url "$RPC_URL" --private-key "$PRIVATE_KEY" \
  --broadcast --verify --slow -vvv

A few notes on the command:

  • The grep must print uint256 constant VK_HASH = 0x1fd4eb1d14be45e05dc78c448eb4f29d7f63e4de95129c4a5e1058cd9837f8a6;. That is the pinned v6 rollup verifier; do not continue if it prints anything else.
  • Run the dry run first. It performs the full deployment and the governance simulation against live mainnet state without sending any transaction. -vvv prints the revert reason if anything fails.
  • Expect ten transactions: six external libraries (deployed via CREATE2, and skipped if they already exist at their deterministic addresses), then the verifier, the Rollup, the EscapeHatch and the payload.

The script deploys the v6 verifier, the v6 Rollup (with its Inbox, Outbox, FeeJuicePortal, Slasher and RewardBooster), the v6 EscapeHatch and the upgrade payload, then simulates the payload’s execution through governance against live state before anything is proposed. Record the addresses it logs, in particular payload, which sequencers signal for. On execution, the payload reserves 1,800,000 AZTEC for v5, lowers v5’s checkpoint reward to 50 AZTEC, installs v6’s escape hatch, registers v6 in the Registry and the GSE, migrates the entry-queue flush incentive, and raises the GSE’s proof-of-possession gas cap to 300,000.

Major Changes

Fast Inbox (AZIP-22): Today an L1-to-L2 message waits for the Inbox tree to seal and then a two-checkpoint lag, taking 24 to 108 seconds to reach L2. v6 streams messages into blocks as soon as nodes see them on L1, bringing that to about 12 to 30 seconds. Every deposit, bridge and portal flow benefits.

Staking Provider Exits (AZIP-27): A staking provider operates the validator, but until now only the delegator’s withdrawer could start an exit, so a provider that wanted to stop had no way out short of being slashed for inactivity. Providers can now exit the positions they operate, while the payout still goes to the delegator. A shared rate limit of 5% of the validator set per 7 days stops exits from being used to swing a governance vote.

Protocol Fee Margin (AZIP-23): Fees are priced at exactly the cost of running the network. v6 adds a governance-set margin on top of cost and a governance-set recipient for it, so usage can start to offset the block rewards funded through supply growth. The margin launches at zero and can only be raised in rate-limited steps by a later proposal.

Pluggable Sequencer Reward Calculator (AZIP-31): Changing how sequencer rewards are computed used to mean deploying a new rollup. Governance can now point the rollup at a separate reward calculator contract, so a future reward policy can ship without a rollup upgrade. A calculator that fails or misbehaves falls back to the default reward and can never block a proof. v6 launches with no calculator set, so every proposer earns the default; any reward policy that uses one needs its own AZIP and AZUP.

Sequencer Reward Share (AZIP-30): The sequencer share of the 500 AZTEC checkpoint reward rises from 70% to 90%, from 350 to 450 AZTEC per checkpoint. Total emissions are unchanged.

Ready for Glamsterdam (AZIP-35): Glamsterdam makes the L1 transactions behind checkpoint proposals and epoch proofs materially more expensive. v6 raises the fee model’s L1 gas constants now (300,000 to 500,000 per checkpoint, 3,600,000 to 4,000,000 per epoch proof), so fees cover sequencer and prover L1 costs from the moment the fork activates.

Keeping v5 Alive During Migration (AZIP-34): Once v6 is canonical, v5 can no longer draw rewards from the RewardDistributor. The payload earmarks 1,800,000 AZTEC for v5 and lowers its checkpoint reward to 50 AZTEC, which at 1,200 checkpoints a day keeps v5 sequenced and proven for 30 days.

Validator Key Registration (AZIP-33): The GSE checks each new validator’s BLS key within a 250,000 gas cap. Osaka made that check more expensive, so about 1 in 28,559 honestly generated keys is now rejected at registration. The payload raises the cap to 300,000, bringing that back to about 1 in 2.5 million.

Prover Changes (AZIP-24, AZIP-25)

  • The rollup records which prover first proved each checkpoint
  • A prover’s activity score only increases on a full-epoch proof

Protocol Changes (AZIP-26, AZIP-29)

  • Each block header commits to a tree of its transactions’ effects, so contracts can prove transaction effects against a header
  • The protocol nullifier is derived from the transaction’s origin, chain id, version and salt only, so a fee bump or cancellation shares it

What This Means For You

Sequencers: Run v6 software. Stake that follows the latest rollup moves to v6 at execution, with first v6 duties two to three epochs later. The default sequencer reward rises to 450 AZTEC per checkpoint. Sequencers whose stake stays on v5 earn 35 AZTEC per checkpoint there from the earmark until it runs out.

Provers: The block-reward prover pool falls from 150 to 50 AZTEC per checkpoint; fee-based prover revenue is unchanged. Activity scores only increase on full-epoch proofs. v5 provers earn 15 AZTEC per checkpoint from the earmark for about 30 days.

Token holders: Emissions are unchanged at 500 AZTEC per checkpoint, with more of it going to sequencers. Governance gains a fee margin and a sequencer reward calculator, both to be set in later proposals.

App developers and infrastructure providers: v6 is a new rollup, so contracts must be recompiled, and class ids and addresses change. L1-to-L2 messages arrive in seconds. L2 fees rise slightly with the Glamsterdam gas constants.

The v6 code, including the deploy script and the upgrade payload, is available on the v6 branch.

Disclaimer

This message is provided for informational and technical discussion purposes only. It does not constitute a recommendation, solicitation, or request to signal support for, vote on, approve, reject, or otherwise take any action with respect to any governance proposal. It expresses no view on how any token holder, sequencer, or participant should act or vote. Any governance action described can only occur through independent, decentralized Aztec Governance processes and at the discretion of token holders.

1 Like

gm Proposal: V6 Payload

1 Like