Alpha Upgrade is Ready for Proposal

Governance
1

Introduction

We at Aztec Labs are thrilled to announce that we believe the code for Alpha network, enabling transactions on Aztec, is ready.

This post:

  1. Describes Alpha, and outlines a plan the community and Aztec Governance can follow to launch the Alpha network: the first private, programmable, Stage 2 validity rollup on Ethereum.

  2. Covers the major changes that we at Aztec Labs have delivered since the Ignition network launched and will be incorporated in this version of the network.

What is Alpha?

Aztec is the leading privacy-first Layer 2 on Ethereum, empowering developers to build applications that protect user privacy.

“Alpha” is the name given to the first version of Aztec that includes an execution environment to enable private transactions. The proposed rollup will enable developers to deploy composable private smart contracts if implemented by the decentralized network.

Why “Alpha”? ”Alpha software” generally refers to the earliest functional version of a program, often incomplete, unstable, or buggy, serving to validate concepts before advancing to a more stable beta phase.

We expect there to be multiple versions of Aztec during the Alpha phase. Each version will have its own state, similar to the different versions of Zcash, or Uniswap v3, v4, etc. Internally at Aztec Labs, we refer to the version of Alpha being proposed in this post as v4. This versioning allows a turnstile mechanism, popularized by Zcash, preventing fraudulent state from moving across versions while the prior versions continue to exist and be usable.

Each version of the Aztec network is a set of immutable, non-upgradable smart contracts. Governance only has the ability to modify fee market parameters and select a canonical instance of the Aztec network. This is a deliberate and necessary design choice that denies Governance the ability to e.g. steal funds, disable contracts that had been deployed, or otherwise arbitrarily update the state in the network. In the event that a bug has been exploited to, e.g. create counterfeit funds in private, immutability confines bad (and good) state on the network it originated in.

Significant work has gone into the security and audit readiness of the network with continuous internal and external audits on the code base (described below, reports here). However, we still view the v4 Alpha network as experimental technology, and we recommend users only transact with funds that they are willing to lose. We will publish a post prior to v4’s launch dedicated to how Labs plans to respond in the event of vulnerabilities being found, and our ongoing security efforts to support the v5 release (which should be ready in June).

What Alpha is and How to launch it

It is important to recognize that neither Aztec Labs nor any single entity can unilaterally launch the Alpha network.

The launch of the first (and every subsequent) Alpha Network will follow the standard governance process, which is thoroughly documented here, but can be summarized as:

  1. Anyone may deploy a new set of rollup contracts to Ethereum

  2. Anyone may deploy a payload in the format expected by Governance, proposing that the new rollup contracts be adopted as the new “canonical” rollup contracts

  3. Sequencers signal their support for this payload

  4. All token holders vote to adopt the new rollup contracts

  5. After a delay, anyone may execute the payload

Aztec Labs has written a script to perform steps 1 and 2, which can be found here.

In it, you will notice some additional steps and config changes relative to the Ignition Chain, including:

  • Increasing the mana target from 0 to 75M to allow an average of ~1.25 TPS (R&D plus user/operator/builder feedback will be ongoing to steadily, safely increase this)

  • Increase rewards by 25%: the checkpoint rewards (renamed from “block rewards”, see “Checkpoint Architecture” below) from 400 to 500 AZTEC to adequately compensate sequencers and provers for the additional load coming from processing transactions

  • TargetCommitteeSize increased from 24 to 48 to provide greater security for transactions before they are proven

  • Moving funds from the “flush rewarder” (a permissionless mechanism to reward people for emptying the staking queue) on the old rollup to the new rollup

  • Updating the execution delay of subsequent governance proposals from 7 to 30 days to achieve Stage 2 (see below)

Stage 2 Rationale

The changes above are required to deploy a new version of the Aztec network with transactions enabled and achieve Stage 2 Decentralization. Stage 2 is so rarely attained because it implies that in general, users can have the same confidence in their ability to use Aztec as they would Ethereum with respect to censorship risk and the inability for governance to jeopardize their funds; quoting L2Beat, “Stage 2 represents a project that is fully controlled by code”.

