Aztec: The Scalable Privacy Layer for Ethereum

August 9th, 2022

Blockchains are transparent by default, and as a result, lack privacy.

When a transaction occurs on the blockchain, the involved address’ wallet balance, tokens, NFTs and interactions with other addresses, contracts and the exact amounts they have ever transacted with are open for anyone to see, and despite the pseudo-anonymity of public addresses, they can, with some level of probabilistic certainty, be linked back to the identities of their individual owners. If the rate of adoption for blockchains is to maintain its current trajectory, it is hard to imagine this level of complete transparency would continue at scale.

Complete privacy in itself is limited by regulatory and compliance issues, which is why opt-in privacy layers will play an important role in the landscape of infrastructural privacy and a protocol that progresses towards this is Aztec.

Aztec Network

This is what a smart contract interaction on Ethereum looks like. Every transaction executed and the exact values of those transactions are visible on the block explorer

Aztec Network introduces a privacy layer to this. Founded by Zac Williamson, Joe Andrews and Thomas Pocock, Aztec Network is a ZK-rollup on Ethereum built with privacy preserving architecture that provide both users and decentralized applications access to privacy through private transactions enabled with zero-knowledge proofs

Privacy Architecture

Aztec enables access to privacy through a zero-knowledge proving system called PLONK

PLONK stands for Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge

PLONK essentially arranges a set of polynomials based on the lowest degree of correlation that those polynomials have with one another, using a more universal and updateable trusted setup that can be used for more than one cryptographic program at a time and allows for a larger number of participants compared to previous iterations of trusted setups

A more in-depth guide on PLONK, it’s benefits and technicalities on how it works can be read here:

Transactions in Aztec are private due to the encryption of the value of those transactions using PLONK. That encrypted value is named an “Aztec note” or just “note” for simplicity’s sake. Notes are comprised of a set of elliptic curve commitments and three variables; a message, viewing key and spending key

Elliptic curve commitments are essentially cryptographic algorithms that allows a prover to commit to a specific value without being able to reveal or change the value after committing.
A message refers to an Aztec note i.e. the transactional value that was encrypted by Aztec
A viewing key is able to decrypt a note. Whoever has the viewing key is able to view and read the decrypted value of the note and has the ability to create a join-split ZK-proof, which are ZK-proofs that verify join-split transactions
Whoever has the spending key is able to sign the join-split ZK proof

A join-split transaction is essentially the destruction of note(s) and the subsequent creation of different valued notes that add up to the value of the original note(s), and join-split ZK-proofs verify that double spends did not occur without revealing the value of those individual notes

An easy way to understand join-split transactions is to view it as the formula:

( A + B ) = ( C + D )

If note A is 50 and note B is 50, then ( A + B ) is 100. In a join-split transaction, notes A and B are destroyed and new notes C and D are created. There is no limit to how many new notes and permutations can be created as long as they add up to the original ( A + B ), which was 100.

All notes that have ever been created and destroyed are kept in two separate Merkle Trees; a note tree and a nullifier tree.

A Merkle tree is a data structure that can help prove the integrity of a dataset while significantly reducing the memory requirements needed to do so via one-way hash functions that merge layers of data into a singular Merkle root capable of validating all the data contained in the associated Merkle tree.

The note tree contains all notes that have ever been created while the nullifier tree contains all notes that have ever been destroyed

“Destroyed” in itself is a strong word as “destroying” a note just means adding a corresponding nullifier into the nullifier tree. Verifying that you have ownership over a note means checking if that particular note exists in the note tree and does not have a corresponding nullifier in the nullifier tree

When a set of notes go through a join-split transaction, nullifiers for those old notes are added into the nullifier tree while the newly created notes are recorded in the note tree and the nullifier tree is cross-checked to make sure that those new notes don’t have corresponding nullifiers

