#
Inside Aztec
Inside
Aztec
purple_2
How Aztec is Adding Privacy to Apps Across the Ethereum Ecosystem
Every time you swap tokens on Uniswap, deposit into a yield vault, or vote in a DAO, you're broadcasting your moves to the world. Anyone can see what you own, where you trade, how much you invest, and when you move your money.
Tracking and analysis tools like Chainalysis and TRM are already extremely advanced, and will only grow stronger with advances in AI in the coming years. The implications of this are that the ‘pseudo-anonymous’ wallets on Ethereum are quickly becoming linked to real-world identities. This is concerning for protecting your personal privacy, but it’s also a major blocker in bringing institutions on-chain with full compliance for their users.
Until now, your only option was to abandon your favorite apps and move to specialized privacy-focused apps or chains with varying degrees of privacy. You'd lose access to the DeFi ecosystem as you know it now, the liquidity you depend on, and the community you're part of.
What if you could keep using Uniswap, Aave, Yearn, and every other app you love, but with your identity staying private? No switching chains. Just an incognito mode for your existing on-chain life?
If you’ve been following Aztec for a while, you would be right to think about Aztec Connect here, which was hugely popular with $17M TVL and over 100,000 active wallets, but was sunset in 2024 to focus on bringing a general-purpose privacy network to life.
Read on to learn how you’ll be able to import privacy to any L2, using one of the many privacy-focused bridges that are already built.
Aztec is a fully decentralized, privacy-preserving L2 on Ethereum. You can think of Aztec as a private world computer with full end-to-end programmable privacy. A private world computer extends Ethereum to add optional privacy at every level, from identity and transactions to the smart contracts themselves.
On Aztec, every wallet is a smart contract that gives users complete control over which aspects they want to make public or keep private.
Aztec is currently in Testnet, but will have multiple privacy-preserving bridges live for its mainnet launch, unlocking a myriad of privacy preserving features.
Now, several bridges, including Wormhole, TRAIN, and Substance, are connecting Aztec to other chains, adding a privacy layer to the L2s you already use. Think of it as a secure tunnel between you and any DeFi app on Ethereum, Arbitrum, Base, Optimism, or other major chains.
Here's what changes: You can now use any DeFi protocol without revealing your identity. Furthermore, you can also unlock brand new features that take advantage of Aztec’s private smart contracts, like private DAO voting or private compliance checks.
Here's what you can do:
The apps stay where they are. Your liquidity stays where it is. Your community stays where it is. You just get a privacy upgrade.
Let's follow Alice through a real example.
Alice wants to invest $1,000 USDC into a yield vault on Arbitrum without revealing her identity.
Alice moves her funds into Aztec's privacy layer. This could be done in one click directly in the app that she’s already using if the app has integrated one of the bridges. Think of this like dropping a sealed envelope into a secure mailbox. The funds enter a private space where transactions can't be tracked back to her wallet.
Aztec routes Alice's funds to the Yearn vault on Arbitrum. The vault sees a deposit and issues yield-earning tokens. But there's no way to trace those tokens back to Alice's original wallet. Others can see someone made a deposit, but they have no idea who.
The yield tokens arrive in Alice's private Aztec wallet. She can hold them, trade them privately, or eventually withdraw them, without anyone connecting the dots.
Alice is earning yield on Arbitrum using the exact same vault as everyone else. But while other users broadcast their entire investment strategy, Alice's moves remain private.
The difference looks like this:
Without privacy: "Wallet 0x742d...89ab deposited $5,000 into Yearn vault at 2:47 PM"
With Aztec privacy: "Someone deposited funds into Yearn vault" (but who? from where? how much? unknowable).
In the future, we expect apps to directly integrate Aztec, making this experience seamless for you as a user.
While Aztec is still in Testnet, multiple teams are already building bridges right now in preparation for the mainnet launch.
Projects like Substance Labs, Train, and Wormhole are creating connections between Aztec and major chains like Optimism, Unichain, Solana, and Aptos. This means you'll soon have private access to DeFi across nearly every major ecosystem.
Aztec has also launched a dedicated cross-chain catalyst program to support developers with grants to build additional bridges and apps.
L2s have sometimes received criticism for fragmenting liquidity across chains. Aztec is taking a different approach. Instead, Aztec is bringing privacy to the liquidity that already exists. Your funds stay on Arbitrum, Optimism, Base, wherever the deepest pools and best apps already live. Aztec doesn't compete for liquidity, it adds privacy to existing liquidity.
You can access Uniswap's billions in trading volume. You can tap into Aave's massive lending pools. You can deposit into Yearn's established vaults, all without moving liquidity away from where it's most useful.
We’re rolling out a new approach to how we think about L2s on Ethereum. Rather than forcing users to choose between privacy and access to the best DeFi applications, we’re making privacy a feature you can add to any protocol you're already using. As more bridges go live and applications integrate Aztec directly, using DeFi privately will become as simple as clicking a button—no technical knowledge required, no compromise on the apps and liquidity you depend on.
While Aztec is currently in testnet, the infrastructure is rapidly taking shape. With multiple bridge providers building connections to major chains and a dedicated catalyst program supporting developers, the path to mainnet is clear. Soon, you'll be able to protect your privacy while still participating fully in the Ethereum ecosystem.
If you’re a developer and want a full technical breakdown, check out this post. To stay up to date with the latest updates for network operators, join the Aztec Discord and follow Aztec on X.
OTC trading is fundamental to how crypto markets function. It enables better price negotiations than what you'll find on public order books and facilitates trading of illiquid assets that barely exist on exchanges. Without OTC markets, institutional crypto trading would be nearly impossible. But here's the massive problem: every single OTC transaction leaves a permanent, public trace.
Let's say you're a fund manager who needs to sell 1,000 BTC for USDC on Base. In a traditional OTC trade, your Bitcoin leaves your wallet and becomes visible to everyone on Bitcoin's blockchain. Through cross-chain settlement, USDC then arrives in your Base wallet, which is also visible to everyone on Base's blockchain.
At this point, block explorers and analytics firms can connect these transactions through pattern analysis. As a result, your trading patterns, position sizes, and timing become public data, exposing your entire strategy.
This isn't just about privacy; transparent OTC creates serious operational and strategic risks. These same concerns have moved a significant portion of traditional markets to private off-exchange trades.
In TradFi, institutions don't execute large trades on public order books for many reasons. In fact, ~13% of all stocks in the US are now traded in dark pools, and more than 50% of trades are now off-exchange.
They use private networks, dark pools, and OTC desks specifically because:
While OTC trading is already a major part of the crypto industry, without privacy, true institutional participation will never be practical.
Now, Aztec is making this possible.
We built an open-source private OTC trading system using Aztec Network's programmable privacy features. Because Aztec allows users to have private, programmable, and composable private state, users aren’t limited to only owning and transferring digital assets privately, but also programming and composing them via smart contracts.
If you’re new to Aztec, you can think of the network as a private world computer, with full end-to-end programmable privacy. A private world computer extends Ethereum to add optional privacy at every level, from identity and transactions to the smart contracts themselves.
To build a private OTC desk, we leveraged all these tools provided by Aztec to implement a working proof of concept. Our private OTC desk is non-custodial and leverages private smart contracts and client-side proving to allow for complete privacy of the seller and buyer of the OTC.
How It Actually Works
For Sellers:
For Buyers:
The Magic: Partial Notes are the technical breakthrough that make collaborative, asynchronous private transactions possible. Sellers create incomplete payment commitments that buyers can finish without revealing the seller's identity. It's like leaving a blank check that only the right person can cash, but neither party knows who the other is.
Privacy guarantees include:
Private Contract Deployment: Unlike public decentralized exchanges where smart contracts are visible on the blockchain, the escrow contracts in this system are deployed privately, meaning that only the participants involved in the transaction know these contracts exist.
Partial Note Mechanism: This system uses cryptographic primitives that enable incomplete commitments to be finalized or completed by third parties, all while preventing those third parties from revealing or accessing any pre-existing information that was part of the original commitment.
Privacy-Preserving Discovery: The orderflow service maintains knowledge of aggregate trading volumes and overall market activity, but it cannot see the details of individual traders, including their specific trade parameters or personal identities.
Atomic Execution: The smart contract logic is designed to ensure that both sides of a trade occur simultaneously in a single atomic operation, meaning that if any part of the transaction fails, the entire transaction is rolled back and neither party's assets are transferred.
Our prototype for this is open-sourced here, and you can read about the proof of concept directly from the developer here.
We're inviting teams to explore, fork, and commercialize this idea. The infrastructure for private institutional trading needs to exist, and Aztec makes it possible today. Whether you're building a private DEX, upgrading your OTC desk, or exploring new DeFi primitives, this codebase is your starting point.
The traditional finance world conducts trillions in private OTC trades. It's time to bring that scale to crypto, privately.
To stay up to date with the latest updates for network operators, join the Aztec Discord and follow Aztec on X.
Watch this: Alice sends Zcash. Bob receives USDC on Aztec. Nobody, not even the system facilitating it, knows who Alice or Bob are.
And Bob can now do something with that money. Privately.
This is the connection between private money and a private economy where that money can actually be used.
Zcash has already achieved something monumental: truly private money. It’s the store of value that Bitcoin promised (but made transparent). Like, digital gold that actually stays hidden.
But here's the thing about gold - you don't buy coffee with gold bars. You need an economy where that value can flow, work, and grow. Privately.
While other projects are trying to bolt privacy onto existing chains as an afterthought, Zcash is one of the oldest privacy projects in Web3. It's achieved what dozens of projects are still chasing: a truly private store of value.
This is critical infrastructure for freedom. The ability to store value privately is a fundamental right, a hedge against surveillance, and a given when using cash. We need a system that provides the same level of privacy guarantees as cash. Right now, there's over $1.1 billion sitting in Zcash's shielded pool, private wealth that's perfectly secure but essentially frozen.
Why frozen? Because the moment that shielded $ZEC tries to do anything beyond basic transfers: earn yield, get swapped for stablecoins, enter a liquidity pool, it must expose itself. The privacy in this format is destroyed.
This isn't Zcash's failure. They built exactly what they set out to build: the world's best private store of value. The failure is that the rest of crypto hasn't built where that value can actually work.
The Privacy Landscape Has an Imbalance
What happens when you want to do more than just send money? What happens when you want privacy after you transfer your money?
Private Digital Money (i.e., “Transfer Privacy,” largely solved by Zcash):
Private World Computer (i.e., After-the-Transfer Privacy):
Everyone else is competing to build better ways to hide money. Zcash has already built the private store of value, and Aztec has built the only way to use hidden money.
Here's the trillion-dollar question: What good is private money if you can't use it?
Right now, Zcash's shielded pool contains billions in value. This is money in high-security vaults. But unlike gold in vaults that can be collateralized, borrowed against, or deployed, this private value just sits there.
Every $ZEC holder faces two impossible choices:
Our demo breaks this false sense of choice. For the first time, shielded value can move to a place where it remains private AND becomes useful.
Here's how you can identify whether you’re dealing with a private world computer, or just private digital money:
Without a private world computer (every other privacy solution):
With a private world computer (only Aztec):
This is basic financial common sense. Your money should grow. It should work. It should be useful.
The technical reality is that this requires private smart contracts. Aztec is building the only way to interact privately with smart contracts. These smart contracts themselves can remain completely hidden. Your private money can finally do what money is supposed to do: work for you.
Our demo proves these two worlds can connect:
We built the bridge between storing privately and doing privately.
The technical innovation - "partial notes" - are like temporary lockboxes that self-destruct after one use. Money can be put privately into these lockboxes, and a key can be privately handed to someone to unlock it. No one knows who put the money in, where the key came from, or who uses the key. You can read more about how they work here. But what matters isn't the mechanism.
What matters is that Alice's Zcash can become Bob's working capital on Aztec without anyone knowing about either of them.
As a result, Bob receives USDC that he can:
You can't bolt privacy onto existing systems. You can't take Ethereum and make it private. You can't take a transparent smart contract platform and add privacy as a feature.
Aztec had to be built from the ground up as a private world computer because after-the-transfer privacy requires rethinking everything:
This is why there's only one name building fully private smart contracts. From the beginning, Aztec has been inspired by the work Zcash has done to create a private store of value. That’s what led to the vision for a private world computer.
Everyone else is iterating on the same transfer privacy problem. Aztec solves a fundamentally different problem.
Once you see it, you can't unsee it: Privacy without utility is only the first step.
Every privacy project will eventually need what Aztec built. Because their users will eventually ask: "Okay, my money is private... now what?"
This demo that connects Zcash to Aztec is the first connection between the old world (private transfers) and the new world (private everything else).
For Zcash Holders: Your shielded $ZEC can finally do something without being exposed.
For Developers: Stop trying to build better mattresses to hide money under. Start building useful applications on the only platform that keeps them private.
For the Industry: The privacy wars are over. There's transfer privacy (solved by Zcash) and after-the-transfer privacy (just Aztec).
This demo is live. The code is open source. The bridge between private money and useful private money exists.
But this is just the beginning. Every privacy project needs this bridge. Every private payment network needs somewhere for those payments to actually be used.
We're not competing with transfer privacy. We're continuing it.
Your private money yearns for the private economy.
Welcome to after-the-transfer privacy. Welcome to Aztec.
Privacy has emerged as a major driver for the crypto industry in 2025. We’ve seen the explosion of Zcash, the Ethereum Foundation’s refocusing of PSE, and the launch of Aztec’s testnet with over 24,000 validators powering the network. Many apps have also emerged to bring private transactions to Ethereum and Solana in various ways, and exciting technologies like ZKPassport that privately bring identity on-chain using Noir have become some of the most talked about developments for ushering in the next big movements to the space.
Underpinning all of these developments is the emerging consensus that without privacy, blockchains will struggle to gain real-world adoption.
Without privacy, institutions can’t bring assets on-chain in a compliant way or conduct complex swaps and trades without revealing their strategies. Without privacy, DeFi remains dominated and controlled by advanced traders who can see all upcoming transactions and manipulate the market. Without privacy, regular people will not want to move their lives on-chain for the entire world to see every detail about their every move.
While there's been lots of talk about privacy, few can define it. In this piece we’ll outline the three pillars of privacy and gives you a framework for evaluating the privacy claims of any project.
True privacy rests on three essential pillars: transaction privacy, identity privacy, and computational privacy. It is only when we have all three pillars that we see the emergence of a private world computer.
Transaction privacy means that both inputs and outputs are not viewable by anyone other than the intended participants. Inputs include any asset, value, message, or function calldata that is being sent. Outputs include any state changes or transaction effects, or any transaction metadata caused by the transaction. Transaction privacy is often primarily achieved using a UTXO model (like Zcash or Aztec’s private state tree). If a project has only the option for this pillar, it can be said to be confidential, but not private.
Identity privacy means that the identities of those involved are not viewable by anyone other than the intended participants. This includes addresses or accounts and any information about the identity of the participants, such as tx.origin, msg.sender, or linking one’s private account to public accounts. Identity privacy can be achieved in several ways, including client-side proof generation that keeps all user info on the users’ devices. If a project has only the option for this pillar, it can be said to be anonymous, but not private.
Computation privacy means that any activity that happens is not viewable by anyone other than the intended participants. This includes the contract code itself, function execution, contract address, and full callstack privacy. Additionally, any metadata generated by the transaction is able to be appropriately obfuscated (such as transaction effects, events are appropriately padded, inclusion block number are in appropriate sets). Callstack privacy includes which contracts you call, what functions in those contracts you’ve called, what the results of those functions were, any subsequent functions that will be called after, and what the inputs to the function were. A project must have the option for this pillar to do anything privately other than basic transactions.
Bitcoin ushered in a new paradigm of digital money. As a permissionless, peer-to-peer currency and store of value, it changed the way value could be sent around the world and who could participate. Ethereum expanded this vision to bring us the world computer, a decentralized, general-purpose blockchain with programmable smart contracts.
Given the limitations of running a transparent blockchain that exposes all user activity, accounts, and assets, it was clear that adding the option to preserve privacy would unlock many benefits (and more closely resemble real cash). But this was a very challenging problem. Zcash was one of the first to extend Bitcoin’s functionality with optional privacy, unlocking a new privacy-preserving UTXO model for transacting privately. As we’ll see below, many of the current privacy-focused projects are working on similar kinds of private digital money for Ethereum or other chains.
Now, Aztec is bringing us the final missing piece: a private world computer.
A private world computer is fully decentralized, programmable, and permissionless like Ethereum and has optional privacy at every level. In other words, Aztec is extending all the functionality of Ethereum with optional transaction, identity, and computational privacy. This is the only approach that enables fully compliant, decentralized applications to be built that preserve user privacy, a new design space that we see as ushering in the next Renaissance for the space.
Private digital money emerges when you have the first two privacy pillars covered - transactions and identity - but you don’t have the third - computation. Almost all projects today that claim some level of privacy are working on private digital money. This includes everything from privacy pools on Ethereum and L2s to newly emerging payment L1s like Tempo and Arc that are developing various degrees of transaction privacy
When it comes to digital money, privacy exists on a spectrum. If your identity is hidden but your transactions are visible, that's what we call anonymous. If your transactions are hidden but your identity is known, that's confidential. And when both your identity and transactions are protected, that's true privacy. Projects are working on many different approaches to implement this, from PSE to Payy using Noir, the zkDSL built to make it intuitive to build zk applications using familiar Rust-like syntax.
Private digital money is designed to make payments private, but any interaction with more complex smart contracts than a straightforward payment transaction is fully exposed.
What if we also want to build decentralized private apps using smart contracts (usually multiple that talk to each other)? For this, you need all three privacy pillars: transaction, identity, and compute.
If you have these three pillars covered and you have decentralization, you have built a private world computer. Without decentralization, you are vulnerable to censorship, privileged backdoors and inevitable centralized control that can compromise privacy guarantees.
What exactly is a private world computer? A private world computer extends all the functionality of Ethereum with optional privacy at every level, so developers can easily control which aspects they want public or private and users can selectively disclose information. With Aztec, developers can build apps with optional transaction, identity, and compute privacy on a fully decentralized network. Below, we’ll break down the main components of a private world computer.
A private world computer is powered by private smart contracts. Private smart contracts have fully optional privacy and also enable seamless public and private function interaction.
Private smart contracts simply extend the functionality of regular smart contracts with added privacy.
As a developer, you can easily designate which functions you want to keep private and which you want to make public. For example, a voting app might allow users to privately cast votes and publicly display the result. Private smart contracts can also interact privately with other smart contracts, without needing to make it public which contracts have interacted.
Transaction: Aztec supports the optionality for fully private inputs, including messages, state, and function calldata. Private state is updated via a private UTXO state tree.
Identity: Using client-side proofs and function execution, Aztec can optionally keep all user info private, including tx.origin and msg.sender for transactions.
Computation: The contract code itself, function execution, and call stack can all be kept private. This includes which contracts you call, what functions in those contracts you’ve called, what the results of those functions were, and what the inputs to the function were.
A decentralized network must be made up of a permissionless network of operators who run the network and decide on upgrades. Aztec is run by a decentralized network of node operators who propose and attest to transactions. Rollup proofs on Aztec are also run by a decentralized prover network that can permissionlessly submit proofs and participate in block rewards. Finally, the Aztec network is governed by the sequencers, who propose, signal, vote, and execute network upgrades.
A private world computer enables the creation of DeFi applications where accounts, transactions, order books, and swaps remain private. Users can protect their trading strategies and positions from public view, preventing front-running and maintaining competitive advantages. Additionally, users can bridge privately into cross-chain DeFi applications, allowing them to participate in DeFi across multiple blockchains while keeping their identity private despite being on an existing transparent blockchain.
This technology makes it possible to bring institutional trading activity on-chain while maintaining the privacy that traditional finance requires. Institutions can privately trade with other institutions globally, without having to touch public markets, enjoying the benefits of blockchain technology such as fast settlement and reduced counterparty risk, without exposing their trading intentions or volumes to the broader market.
Organizations can bring client accounts and assets on-chain while maintaining full compliance. This infrastructure protects on-chain asset trading and settlement strategies, ensuring that sophisticated financial operations remain private. A private world computer also supports private stablecoin issuance and redemption, allowing financial institutions to manage digital currency operations without revealing sensitive business information.
Users have granular control over their privacy settings, allowing them to fine-tune privacy levels for their on-chain identity according to their specific needs. The system enables selective disclosure of on-chain activity, meaning users can choose to reveal certain transactions or holdings to regulators, auditors, or business partners while keeping other information private, meeting compliance requirements.
The shift from transparent blockchains to privacy-preserving infrastructure is the foundation for bringing the next billion users on-chain. Whether you're a developer building the future of private DeFi, an institution exploring compliant on-chain solutions, or simply someone who believes privacy is a fundamental right, now is the time to get involved.
Follow Aztec on X to stay updated on the latest developments in private smart contracts and decentralized privacy technology. Ready to contribute to the network? Run a node and help power the private world computer.
The next Renaissance is here, and it’s being powered by the private world computer.
Special thanks to Santiago Palladino, Phil Windle, Alex Gherghisan, and Mitch Tracy for technical updates and review.
On September 17th, 2025, a new network upgrade was deployed, making Aztec more secure and flexible for home stakers. This upgrade, shipped with all the features needed for a fully decentralized network launch, includes a completely redesigned slashing system that allows inactive or malicious operators to be removed, and does not penalize home stakers for short outages.
With over 23,000 operators running validators across 6 continents (in a variety of conditions), it is critical not to penalize nodes that temporarily drop due to internet connectivity issues. This is because users of the network are also found across the globe, some of whom might have older phones. A significant effort was put into shipping a low-memory proving mode that allows older mobile devices to send transactions and use privacy-preserving apps.
The network was successfully deployed, and all active validators on the old testnet were added to the queue of the new testnet. This manual migration was only necessary because major upgrades to the governance contracts had gone in since the last testnet was deployed. The new testnet started producing blocks after the queue started to be “flushed,” moving validators into the rollup. Because the network is fully decentralized, the initial flush could have been called by anyone. The network produced ~2k blocks before an invalid block made it to the chain and temporarily stalled block production. Block production is now restored and the network is healthy. This post explains what caused the issue and provides an update on the current status of the network.
Note: if you are a network operator, you must upgrade to version 2.0.3 and restart your node to participate in the latest testnet. If you want to run a node, it’s easy to get started.
This upgrade was a team-wide effort that optimized performance and implemented all the mechanisms needed to launch Aztec as a fully decentralized network from day 1.
With these updates in place, we’re ready to test a feature-complete network.
As mentioned above, block production started when someone called the flush function and a minimum number of operators from the queue were let into the validator set.
Shortly thereafter, while testing the network, a member of the Aztec Labs team spun up a “bad” sequencer that produced an invalid block proposal. Specifically, one of the state trees in the proposal was tampered with.
The expectation was that this would be detected immediately and the block rejected. Instead, a bug was discovered in the validator code where the invalid block proposal wasn't checked thoroughly enough. In effect, the proposal got enough attestations, so it was posted to the rollup. Due to extra checks in the nodes, when the nodes pulled the invalid block from Ethereum, they detected the tampered tree and refused to sync it. This is a good outcome as it prevented the attack. Additionally, prover nodes refused to prove the epoch containing the invalid block. This allowed the rollup to prune the entire bad epoch away. After the prune, the invalid state was reset to the last known good block.
The prune revealed another, smaller bug, where, after a failed block sync, a prune does not get processed correctly, requiring a node restart to clear up. This led to a 90-minute outage from the moment the block proposal was posted until the testnet recovered. The time was equally split between waiting for pruning to happen and for the nodes to restart in order to process the prune.
Validators were correctly re-executing all transactions in the block proposals and verifying that the world state root matched the one in the block proposal, but they failed to check that intermediate tree roots, which are included in the proposal and posted to the rollup contract on L1, were also correct. The attack tweaked one of these intermediate roots while proposing a correct world state root, so it went unnoticed by the attestors.
As mentioned above, even though the block made it through the initial attestation and was posted to L1, the invalid block was caught by the validators, and the entire epoch was never proven as provers refused to generate a proof for the inconsistent state.
A fix was pushed that resolved this issue and ensured that invalid block proposals would be caught and rejected. A second fix was pushed that ensures inconsistent state is removed from the uncommitted cache of the world state.
Block production is currently running smoothly, and the network health has been restored.
Operators who had previously upgraded to version 2.0.3 will need to restart their nodes. Any operator who has not upgraded to 2.0.3 should do so immediately.
Slashing has also been functioning as expected. Below you can see the slashing signals for each round. A single signal can contain votes for multiple validators, but a validator's attester needs to receive 65 votes to be slashed.
Join us this Thursday, September 25, 2025, at 4 PM CET on the Discord Town Hall to hear more about the 2.0.3 upgrade. To stay up to date with the latest updates for network operators, join the Aztec Discord and follow Aztec on X.
Privacy has emerged as a major driver for the crypto industry in 2025. We’ve seen the explosion of Zcash, the Ethereum Foundation’s refocusing of PSE, and the launch of Aztec’s testnet with over 24,000 validators powering the network. Many apps have also emerged to bring private transactions to Ethereum and Solana in various ways, and exciting technologies like ZKPassport that privately bring identity on-chain using Noir have become some of the most talked about developments for ushering in the next big movements to the space.
Underpinning all of these developments is the emerging consensus that without privacy, blockchains will struggle to gain real-world adoption.
Without privacy, institutions can’t bring assets on-chain in a compliant way or conduct complex swaps and trades without revealing their strategies. Without privacy, DeFi remains dominated and controlled by advanced traders who can see all upcoming transactions and manipulate the market. Without privacy, regular people will not want to move their lives on-chain for the entire world to see every detail about their every move.
While there's been lots of talk about privacy, few can define it. In this piece we’ll outline the three pillars of privacy and gives you a framework for evaluating the privacy claims of any project.
True privacy rests on three essential pillars: transaction privacy, identity privacy, and computational privacy. It is only when we have all three pillars that we see the emergence of a private world computer.
Transaction privacy means that both inputs and outputs are not viewable by anyone other than the intended participants. Inputs include any asset, value, message, or function calldata that is being sent. Outputs include any state changes or transaction effects, or any transaction metadata caused by the transaction. Transaction privacy is often primarily achieved using a UTXO model (like Zcash or Aztec’s private state tree). If a project has only the option for this pillar, it can be said to be confidential, but not private.
Identity privacy means that the identities of those involved are not viewable by anyone other than the intended participants. This includes addresses or accounts and any information about the identity of the participants, such as tx.origin, msg.sender, or linking one’s private account to public accounts. Identity privacy can be achieved in several ways, including client-side proof generation that keeps all user info on the users’ devices. If a project has only the option for this pillar, it can be said to be anonymous, but not private.
Computation privacy means that any activity that happens is not viewable by anyone other than the intended participants. This includes the contract code itself, function execution, contract address, and full callstack privacy. Additionally, any metadata generated by the transaction is able to be appropriately obfuscated (such as transaction effects, events are appropriately padded, inclusion block number are in appropriate sets). Callstack privacy includes which contracts you call, what functions in those contracts you’ve called, what the results of those functions were, any subsequent functions that will be called after, and what the inputs to the function were. A project must have the option for this pillar to do anything privately other than basic transactions.
Bitcoin ushered in a new paradigm of digital money. As a permissionless, peer-to-peer currency and store of value, it changed the way value could be sent around the world and who could participate. Ethereum expanded this vision to bring us the world computer, a decentralized, general-purpose blockchain with programmable smart contracts.
Given the limitations of running a transparent blockchain that exposes all user activity, accounts, and assets, it was clear that adding the option to preserve privacy would unlock many benefits (and more closely resemble real cash). But this was a very challenging problem. Zcash was one of the first to extend Bitcoin’s functionality with optional privacy, unlocking a new privacy-preserving UTXO model for transacting privately. As we’ll see below, many of the current privacy-focused projects are working on similar kinds of private digital money for Ethereum or other chains.
Now, Aztec is bringing us the final missing piece: a private world computer.
A private world computer is fully decentralized, programmable, and permissionless like Ethereum and has optional privacy at every level. In other words, Aztec is extending all the functionality of Ethereum with optional transaction, identity, and computational privacy. This is the only approach that enables fully compliant, decentralized applications to be built that preserve user privacy, a new design space that we see as ushering in the next Renaissance for the space.
Private digital money emerges when you have the first two privacy pillars covered - transactions and identity - but you don’t have the third - computation. Almost all projects today that claim some level of privacy are working on private digital money. This includes everything from privacy pools on Ethereum and L2s to newly emerging payment L1s like Tempo and Arc that are developing various degrees of transaction privacy
When it comes to digital money, privacy exists on a spectrum. If your identity is hidden but your transactions are visible, that's what we call anonymous. If your transactions are hidden but your identity is known, that's confidential. And when both your identity and transactions are protected, that's true privacy. Projects are working on many different approaches to implement this, from PSE to Payy using Noir, the zkDSL built to make it intuitive to build zk applications using familiar Rust-like syntax.
Private digital money is designed to make payments private, but any interaction with more complex smart contracts than a straightforward payment transaction is fully exposed.
What if we also want to build decentralized private apps using smart contracts (usually multiple that talk to each other)? For this, you need all three privacy pillars: transaction, identity, and compute.
If you have these three pillars covered and you have decentralization, you have built a private world computer. Without decentralization, you are vulnerable to censorship, privileged backdoors and inevitable centralized control that can compromise privacy guarantees.
What exactly is a private world computer? A private world computer extends all the functionality of Ethereum with optional privacy at every level, so developers can easily control which aspects they want public or private and users can selectively disclose information. With Aztec, developers can build apps with optional transaction, identity, and compute privacy on a fully decentralized network. Below, we’ll break down the main components of a private world computer.
A private world computer is powered by private smart contracts. Private smart contracts have fully optional privacy and also enable seamless public and private function interaction.
Private smart contracts simply extend the functionality of regular smart contracts with added privacy.
As a developer, you can easily designate which functions you want to keep private and which you want to make public. For example, a voting app might allow users to privately cast votes and publicly display the result. Private smart contracts can also interact privately with other smart contracts, without needing to make it public which contracts have interacted.
Transaction: Aztec supports the optionality for fully private inputs, including messages, state, and function calldata. Private state is updated via a private UTXO state tree.
Identity: Using client-side proofs and function execution, Aztec can optionally keep all user info private, including tx.origin and msg.sender for transactions.
Computation: The contract code itself, function execution, and call stack can all be kept private. This includes which contracts you call, what functions in those contracts you’ve called, what the results of those functions were, and what the inputs to the function were.
A decentralized network must be made up of a permissionless network of operators who run the network and decide on upgrades. Aztec is run by a decentralized network of node operators who propose and attest to transactions. Rollup proofs on Aztec are also run by a decentralized prover network that can permissionlessly submit proofs and participate in block rewards. Finally, the Aztec network is governed by the sequencers, who propose, signal, vote, and execute network upgrades.
A private world computer enables the creation of DeFi applications where accounts, transactions, order books, and swaps remain private. Users can protect their trading strategies and positions from public view, preventing front-running and maintaining competitive advantages. Additionally, users can bridge privately into cross-chain DeFi applications, allowing them to participate in DeFi across multiple blockchains while keeping their identity private despite being on an existing transparent blockchain.
This technology makes it possible to bring institutional trading activity on-chain while maintaining the privacy that traditional finance requires. Institutions can privately trade with other institutions globally, without having to touch public markets, enjoying the benefits of blockchain technology such as fast settlement and reduced counterparty risk, without exposing their trading intentions or volumes to the broader market.
Organizations can bring client accounts and assets on-chain while maintaining full compliance. This infrastructure protects on-chain asset trading and settlement strategies, ensuring that sophisticated financial operations remain private. A private world computer also supports private stablecoin issuance and redemption, allowing financial institutions to manage digital currency operations without revealing sensitive business information.
Users have granular control over their privacy settings, allowing them to fine-tune privacy levels for their on-chain identity according to their specific needs. The system enables selective disclosure of on-chain activity, meaning users can choose to reveal certain transactions or holdings to regulators, auditors, or business partners while keeping other information private, meeting compliance requirements.
The shift from transparent blockchains to privacy-preserving infrastructure is the foundation for bringing the next billion users on-chain. Whether you're a developer building the future of private DeFi, an institution exploring compliant on-chain solutions, or simply someone who believes privacy is a fundamental right, now is the time to get involved.
Follow Aztec on X to stay updated on the latest developments in private smart contracts and decentralized privacy technology. Ready to contribute to the network? Run a node and help power the private world computer.
The next Renaissance is here, and it’s being powered by the private world computer.
After eight years of solving impossible problems, the next renaissance is here.
We’re at a major inflection point, with both our tech and our builder community going through growth spurts. The purpose of this rebrand is simple: to draw attention to our full-stack privacy-native network and to elevate the rich community of builders who are creating a thriving ecosystem around it.
For eight years, we’ve been obsessed with solving impossible challenges. We invented new cryptography (Plonk), created an intuitive programming language (Noir), and built the first decentralized network on Ethereum where privacy is native rather than an afterthought.
It wasn't easy. But now, we're finally bringing that powerful network to life. Testnet is live with thousands of active users and projects that were technically impossible before Aztec.
Our community evolution mirrors our technical progress. What started as an intentionally small, highly engaged group of cracked developers is now welcoming waves of developers eager to build applications that mainstream users actually want and need.
A brand is more than aesthetics—it's a mental model that makes Aztec's spirit tangible.
Renaissance means "rebirth"—and that's exactly what happens when developers gain access to privacy-first infrastructure. We're witnessing the emergence of entirely new application categories, business models, and user experiences.
The faces of this renaissance are the builders we serve: the entrepreneurs building privacy-preserving DeFi, the activists building identity systems that protect user privacy, the enterprise architects tokenizing real-world assets, and the game developers creating experiences with hidden information.
This next renaissance isn't just about technology—it's about the ethos behind the build. These aren't just our values. They're the shared DNA of every builder pushing the boundaries of what's possible on Aztec.
Agency: It’s what everyone deserves, and very few truly have: the ability to choose and take action for ourselves. On the Aztec Network, agency is native
Genius: That rare cocktail of existential thirst, extraordinary brilliance, and mind-bending creation. It’s fire that fuels our great leaps forward.
Integrity: It’s the respect and compassion we show each other. Our commitment to attacking the hardest problems first, and the excellence we demand of any solution.
Obsession: That highly concentrated insanity, extreme doggedness, and insatiable devotion that makes us tick. We believe in a different future—and we can make it happen, together.
Just as our technology bridges different eras of cryptographic innovation, our new visual identity draws from multiple periods of human creativity and technological advancement.
Our new wordmark embodies the diversity of our community and the permissionless nature of our network. Each letter was custom-drawn to reflect different pivotal moments in human communication and technological progress.
Together, these letters tell the story of human innovation: each era building on the last, each breakthrough enabling the next renaissance. And now, we're building the infrastructure for the one that's coming.
We evolved our original icon to reflect this new chapter while honoring our foundation. The layered diamond structure tells the story:
The architecture echoes a central plaza—the Roman forum, the Greek agora, the English commons, the American town square—places where people gather, exchange ideas, build relationships, and shape culture. It's a fitting symbol for the infrastructure enabling the next leap in human coordination and creativity.
From the Mughal and Edo periods to the Flemish and Italian Renaissance, our brand imagery draws from different cultures and eras of extraordinary human flourishing—periods when science, commerce, culture and technology converged to create unprecedented leaps forward. These visuals reflect both the universal nature of the Renaissance and the global reach of our network.
But we're not just celebrating the past —we're creating the future: the infrastructure for humanity's next great creative and technological awakening, powered by privacy-native blockchain technology.
Join us to ask questions, learn more and dive into the lore.
Join Our Discord Town Hall. September 4th at 8 AM PT, then every Thursday at 7 AM PT. Come hear directly from our team, ask questions, and connect with other builders who are shaping the future of privacy-first applications.
Take your stance on privacy. Visit the privacy glyph generator to create your custom profile pic and build this new world with us.
Stay Connected. Visit the new website and to stay up-to-date on all things Noir and Aztec, make sure you’re following along on X.
The next renaissance is what you build on Aztec—and we can't wait to see what you'll create.
Aztec’s Public Testnet launched in May 2025.
Since then, we’ve been obsessively working toward our ultimate goal: launching the first fully decentralized privacy-preserving layer-2 (L2) network on Ethereum. This effort has involved a team of over 70 people, including world-renowned cryptographers and builders, with extensive collaboration from the Aztec community.
To make something private is one thing, but to also make it decentralized is another. Privacy is only half of the story. Every component of the Aztec Network will be decentralized from day one because decentralization is the foundation that allows privacy to be enforced by code, not by trust. This includes sequencers, which order and validate transactions, provers, which create privacy-preserving cryptographic proofs, and settlement on Ethereum, which finalizes transactions on the secure Ethereum mainnet to ensure trust and immutability.
Strong progress is being made by the community toward full decentralization. The Aztec Network now includes nearly 1,000 sequencers in its validator set, with 15,000 nodes spread across more than 50 countries on six continents. With this globally distributed network in place, the Aztec Network is ready for users to stress test and challenge its resilience.
We're now entering a new phase: the Adversarial Testnet. This stage will test the resilience of the Aztec Testnet and its decentralization mechanisms.
The Adversarial Testnet introduces two key features: slashing, which penalizes validators for malicious or negligent behavior in Proof-of-Stake (PoS) networks, and a fully decentralized governance mechanism for protocol upgrades.
This phase will also simulate network attacks to test its ability to recover independently, ensuring it could continue to operate even if the core team and servers disappeared (see more on Vitalik’s “walkaway test” here). It also opens the validator set to more people using ZKPassport, a private identity verification app, to verify their identity online.
The Aztec Network testnet is decentralized, run by a permissionless network of sequencers.
The slashing upgrade tests one of the most fundamental mechanisms for removing inactive or malicious sequencers from the validator set, an essential step toward strengthening decentralization.
Similar to Ethereum, on the Aztec Network, any inactive or malicious sequencers will be slashed and removed from the validator set. Sequencers will be able to slash any validator that makes no attestations for an entire epoch or proposes an invalid block.
Three slashes will result in being removed from the validator set. Sequencers may rejoin the validator set at any time after getting slashed; they just need to rejoin the queue.
In addition to testing network resilience when validators go offline and evaluating the slashing mechanisms, the Adversarial Testnet will also assess the robustness of the network’s decentralized governance during protocol upgrades.
Adversarial Testnet introduces changes to Aztec Network’s governance system.
Sequencers now have an even more central role, as they are the sole actors permitted to deposit assets into the Governance contract.
After the upgrade is defined and the proposed contracts are deployed, sequencers will vote on and implement the upgrade independently, without any involvement from Aztec Labs and/or the Aztec Foundation.
Starting today, you can join the Adversarial Testnet to help battle-test Aztec’s decentralization and security. Anyone can compete in six categories for a chance to win exclusive Aztec swag, be featured on the Aztec X account, and earn a DappNode. The six challenge categories include:
Performance will be tracked using Dashtec, a community-built dashboard that pulls data from publicly available sources. Dashtec displays a weighted score of your validator performance, which may be used to evaluate challenges and award prizes.
The dashboard offers detailed insights into sequencer performance through a stunning UI, allowing users to see exactly who is in the current validator set and providing a block-by-block view of every action taken by sequencers.
To join the validator set and start tracking your performance, click here. Join us on Thursday, July 31, 2025, at 4 pm CET on Discord for a Town Hall to hear more about the challenges and prizes. Who knows, we might even drop some alpha.
To stay up-to-date on all things Noir and Aztec, make sure you’re following along on X.
On May 1st, 2025, Aztec Public Testnet went live.
Within the first 24 hours, over 20k users visited the Aztec Playground and started to send transactions on testnet. Additionally, 10 apps launched live on the testnet, including wallets, block explorers, and private DeFi and NFT marketplaces. Launching a decentralized testnet poses significant challenges, and we’re proud that the network has continued to run despite high levels of congestion that led to slow block production for a period of time.
Around 6 hours after announcing the network launch, more than 150 sequencers had joined the validator set to sequence transactions and propose blocks for the network. 500+ additional full nodes were spun up by node operators participating in our Discord community. These sequencers were flooded with over 5k transactions before block production slowed. Let’s dive into why block production slowed down.
On Aztec, an epoch is a group of 32 blocks that are rolled up for settlement on Ethereum. Leading up to the slowdown of block production, there were entire epochs with full blocks (8 transactions, or 0.2TPS) in every slot. The sequencers were building blocks and absorbing the demand for blockspace from users of the Aztec playground, and there was a build up of 100s of pending transactions in sequencer mempools.
Issues arose when these transactions started to exceed the mempool size, which was configured to hold only 100mb or about 700 transactions.
As many new validators were brought through the funnel and started to come online, the mempools of existing validators (already full at 700 transactions) and new ones (at 0 transactions) diverged significantly. When earlier validators proposed blocks, newer validators didn't have the transactions and could not attest to blocks because the request/response protocol wasn't aggressive enough. When newer validators made proposals, earlier validators didn't have transactions (their mempools were full), so they could not attest to blocks.
New validators then started to build up pending transactions. When validators with full mempools requested missing transactions from peers, they would evict existing transactions from their mempools (mempool is at max memory) based on priority fee. All transactions had default fee settings, so validators were randomly ejecting transactions and were not doing so in lockstep (different validators ejected different transactions). For a little over an hour, the mempools diverged significantly from each other, and block production slowed down to about 20% of the expected rate.
In order to stop the mempool from ejecting transactions, the p2p mempool size was increased. By increasing the mempool size, the likelihood of needing to evict transactions that might soon appear in proposals is reduced. This increases the chances that sequencers already have the necessary transactions locally when they receive a block proposal. As a result, more validators are able to attest to proposals, allowing blocks to be finalized more reliably. Once blocks are included on L1, their transactions are evicted from the mempool. So over time, as more blocks are finalized and transactions are mined, the mempool naturally shrinks and the network will recover on its own.
If you are interested in running a sequencer node visit the sequencer page. Stay up-to-date on Noir and Aztec by following Noir and Aztec on X.
Devnet is now live! This milestone enables private, client-side smart contract execution with robust public verifiability, a massive milestone for Aztec and the Ethereum community.
To celebrate this milestone, we’re launching Alpha Build, a series of three developer sprints with a USD $100,000 prize pool and the opportunity to deploy on the Aztec Network for the first time.
The first Alpha Build will kick off Monday, August 19th with two additional Alpha Builds happening by mid-November. Alpha Build participants will receive expert mentorship, gain direct access to the team, and connect with a growing community of over 300 developers from around the globe. In addition to cash prizes, top builders will be invited to deploy their applications on the Devnet.
Complete the Alpha Build Application to gain access to the Discord server, and download the Aztec Sandbox to get started.
Devnet is a culmination of all the hard work and iteration over the past 7 years.
In March 2023, we made a bold commitment to focus on bringing the Aztec Network to life and delivering true programmable privacy. Over the past year and a half, our team has worked tirelessly to bring this vision to life, and their efforts have paid off.
Today, we’re proud to deliver on that commitment and unveil a live Devnet, realizing the integration of all essential components of the tech stack, including Honk, cutting-edge cryptography, Noir for smart contract development, a private execution environment (PXE) for client-side proof generation, and a sequencer for transaction processing and public execution.
Together, they enable private, client-side smart contract execution with robust public verifiability, marking a significant leap forward for the Aztec Network.
Over the next few months, we’ll run three themed Alpha Builds with challenges across the most important use cases in crypto, including payments, gaming, and identity. Privacy expands the design space so you can explore solutions for conditional payments, on and off-chain access control using NFTs stored privately on Aztec, or card games with a shared hidden public state.
The three challenges for Alpha Build One (ab1) will focus on payment use cases with an emphasis on building a UI, Account Abstraction and Fee Abstraction features. If you’re new to Aztec or have been with us from the beginning, ab1 is your chance to dive deep into underexplored problems and designs while contributing to the growing ecosystem.
Complete the Alpha Build Application to gain access to the Discord server, and download the Aztec Sandbox to get started.
The Alpha Build payment challenges are designed to build upon each other, increasing in complexity as the weeks progress. Here’s what you can expect:
Throughout the challenges, the DevRel Team will provide Discord support and host weekly office hours from 10 a.m. - 11 a.m. ET every Wednesday and Thursday.
All submissions for ab1 are due by Sunday, September 15th, 2024, and must include the following:
Don’t miss this opportunity to deploy on the Aztec Network for the first time.
To get started, fill out the Alpha Build Application. We will review applications and, if selected, invite you to join a private Discord channel for our Alpha Build.
The Devnet Live Celebration will be on Friday, August 16th, 2024, at 11:30 a.m. ET on X. Join Cat, our Developer Relations Engineer, and President and Co-Founder, Joe Andrews as they dive deep into Alpha Build season, exploring challenges, themes, and innovative ideas.
In blockchain narrative, the term “zero knowledge” entered our vocabulary when rollups first emerged. In particular, we’ve heard it a lot in the context of zero knowledge rollups (ZK-rollups). But, zero knowledge technology has existed for years before. The first article on zero knowledge was published back in 1989.
In this blog, we’ll break it down to clarify what zero knowledge (ZK) is and what it ISN’T (the latter might actually be more interesting than the former). We’ll investigate if ZK-rollups have any ZK for real, and if not, why they get to use the term at all, and dive into the difference between ZK as a technology and ZK as a marketing term.
For those who need answers right away:
*by privacy we mean (i) user privacy (transaction sender and recipient), (ii) data privacy (payload of the transaction, e.g., the asset or value being transacted), and (iii) code privacy (the program logic).
Now let’s dive a bit deeper.
If we want to discuss ZK in a rollup context, we first need to understand zero knowledge property on its own. As we mentioned above, the concept of ZK was introduced in 1989 (years before the first blockchain was baked) in a paper titled, “The knowledge complexity of interactive proof systems.” It wasn’t until around 2018 that the Ethereum community figured out ZK might be a good fit for a rollup universe.
We usually consider zero knowledge as a property of a proving system. In blockchain, we often say ZKP, meaning zero knowledge proof. But “proof” might mean proof of statement or proof of knowledge. So, in the next section of this article, we will differentiate between the two types of proofs.
Proof of statement proves that a statement is true without revealing anything about the statement itself.
Examples of statements:
Proof of knowledge proves that the person making an assertion has some knowledge about the statement.
So, if we look at the examples from the previous paragraph side-by-side:
Proof of StatementProof of Knowledgez is a square modular n: z = x^2 mod n.I know a value x such that z = x^2 (mod n).The graphs G and H are non-isomorphic.I know the isomorphism between two graphs, G and H.The number 638634389........3427 has 3 prime factors.I know the factors of the number 638634389........3427.
One should note that every proof of knowledge is a proof of statement (but not the opposite). For instance, if one proves that they know a value x such that z = x^2 (mod n), this will be proof of knowledge, but it also automatically proves that z is a square modulo n (proof of statement).
Let’s explore one of these examples to see how proof of statement and proof of knowledge can be constructed!
Let’s use the graph-isomorphism problem. To do this, we’ll say proof of graph non-isomorphism will be proof of statement, while a proof of graph isomorphism will be proof of knowledge.
Basically graph isomorphism (denoted by ≅) is the following: two graphs with labeled nodes are isomorphic if they are "the same" up to a permutation of the labels. That is to say, there exists a permutation of the labels of one graph that results in the other graph.
More formally, we say that two graphs G and H are isomorphic if there is a bijective function f between the vertices’ labels of G and H such that there is an edge between the vertices u and v in G if and only if there is an edge between the vertices f(u) and f(v) in H.
An example of two isomorphic graphs:
If there exists no such permutation, we say that the two graphs are non-isomorphic. Now, assume we want to prove that two graphs are non-isomorphic. We only want to prove this single fact; nothing about the graphs themselves, no other knowledge except for the statement that they are non-isomorphic.
Proof intuition:
One round of protocol:
Now, let’s think… What if we want to prove two graphs are isomorphic? In other words, the Prover wants to prove that they know the isomorphism σ such that H = σ(G).
Proof intuition:
One round of protocol:
Now that we’ve explored examples of proof of statement and proof of knowledge, let’s discuss whether or not they have zero knowledge property.
Informally, zero knowledge means that a Verifier can’t retrieve any additional information from a Prover (except for the information clear from the proof itself).
In the example of graph isomorphism, proof of knowledge is zero knowledge (with honest Verifier). According to the protocol, the Prover doesn’t reveal any information on the isomorphism or permutation to the Verifier. Instead, they send the Verifier commitments and that’s it.
However, in the example of the proof of graph non-isomorphism, it’s not zero knowledge. Because, instead of setting K = π(G) or K = π(H), a malicious Verifier (i.e. a Verifier which deviates from the protocol) can set K = π{RANDOM GRAPH} and as a result of the protocol execution by the Prover, the Verifier will know if RANDOM_GRAPH is isomorphic to either G or H. So the Verifier is definitely able to retrieve additional information.
Can we convert our proof of graph non-isomorphism into zero knowledge? Yes, we can. The Verifier should also provide proof that (i) the graph it sends is isomorphic either to G or to H (meaning the graph they’re sending is not arbitrary), and (ii) they know the isomorphism.
One should note that most protocols in the space are only honest-verifier ZK (i.e. ZK property doesn’t hold with malicious verifier). However, this isn’t an issue because the protocols are made non-interactive with the Fiat-Shamir heuristic. Hence – there is no distinction for non-interactive protocols as the verifier cannot "misbehave.”
Now, when we differentiated between proof of statement and proof of knowledge and saw that both of them can have zero knowledge property or not have it, let’s take a look at ZK-rollup and figure out (i) does it use proof of statement or proof of knowledge, (ii) does it have zero knowledge property?
In a ZK-rollups, the logic is pretty similar to the graph-non-isomorphism problem (where we prove the statement that two graphs are non-isomorphic). In ZK-rollup, we prove the statement that the state transition was done correctly.
In this section, we’ll briefly cover how ZK-rollups work and how they utilize proofs. By “ZK-rollups,'' we mean regular (i.e. NON-privacy-preserving) ZK-rollups such as Scroll, Starknet, zksync, Taiko, and many more.
The main use of “vanilla” ZK-rollups is to enable scalability by posting a single proof of the validity of transactions.
ZK-rollups execute transactions off-chain and post proof on L1 (Ethereum) that whatever they did off-chain was done correctly. Their purpose is to prove that the new chain state is correct.
To generate a proof of correct state transition, one needs to prove that all transactions were executed correctly on given inputs.
For the sake of this, the Prover needs to know previous state and input values.
However, for the Verifier to verify the proof, they need to have the proof as well as to know new state, previous state, and input values:
There are two types of inputs, public and private. In ZK-rollups, “private input” does NOT mean “secret” even though they are called “private.” Instead, it means that private inputs are consumed by Prover only while public inputs are consumed both by Prover and Verifier (sometimes private inputs are also called “witness” as a reference to the NP complexity class). Public inputs are expensive as they need to be submitted to L1 hence we want it to be as small (“succinct”) as possible. In terms of what these inputs consist of in the context of the proof:
Public inputs (consumed by Prover AND Verifier) – all data that needs to be submitted to L1 so that everyone can update their records of the current state. This will include new state root as well as might include signatures, sender, receiver, functions, contract addresses, function arguments, newly-deployed contract data, storage slots which have changed and their new values, events that were emitted. One should note that this reveals A LOT of information to a public observer. The specific list of public inputs will depend on the specific ZK-rollup design.
Private inputs (consumed by Prover ONLY) – all information that was needed by rollup circuits to prove correctness of the state transition. This will include Merkle membership proofs (hash paths) as well as the execution trace (might include transaction inputs such as newly-deployed contract data, storage slots which have changed and their new values, and events that were emitted).
As you can see from the logic above, private inputs have nothing to do with privacy. So if a ZK-rollup is generating a proof that Alice sent Bob 1ETH, both the Prover and the Verifier will be aware of this information (i.e. no privacy at all!).
To sum it up, in the case of a ZK-rollup, we want to prove the validity of transactions, it is a proof of statement and it does NOT have zero-knowledge property because all the information (i.e. state, functions, inputs) is public and everything that is not provided explicitly can be derived by a Verifier.
That is to say, there is no ZK in a vanilla ZK-rollup. Why is it called ZK-rollup then?
.webp)
Maybe… For the sake of marketing =)
Short answer: yes, it can. While the main use of “vanilla” ZK-rollups is to enable scalability, the main use of Aztec is to enable scalability AND allow privacy. And, it utilizes ZK exactly for the privacy purpose.
Aztec provides privacy by means of client-side proof generation, i.e. whatever should be processed privately is processed on the user’s device and then a proof of its correct execution is supplied to the mempool.
Processed privately means that
Client-side proofs are then verified by the sequencer (who manages the mempool).
In this case, client-side proof is a zero knowledge proof of statement: the sequencer verifies the proof validity without any information about what was executed on the client-side, and is unable to retrieve any information about it.
After client-side proofs have been verified by the sequencer, everything is similar to a vanilla ZK-rollup mechanism as described in the previous section. That is to say, Aztec ZK-rollup first generates a number of client-side proofs (which are zero knowledge proofs) and then a block proof (which is not zero knowledge).
It’s not possible to add privacy ad-hoc to an already existing ZK-rollup. It should be designed to be private from the very beginning.
One first needs to give a precise definition of “privacy” as the statements proved, depending on the rollup design, may reveal unnecessary information and harm user privacy.
If builders want their dApps to interact with the external world; meaning that dApps aren’t monolithically private but instead allow some functions and variables to be private while some functions and variables stay public (e.g. necessary for AMMs, lending protocols, etc.), rollup state management becomes very non-trivial. Now it has to process public and private state updates separately. However, it’s exactly the latter approach that unlocks dozens of use cases we’ve been dreaming about for years! (Think programmable on-chain identity management and DeFi alternatives to conservative financial institutions).
As of today, Aztec is one of very few privacy-preserving L2s on Ethereum where privacy is provided by processing private information on the client-side. Check out this article to dive into client-side proof generation and this article to learn more about Aztec smart contracts anatomy allowing for hybrid private and public state management.
Ready to join Aztec’s building pioneers? Let us know by filling out this form.
Many thanks to Palla, Patrick, and Brecht for review.
In the ever-evolving landscape of digital privacy, the power of Zero-Knowledge Proofs (ZKPs) is revolutionizing how we protect and prove information. Noir, a leading language for privacy-first programmable privacy, is at the forefront of this innovation and is calling on you to help us enhance provable emails using Noir. This research campaign (NCR#1), running from August 8th - 25th, 2024 presents a unique opportunity to push the boundaries of privacy while creating novel solutions for secure email verification.
The rise of Programmable Cryptography and Zero-Knowledge Proofs offers unprecedented potential for trustless and private verification of information, cryptographically bridging data across silos. Imagine a world where you can prove ownership of an email address or an email received without revealing its content or personal details. This capability is not just a theoretical possibility, but a practical reality waiting to be unlocked through advanced research and development.
Aztec Labs has been a strong supporter of this vision, particularly with the ZK Email team's pioneering work. As a part of these continued efforts, we invite researchers, developers, tech enthusiasts, and anyone with creative ideas to propose a two-month research plan that explores ways to leverage Noir (and Aztec) to augment this work and its broader vision.
We’re looking for proposals focused on building end-user-oriented projects, including MVPs. Proposals focused on building developer tooling and technical/cryptography research are also welcome as long as their relevance to zkEmail is clear.
Multiple submissions are welcomed, however, to be considered, your proposal must meet the following criteria:
To participate, please head to our GitHub and submit your proposal using the following format:
Proposal submissions are open now and will close on August 25th, 2024. Our selection committee will pick two proposals that will receive up to US$40,000 in grants. Winners will be announced before September 5th, 2024, via GitHub Discussions and X.
Click here to get started on your proposal today.
We believe in the value of the real-world impact of top-tier research.
To ensure the security and quality of applying research outcomes, we’re onboarding audit partners to sponsor and provide auditing for the final implementations of selected proposals. Potential audit partners will be evaluated up to August 20th, 2024, and announced on GitHub by August 31st, 2024.
To learn more about how to get involved, please contact Savio or Lisa.
Join us in pioneering the future of privacy-first communication. Submit your proposal and be part of this transformative journey with Noir!
Special thanks to Palla, James Zaki, and Emmanuel Batse for the review.
Disclaimer: if you’re familiar with Account Abstraction and are curious about how it works on Aztec, go right to the section “The most abstract Account Abstraction”.
Account Abstraction context
What is AA and why did the Ethereum community give it this name?
Note: the second option is sometimes also referred to as “contract wallets” or “smart accounts”.
The story of Account Abstraction
AA on Ethereum
The discussions around AA on Ethereum started around 2017. There were a number of EIPs and ERCs proposing different versions of AA (e.g. EIP-86, suggesting abstraction of transaction origin and signature, EIP-1014, and EIP-2938) that were explored and discussed but ultimately rejected, so we won’t cover them in this piece.
The first ERC affiliated with AA that made it to Ethereum mainnet was ERC-4337 (deployed on Mainnet in March 2023). It introduced AA without any modifications to the core protocol. It achieved this by replicating the functionality of the transactions mempool in a higher-level system. Instead of transactions, users send UserOperation objects to relayers, and these relayers package a set of these objects into a single standard transaction that is sent to Ethereum nodes.
Since then, the community has argued whether ERC-4337 is the Ethereum AA endgame or not. Right now, there is a dispute around EIP-3074 in the next Ethereum protocol upgrade. It suggests AUTH and AUTHCALL opcodes, which allow EOAs to delegate execution to smart contracts. However, one should note that the transaction validity still relies on EOAs’ ECDSA signature (i.e. ECDSA signature becomes enshrined).
This EIP is not new and some ecosystem players have discussed it being complementary to ERC-4337. The core question is what’s the more urgent problem for Ethereum to solve – censorship-resistance (against EIP-3074) or user experience (for EIP-3074)?
As Ethereum follows the rollup-centric roadmap, we expect most activity to happen on Ethereum L2s. As L2s technically don’t depend on Ethereum, they can implement AA on their own by introducing appropriate opcodes.
Some L2s have chosen a native AA “feature” as one of their core value propositions and implemented native AA (among those zkSync, StarkNet, and Aztec). In particular, this means that a transaction can be initiated directly by a smart contract (i.e. without any reliance on EOA).
As a comparison, in ERC-4337, AA is not native, as there is a step in the tx flow where an EOA account is engaged (as a Bundler).
As an alternative to enshrining AA in Ethereum, the Rollup Improvement Proposal (RIP) was proposed. RIP is a way to facilitate L2 standardization (not only around AA but around other L2 aspects as well). RIP-7560 is a native version of ERC-4337 for L2 chains currently under discussion. Check a series of RollCalls to learn more.
The most abstract Account Abstraction
While we talk about “arbitrary verification logic” describing the intuition behind AA, the logic is not really arbitrary. The verification logic (i.e. what can be checked as an authorization) is limited to make the verification time fast and bounded. That is the case for all chains where transaction validity is checked by the sequencer. Otherwise, it will cause UX downfall, whereas the main reason behind introducing AA is UX improvement.
On Aztec, there is no limitation on verification logic, as transaction validity check is executed client-side and a proof of validity is supplied to the sequencer. The sequencer only verifies the proof and this process is independent of the verification logic complexity.
This unlocks a whole universe of new use cases and optimization of existing ones. Whenever the dapp can benefit from moving expensive computations off-chain, Aztec AA will provide a unique chance for an optimization. That is to say, on traditional chains users pay for each executed opcode, hence more complex operations (e.g. alternative signature verification) are quite expensive. In the case of Aztec, it can be moved off-chain so that it becomes almost free. The user pays for the operations in terms of client-side prover time.
For example:
However, one should note that if the verification logic depends on the public state and requires a public function call (e.g. checking the balance), this check will be executed by the sequencer and imply some limitations on the allowed complexity of verification logic. For those who prefer watching over reading, here is a talk, “Account Abstraction for a Private Network”, by Santiago Palladino (Palla).ConclusionAA is not a new topic, however, AA on private networks unlocks new capabilities for arbitrary verification logic, allowing for more complex logic as well as significant cost optimizations. Check documentation to dive into the details of Aztec’s AA. And if you are up to join Aztec’s building pioneers – express your interest in this form. Sources