We strongly believe that starting Alpha at this level of commitment and assurance to users will pay dividends in the years to come.

Deploying the rollup and payload

git clone -b v4 <https://github.com/AztecProtocol/aztec-packages.git>
cd l1-contracts

# depending on your environment,
# ./bootstrap.sh may not complete successfully
# but for the purposes below it only needs install solc
./bootstrap.sh

export L1_RPC_URL=<your_rpc_url>
export ROLLUP_DEPLOYMENT_PRIVATE_KEY=<your_ethereum_private_key>
export DEPLOYER=<address_corresponding_to_private_key>
export ETHERSCAN_API_KEY=<your_etherscan_api_key_for_contract_verification>

# if you already have the repository checked out, 
# make sure you have checked out the v4 branch
./scripts/run_alpha_upgrade.sh

That will print out the relevant addresses of the newly created rollup, and the payload which will make it the new canonical rollup recognized by Aztec Governance. Once you have them, you can include the addresses in a forum post similar to these:

To be clear, Aztec Labs is not going to deploy the rollup contracts or submit the payload ourselves, and we encourage anyone in the community to do so if they feel comfortable. We will of course be available to provide support and answer questions about the process, and will validate the correctness of proposals made to the forum that claim to have run the script above.

Major Changes Since Ignition

Security Audit Hardening

The single biggest area of work was a comprehensive security audit pass across both the AVM (Aztec Virtual Machine) and the Barretenberg proving backend.

AVM pre-audit: Dozens of PIL constraint fixes addressing memory injection vulnerabilities, ghost row attacks, missing boolean constraints, unconstrained reads, and various soundness bugs across nearly every PIL file — context, execution, registers, gas, addressing, calldata, SHA256, keccak, poseidon2, ECC, bitwise, and more. The AVM circuit is substantially more hardened than in v2.

Barretenberg audit: Dedicated internal review of proving system and all core barretenberg circuit components. External audit of circuit primitives (field, group, bool, etc.), Goblin ECCVM, Ultra/Mega circuit builders, ACIR/DSL translation layer, and more.

Circuit-level fixes: Global uniqueness of side effect counters is now enforced, public inputs are asserted clean on the tail circuit, and the min revertible side effect counter is validated within range.

AVM: C++ Simulator and Goblin Recursive Verifier

The AVM underwent a major architectural shift:

  • Migrated to a C++ simulator — the TypeScript AVM simulator was replaced with a native C++ implementation accessed via NAPI bindings, with the option to use the TS logger from C++.

  • Goblin AVM recursive verifier — the AVM proof is now verified recursively using the Goblin IVC scheme, with the AVM VK added to the VK tree and fixed in the recursive verifier.

  • PublicTxEffect — public execution now returns a structured PublicTxEffect rather than ad-hoc results.

  • Siloed nullifier exists — the AVM now handles siloed nullifier existence checks natively.

  • Smaller and faster traces — the precomputed trace was reduced in size, bitwise traces horizontalized, register count reduced from 7 to 6, and batch inverses applied for faster tracegen. Sumcheck got 20% faster.

AVM Fuzzer

A full transaction-level fuzzer was built from scratch:

  • Bytecode mutation, contract instance/class/protocol mutations, gas mutations, enqueued call mutations, accumulated data mutations

  • External call and internal call “gadget” fuzzers, calldata fuzzer, ECC scalar mul fuzzer

  • Proving runs during fuzzing — bugs found by the fuzzer are actually proven, not just simulated

  • Coverage tracking and artifact archiving

  • Docker container for continuous fuzzing

The Great Wallet Refactor