Let’s recap with an applicable example. Imagine Nancy currently has two $50 notes and wants to send $20 to Paul. Nancy will create one (or more) note(s) that add up to $20 to be given to Paul and one (or more) note(s) that add up to $80 to keep for herself. Nancy will then create a ZK-proof that verifies that the ownership of the set of note(s) that sums up to $20 belongs to Paul, while the ownership of the other set of notes that sums up to $80 belongs to her. Subsequently, the smart contract will verify this ZK-proof, and once verified, will “destroy” or add nullifiers of Nancy’s old set of two $50 notes to the nullifier tree in the registry, and create or add all the new set of notes (both her and Paul’s) to the note tree.

Scalability

Aztec’s proving system has been upgraded and is now called UltraPlonk, which is PLONK boosted with Plookup gates. With this upgrade, here’s how Aztec’s scaling infrastructure works:

A proof is generated client-side in-browser
28 client proofs are then aggregated into one inner rollup proof
32 inner rollup proofs are then aggregated into one outer rollup proof
The outer rollup is then verified into a root rollup circuit, which is another larger circuit that establishes the validity of the underlying mechanisms that ensures execution
The root rollup circuit is then posted onto Ethereum L1

The illustration above is a post-upgrade outer rollup proof, consisting of 32 inner rollups processing 28 client proofs. Before the latest upgrade, an outer rollup consisted of only 4 inner rollups.

Pre-upgrade, it was 28 client proofs multiplied by 4 inner rollups, which resulted in 112 TPR (Transactions per Rollup). Post-upgrade, it's now 28 client proofs multiplied by 32 inner rollups, which results in 896 TPR.

Not only did TPR increase by 8x, the cost of posting a proof onto Ethereum L1 also decreased to 550,000 gas, approximately a 30% reduction compared to pre-upgrade (source: Aztec docs)

With these improvements, here’s how much each user pays for rollup costs per transaction, before and after the upgrade:

However, in their most recent community AMA, the team clarified that in practice, throughput currently hovers around 200 TPR. Despite still being a 2x upgrade over previous systems, it’s far from the supposed 896 TPR. The reason for this is due to Ethereum L1 not being able to process the full size of Aztec’s root rollup circuit. The team did clarify that this will be addressed with their proving system’s next upgrade, which will also supposedly reduce the cost of posting a proof onto Ethereum L1 by about 67% to 180,000 gas.

Aztec: Connect

When a user bridges from Layer 1 (Ethereum) into Layer 2 (Arbitrum, Optimism, etc.), they are only able to interact with protocols that have deployed on the execution environment they are in

i.e. Bridge to Arbitrum, users can only interact with protocols that have deployed on Arbitrum. Bridge to Optimism, users can only interact with protocols that have deployed on Optimism, and so on and so forth for other Layer 2s.

This creates 2 problems; Composability and Fractured Liquidity

Composability - A rollup user planning to execute transactions with multiple protocols won’t be able to do so if just one of those protocols isn’t deployed on that rollup. Example, if an Arbitrum user wants to swap on 1inch, lend on AAVE and yield farm on Yearn but AAVE isn’t deployed on Arbitrum, then the user wouldn’t be able to do the actions that they originally wanted to like they can on Ethereum L1
Fractured Liquidity - Assuming rollup adoption continues to increase, so will the amount of liquidity dispersed from L1 into those rollups, and with even more rollups launching with their own incentive structures, the already dispersed liquidity could become even more divided among the various rollups

Lastly, transactions are still completely transparent

Aztec Connect intends to address these problems by being a composable private bridge that connects Aztec’s rollup with Ethereum DeFi protocols, enabling users inside Aztec to interact directly with Ethereum L1 protocols with higher levels of privacy, without requiring those protocols to deploy on a new environment.

All transactions within Aztec are private and parties outside of Aztec are unable to view internal activities. When an Aztec user wants to transact with a protocol, their transaction will go through Aztec Connect and is combined with other Aztec users’ transactions using a batching mechanism, which helps with every transaction’s anonymity set and cheaper fees. Once the threshold within a batch is reached, Aztec Connect executes all individual transactions as one large batched transaction against the protocol on Ethereum L1.

