A look into the pieces that comprise a private zkRollup
Aztec Network is a privacy-first zkRollup on Ethereum. Most people who are fans of Aztec understand the public nature of Ethereum and how Aztec serves to solve Ethereum’s drawbacks: privacy and scalability.
In this piece we want to underscore the elements of Aztec’s network architecture and offer a sense for how the different pieces work together to enable a privacy layer for Ethereum DeFi, DAOs, and NFTs.
It complements our more basic piece about how Aztec’s UTXO-based privacy architecture works, which can be found here.
As a guide to the anatomy of a transaction traversing Aztec’s network, we’ve supplied a handy dandy diagram:
User Transactions
It all starts with the most important element in the whole flow — a user making a private transaction.
Typically the user interacts with a front-end (either the first-party maintained zk.money or an Ethereum app which has integrated the Aztec Connect SDK).
User accounts are accessed and managed by the Aztec Connect SDK, and like Ethereum are comprised of public and private keys. Unlike Ethereum, however, Aztec accounts have a single public key but two types of private key: viewing keys and a spending keys.
The viewing key allows the holder to view a user’s owned encrypted notes think of this like a pair of decoder glasses that allows the holder to see a user’s note balances, but no one else’s:
The spending key on the other hand is like a key that allows the holder to unlock individual encrypted notes and spend them — either in a send, withdraw, or DeFi transaction.
You can register different spending keys to different devices, preventing the need to paste sensitive information across devices.
The Aztec SDK
The Aztec SDK manages all this through an easy-to-use API that allows developers to integrate account registration, recovery, and asset transfer functionality in a few lines.
The SDK retrieves encrypted state and presents it to the developer in a way that’s easy to serve to users, all while managing private information such that applications never have access.
When users grant applications access to their account, the SDK helps users spend funds, computing state updates with a proof of correctness. It manage state (what users own) and facilitates user transactions (updating state by constructing proofs).
In comparison, an Ethereum transaction is a request for a state update along with authorization from a private key (a signature). In Aztec, the SDK is itself computing the state update, and then sending the proof of correctness to an Aztec sequencer.
The sequencer is therefore not doing any real computation or state update but just offering a compression service — aggregating user proofs (“inner proofs”) into a larger single outer proof.
It’s worth noting also that the sequencer cannot reasonably discriminate between transactions, since all it receives is an encrypted proof of correctness for an underlying transaction, which is generated client-side in the user’s browser. This makes targeted censorship of specific transactions essentially impossible.
Learn more about building with Aztec with our SDK documentation
Falafel: the Aztec Client
Once the transaction is created, it’s sent to Falafel. Falafel is a Typescript implementation of Aztec’s client — think of it like Go Ethereum (geth) or any other Ethereum client that forms an interface between the user and the actual blockchain.
Falafel is offchain software that accepts user proofs (encrypted transactions), aggregates them, creates a rollup proof, and then sends rollup proofs to the rollup contract for validation. This large proof comprised of many user transactions is what we call an “outer proof” (the inner proofs being the proofs containing each individual user transaction).
Falafel is just a batching mechanism that creates a big mega proof that adds all the inner proofs together proving that all the underlying state updates are valid.
Some note on privacy and censorship resistance in the network’s end state: the only reasonable censorship a sequencer can undertake is refusal to process blocks and attempting to interrupt network liveness.
If we analogize sequencers who run Falafel as mailmen, the only thing they can do is quit delivering the mail, but they can’t open specific letters and envelopes, nor can they reject letters in a targeted way because there is no revealing information.
Anyone can run the Falafel client and become a sequencer. The Aztec sequencer proposes blocks — sets of encrypted transactions.
Our goal is to have a network of sequencers run Falafel, processing and batching transactions for publication. Currently, though, Aztec serves as the sole network sequencer.
Rollup Contract
Once the outer proof is constructed, it’s sent to the on-chain rollup contract, a smart contract published on Ethereum (you can find it at this address).
The outer proof sent to the rollup contract can contain a variety of encrypted user actions: withdrawals, deposits, new account registrations, or Aztec Connect bridge transactions.
The outer proof is sent to the rollup contract for validation and state updates. The rollup contract then runs through each user transaction and executes the necessary logic on Ethereum Layer 1.
Deposit: Users move funds to the Aztec rollup contract, which locks funds and then credits the user with an L2 representation of those funds once the rollup is published to Ethereum.
Withdrawal: Users indicate they want to send funds out of Aztec, the rollup contract confirms the value of the singular note the user is spending, nullifies internal Aztec funds, and sends its L1 funds to the specified withdrawal address.
DeFi interaction: the rollup contract calls out to an Aztec Connect Bridge Contract, which serves as an interface to Layer 1 smart contracts.
Bridge contracts are all fundamentally structured as two-input, two-output swaps: the rollup contract sends 1–2 assets into an L1 protocol, and atomically receives 1–2 assets back (a synchronous bridge like a swap) or returns token assets back at a later date (an asynchronous bridge like a timed vault). In the next block, it subsequently generates a claim note for the user to claim the returned asset at a later date.
You can think of this structure like inputting A + B and getting C + D back, either now or later:
Virtual assets are an Aztec-specific representation of token positions that can’t immediately be returned to the rollup — think vault positions, fixed term positions, or anything else that is escrowed for redemption at a later date.
In all cases, smart contract logic stays on Layer 1. Users are interacting with Layer 1 liquidity and smart contracts — with no liquidity fragmentation or logic execution “on Aztec” whatsoever!
Aztec Connect serves as a privacy-and-batching layer for the battle-tested contracts and liquidity on Ethereum.
Subsidy Contract
We recently made an upgrade to Aztec that allows any party to fund subsidies for bridge transactions. Subsidies are an important part of bootstrapping bridges on Aztec while user volume gets to critical mass.
Take for an example a bridge that supports 50-unit transaction batches. Think of this like a bus with 50 seats, which only departs for its destination once the bus is full.
On any given day, three things could happen:
- All 50 “seats” get filled — yay!
- Not all 50 seats get filled, and people wait for a whiiiile before the rest of the seats get filled
- Someone at some point gets sick of waiting and pays for the whole batch to go down to Ethereum and execute
The “someone” in scenario 3 could be an individual electing to pay for the number of seats remaining, OR it could be the bus service itself. Protocols who want the bridge to be performant even before bus seats are selling out can subsidize regular departures, ensuring timely performance.
Previously, Aztec offered these subsidies to our partners by managing a subsidy balance within Falafel, Aztec Network’s client. We would use the multisig to manually top up Falafel’s subsidy balance on a bridge-contract to bridge-contract basis.
Now, a contract has been deployed that allows any EOA or contract account to subsidize bridge contracts under a certain set of parameters:
- Bridge ID
- Subsidy amount committed
- Bridge contract backstop (how often to subsidize running of the bridge, e.g. “6 hour backstop” means if the bridge reaches 6 hours without inclusion in a block, it automatically calls the subsidy contract for funds and inclusion in the next block)
When the subsidy amount runs out based on the given parameters, the subsidy contract simply stops returning a subsidy.
Previously, subsidy funding happened completely offchain (partner sends funds to our multisig, we then send it from the multisig to Falafel). Partners would have to trust us to use the funds wisely, do the appropriate accounting within Falafel, and hold the funds. It also required interaction with the Aztec Core Team.
Now, the subsidy contract allows anyone to permissionlessly fund bridge contracts, regardless of author or origin. The network owns the subsidy, and any sequencer running Falafel can claim it. It’s a step toward Aztec Network’s decentralization plan, making each part of the network stand on its own from the Aztec Core Team.
Conclusion
With Aztec, privacy is a feature you can now add to any Ethereum contract — and now you know exactly how it works!
We’re excited to see developers and users explore the full potential of Aztec’s privacy architecture.
If you’re a developer, check out the following resources:
And jump into our Discord for questions on how Aztec works!
Explaining the “Network” in Aztec Network was originally published in Aztec on Medium, where people are continuing the conversation by highlighting and responding to this story.