The wallet and SDK surface area went through a complete overhaul:

  • New note emission API — cleaner, context-free NoteEmission methods. Private event emission is now split from delivery, and recipient was removed from the delivery path.

  • Enshrined note ownership — owner is now enshrined in notes and state variables. Randomness removed from built-in note types and enshrined at the protocol level. RetrievedNote now contains the storage slot.

  • New state variable traits — Owned trait, SinglePrivateMutable, PublicImmutable with is_initialized made public.

  • Wallet capabilities and scopes — wallets can declare capabilities, pass scopes to PXE, and support optional additional scopes.

  • wallets package — wallet implementations extracted into their own package.

  • Full batchability — wallet transactions are now fully batchable.

  • Entrypoint and fee payment simplification — less boilerplate for account contracts.

  • Alternative accounts — support for alternative account implementations.

L1 Escape Hatch

The escape hatch is a periodic, alternative block production path on L1 that allows a single bonded proposer to bypass the sequencer committee, ensuring users can force transactions through even under 100% committee censorship. It is the critical mechanism that moves Aztec from Stage 0 to Stage 1 rollup maturity by anchoring liveness guarantees to Ethereum rather than the Aztec sequencer set. When not in use, it has near-zero impact on normal block production costs and throughput.

  • How it works: Every 112 epochs, a window of 2 epochs opens where a randomly selected designated proposer (drawn from a bonded candidate set) can produce blocks without committee attestations.

  • Candidate entry: Any entity can join by depositing 332M AZTEC; no sequencer registration required.

  • Anti-abuse: Failed or malicious hatches (no blocks proposed, unprovable blocks, pruned chains) result in slashing up to 9.6M AZTEC. All exits incur a 1.66M AZTEC to make griefing costly.

  • Tradeoff: During an active hatch the designated proposer has a monopoly on block production (MEV risk), and the escape hatch bypasses the committee safety net against circuit soundness bugs.

Checkpoint Architecture

The L1 settlement model changed to significantly improve user experience and perceived latency of transaction inclusion. “Multiple blocks per slot” allows sequencers to build an arbitrary number of blocks when it is their slot to propose, with transactions being able to build off the state in the preceding blocks as normal. We currently recommend nodes target ~6 second blocks, reserving the second half of their slot for publishing to L1. (Sneak peak: we will shortly release our design for “pipelining”, which should be ready by the next network upgrade, and allows ~4 second blocks with no need to reserve time for publishing)

  • Multiple L2 blocks per slot — rather than a 1:1 mapping, sequencers now publish “checkpoints” in their slot which batch multiple L2 blocks.

  • Checkpoint circuits — new circuit types for checkpoint proving, with max 32 checkpoints per epoch.

  • Out hashes aggregated per epoch — out hashes are now set on L1 per epoch rather than per block.

  • Out hash root validated on L1 — set in checkpoint header and validated during L1 processing.

  • Escape hatch — nodes are aware of the escape hatch, slashing is disabled during escape hatch periods, and the sentinel is suspended.

  • Blocks in a checkpoint enforced to have the same timestamp.

Gas Model Changes

  • Gas compensates for long term storage of state

  • Opcode gas multipliers added to account for slow simulation opcodes

  • Tx overhead and private emission L2 gas now based on simulation time

  • Max private log size changed to 16 fields

Protocol Naming Cleanup

A sweeping rename pass for consistency:

  • protocol_types → protocol

  • “unencrypted logs” → public logs

  • “historical block” → anchor block

  • “block” → checkpoint on L1 (which contains multiple “block”s)

  • Router contract renamed

  • #[internal] renamed to #[only_self]

  • New #[external(...)] macro introduced

  • ContractSelf introduced

New aztec CLI + Dockerless Installation

  • Unified aztec CLI command replacing fragmented tooling

  • aztec-up installs without Docker — native binary installation support

  • aztec-up can manage multiple Aztec versions

  • aztec profile command with gate count profiling and flamegraph generation

  • Contract debug logs printed in tx output

  • CLI reference docs auto-generated at release

PXE Restructuring

  • JobCoordinator introduced for managing PXE work

  • getNotes moved to debug submodule

  • Intermediate PXE modules removed

  • Aztec Node proxy methods removed from PXE

  • PXE JSON RPC dropped

  • IndexedDB store cleared on data schema version change — cleaner upgrade path

  • New log sync algorithm — reorg-resistant, with pagination, concurrent nullifier and tag searching