Batched transactions with Aztec Connect. source: Etherscan

This addresses the composability problem as Aztec users will have access to all protocols like they would on Ethereum L1, from swapping, lending, borrowing, yield farming to governance voting. Fractured liquidity becomes less of a problem since protocols won’t have to deploy on another execution environment. As for privacy, Aztec Connect acts as a proxy where users can interact with Layer 1 protocols with full anonymity.

In L1 and other rollups, transactions on the block explorer look something like:

[from: 0xUser, to: L1/L2SmartContract]

Transaction on Arbitrum. source: Arbiscan

Using Aztec Connect, transactions on the block explorer look like:

[from: Aztec Connect, to: L1SmartContract]

Transaction on L1 with Aztec Connect. source: Etherscan

Imagine Aztec as a walled city. All an outside observer can see is users entering and leaving Aztec via our bridge. Within the walls of the city, users can exchange assets with fully private transactions. Neither the network nor its participants can see the senders and recipients of transactions, nor their amounts. In addition, once inside the system, users can batch transactions and teleport back to L1 — to swap, stake for yield, lend funds, vote in DAOs, or buy NFTs

Source: Aztec docs

zk.money

zk.money is an application built on top of Aztec that acts as both a shielding protocol and a portal to onboard users from Ethereum L1 into Aztec

Users wanting to interact with DeFi protocols inside Aztec or with Aztec Connect are required to register and deposit via zk.money. To register, users are required to make a unique “alias” with a 20-character, lowercase-only alphanumeric limit that acts as an internal username on top of your public key, making it easier to type and read for when users want to send assets to one another. Note that this alias is only for within Aztec and is not an ENS. After registering an alias, users are required to deposit a minimum of 0.01 ETH + gas fees

ETH deposited into zk.money will be shielded and become zkETH

Although initial registration deposits currently only support ETH, Aztec and zk.money supports both ETH and DAI. When the latter is deposited into Aztec, it becomes zkDAI

They used to support renBTC, although in their most recent community AMA, the team noted that this is no longer the case due to lower demand for the use of renBTC compared to ETH or DAI. As a result, they decided to no longer support renBTC to reduce any possible variables that could limit and endanger their transactions’ privacy sets

As long as users transact within Aztec’s rollup with addresses registered with zk.money, they will transact with zkETH and zkDAI

When zkETH or zkDAI is sent to addresses not registered with zk.money, the unregistered recipient will receive regular ETH or regular DAI on Ethereum L1

In the example above, 0x123 sends zkETH to 0x456 and the latter will receive zkETH since they’ve registered on zk.money

However, if 0x123 sends zkETH to 0xABC, the latter will receive regular ETH on Ethereum L1 since they have not registered on zk.money

Despite how 0x123 sent ETH to 0xABC, there is no evidence on the block explorer that any direct interaction happened between the two addresses other than the fact that both had interacted with the Aztec Connect smart contract at some point in time.

An in-depth guide on how to set up zk.money can be found here:

Currently, DeFi protocols Element Finance and Lido are available to use with Aztec: Connect, the former with zkDAI and the latter through Curve with zkETH. Support for protocols such as AAVE, Compound and Liquity are to arrive soon, and in their most recent community AMA, the Aztec team confirmed that supporting a DEX for Aztec Connect is currently one of their top priorities.

Closing Thoughts

Privacy is under-appreciated. Most won’t care until it’s too late or until they’ve experienced the effects of a lack of privacy themselves.

With the use of UltraPlonk for scalability, Ethereum as a settlement layer for decentralization, a composable private bridge that makes the fractured liquidity argument less of a problem with more and more protocols being integrated and an architectural emphasis on infrastructural privacy, Aztec is shaping up nicely to becoming the scalable, opt-in privacy layer for Ethereum.