Network Layer

The P2P and sequencing layer got substantial hardening:

Big shoutout to Nethermind for their work here!

  • TxPoolV2 — new transaction pool with slot-based soft deletion, fee prioritization, minimum tx pool age for block building, and nullifier deduplication.

  • Peer scoring — misbehaving peers are now scored and penalized.

  • Fast tx request/response — new protocol for efficient tx propagation, with dynamic peer set adjustment and batch tx requesting.

  • Attestation trimming — attestations trimmed to minimum required length.

  • Calldata validation — calldata checked against emitted hashes.

  • Tx file store — transactions persisted to file store as fallback, with configurable uploaders.

  • Proof store — proofs stored and retrieved for HA setups.

  • Error codes for RPC calls — structured error codes for common failure modes.

  • API key authentication for admin RPC endpoint.

High Availability Nodes

  • ValidatorKeystore with web3signer integration and retry logic

  • Worker thread wallet for non-blocking signing

  • reloadKeystore admin RPC endpoint for hot-reloading keys

  • World state history length defined in checkpoints

  • Automatic stop from governance signalling when node falls behind

Slashing

  • Duplicate attestation slashing — equivocation on attestations is now slashable

  • Duplicate proposal slashing — equivocation on proposals is now slashable

  • Slashing disabled during escape hatch

Barretenberg Improvements

Beyond audit work:

  • Backend fully ported to HyperNova-style Sumcheck-based client side prover

  • Improvements to client side memory consumption (many useful transactions <500mb)

  • barretenberg-rs — new Rust crate with FFI backend, iOS/Android cross-compilation, JSON input/output for bb verify, and crate publishing infrastructure

  • Cloudflare R2 as primary CRS host with S3 fallback

  • WASM builds now have asserts enabled

Private-Public Storage Proofs

Demonstration of efficient Ethereum storage proofs by leveraging both private and public execution, allowing proving arbitrary Ethereum state within Aztec. Combined with the aztec::history module improvements, this opens up new patterns for hybrid private/public L1-L2 interoperability.

Fee Asset Price Oracle

On-chain oracle for fee token pricing, with configurable priority fee calculation strategies. The StakingAssetHandler was refactored to work as a normal faucet.

Documentation

Major docs overhaul covering node operation, note delivery, delegation flows, recursive verification tutorials, TypeScript API docs (including LLM-friendly generation), contract readiness states, and network information pages. See the main documentation at https://docs.aztec.network/ , and a detailed API documentation covering aztec.nr, the smart contract framework, at https://docs.aztec.network/aztec-nr-api/devnet/noir_aztec/.

Closing

The timeline we have in our mind is:

  • Day 1-3: A community member deploys the rollup and payload, and posts on the forum

  • Day 4: We reply on that community member’s forum post, confirming the payload has been deployed without error and reminding sequencers how they can signal for the payload

  • Day 7: The payload passes sequencer signaling, and is forwarded to Governance

  • Day 10: The voting period starts

  • Day 17: The 7 day execution delay begins (assuming it received enough support)

    • We post clear, simple instructions for sequencers on how to prep for and perform the upgrade to their nodes

  • Day 24: The payload executes, and Alpha begins

Note that this timeline may shift.

Last, thanks to everyone at Aztec Labs, the Aztec Foundation, the other core contributors Wonderland and Nethermind, our auditors, node operators, builders, and the wider community for their support and contributions to get us to this point. We are excited for the next chapter of Aztec, and we look forward to building it together with all of you.

Cheers!

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.

13 Likes
Proposal: Aztec Alpha Payload
2

One of our engineers found a vulnerability shortly after this forum post was published. The vulnerability would have required control of the validator re-execution committee to exploit, but we feel it was important enough to warrant patching right away. This has been patched in the v4 branch and the above script will use the patch when a payload is deployed.

We will manually verify this on request once a community member deploys the payload.

4 Likes
3

Congratz with this milestone, one question tho. at what congestion level does the burn actually outpace the new circulating supply?

4

→

4 Likes