Menu
Marking a Feature Complete Testnet, the Last Stop Before Ignition
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.
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.
When Aztec first got started, the world of zero-knowledge proving systems and applications was in its infancy. There was no PLONK, no Noir, no programmable privacy, and it wasn’t clear that demand for onchain privacy was even strong enough to necessitate a new blockchain network.
After a decade of building, revolutionary breakthroughs in privacy technology have paved the way to, and now set the stage for, mainnet including: PLONK, a novel proving system for user-level privacy and programmability that yielded zk.money and Aztec Connect, which was a pivotal moment for privacy and encryption solutions; Noir, an intuitive zero-knowledge, Rust-like programming language; and a client-side library for a private execution environment (PXE). These tools allow developers to explore privacy-preserving applications across any use case where protecting sensitive data is a critical function.
In 2023 and 2024 Aztec was named by Electric Capital as one of the fastest-growing developer ecosystems. The next generation of applications on Ethereum are already being built using parts of the Aztec stack, like Noir. Projects such as zkPassport and zkEmail are unlocking key identity use cases, while other applications like Anoncast (built in one weekend) have caught the attention of heavyweights like Vitalik Buterin and Laura Shin.
Earlier this month, we announced the successful testing of the first decentralized upgrade process for an L2, with over 100 sequencers participating. Now, with the mission to bring programmable privacy to the masses, the Aztec Public Testnet is here and, for the first time ever, open to developers to build fully private applications on Ethereum.
The Aztec Network will launch fully decentralized from day one.
Not because it’s a flex, but because true privacy can only be achieved when there is no central entity that has potential backdoor access.
Imagine logging into your hot wallet using web2 auth with Google or iCloud, or proving you’re a U.S. citizen onchain without revealing your passport information. For this, you need onchain privacy, and true privacy needs full decentralization so the user can maintain control over their data.
This is the vision for the Aztec Network.
Like Zac, our CEO and Co-founder, said in his talk Privacy: The Missing Link, “there are three fundamental attributes required to bridge the gap and bring the world onchain: interfacing with web2 systems, linking accounts to identities, and establishing digital sovereignty.”
Launching a decentralized network is a complex task filled with lots of intricacies and nuances to navigate. The Aztec Public Testnet plays a crucial role in stress-testing the network, identifying early issues, and ensuring its participants work as intended – ultimately leading to a more robust mainnet.
There are two ways you can participate in the network: as a developer who wants to build and deploy applications (with end-to-end privacy) or as a node operator powering the network.
Aztec enables developers to build with both private and public state.
Smart contracts on Aztec blend private functions that execute on the client side with public functions that are executed by sequencers on the Aztec Network. This allows you to customize your contract with both public and private components while deploying them to a fully decentralized network.
The fastest way to get started with the Aztec Public Testnet is to deploy a smart contract using the Playground. If you’re a developer, visit our dev landing page to connect to Testnet and deploy on the Aztec Network.
The Aztec Network is run by a decentralized sequencer and prover network.
Sequencers propose and produce blocks using consumer hardware and are responsible for proposing and voting on network upgrades. Provers participate in a decentralized prover network and are selected to prove the rollup integrity.
No airdrops. No marketing gimmicks. We just want to create a community of highly skilled operators who share the vision of a fully decentralized privacy-preserving network. Anyone can boot up a sequencer node and access the testnet faucet. See the sequencer quickstart to get started. Apply to get a special Discord role and peer support from experienced node operators leading the Aztec Network.
To see existing applications and get inspo for what you want to build on the Aztec Public Testnet, check out our Ecosystem page. If you’ve already built an app and would like to be featured, submit your app here.
Next, head to the Playground to try out the Aztec Public Testnet, where you can deploy and interact with privacy-preserving smart contracts. Tools and infrastructure to start building wallets, bridges, and explorers are already available.
If you’re a developer, click ➡️ here to get started and deploy your smart contract in literal minutes.
If you’re a node operator, click ➡️ here to set up and run a node.
Stay up-to-date on Noir and Aztec by following Noir and Aztec on X.
Aztec will be a fully decentralized, permissionless and privacy-preserving L2 on Ethereum. The purpose of Aztec’s Public Testnet is to test all the decentralization mechanisms needed to launch a strong and decentralized mainnet. In this post, we’ll explore what full decentralization means, how the Aztec Foundation is testing each aspect in the Public Testnet, and the challenges and limitations of testing a decentralized network in a testnet environment.
Three requirements must be met to achieve decentralization for any zero-knowledge L2 network:
Decentralization across sequencing, proving, and governance is essential to ensure that no single party can control or censor the network. Decentralized sequencing guarantees open participation in block production, while decentralized proving ensures that block validation remains trustless and resilient, and finally, decentralized governance empowers the community to guide network evolution without centralized control.
Together, these pillars secure the rollup’s autonomy and long-term trustworthiness. Let’s explore how Aztec’s Public Testnet is testing the implementation of each of these aspects.
Aztec will launch with a fully decentralized sequencer network.
This means that anyone can run a sequencer node and start sequencing transactions, proposing blocks to L1 and validating blocks built by other sequencers. The sequencer network is a proof-of-stake (PoS) network like Ethereum, but differs in an important way. Rather than broadcasting blocks to every sequencer, Aztec blocks are validated by a randomly chosen set of 48 sequencers. In order for a block to be added to the L2 chain, two-thirds of the sequencers need to verify the block. This offers users fast preconfirmations, meaning the Aztec Network can sequence transactions faster while utilizing Ethereum for final settlement security.
PoS is fundamentally an anti-sybil mechanism—it works by giving economic weight to participation and slashing malicious actors. At the time of Aztec’s mainnet, this will allow sequencers to vote out bad actors and burn their staked assets. On the Public Testnet, where there are no real economic incentives, PoS doesn't function properly. To address this, we introduced a queue system that limits how quickly new sequencers can join, helping to maintain network health and giving the network time to react to potential malicious behavior.
Behind the scenes, a contract handles sequencer onboarding—it mints staking assets, adds sequencers to the set, and can remove them if necessary. This contract is just for Public Testnet and will be removed on Mainnet, allowing us to simulate and test the decentralized sequencing mechanisms safely.
Aztec will also launch with a fully decentralized prover network.
Provers generate cryptographic proofs that verify the correctness of public transactions, culminating in a single rollup proof submitted to Ethereum. Decentralized proving reduces centralization risk and liveness failures, but also opens up a marketplace to incentivize fast and efficient proof generation. The proving client developed by Aztec Labs involves three components:
Once the final proof has been computed, the proving node sends the proof to L1 for verification. The Aztec Network splits proving rewards amongst everyone who submits a proof on time, reducing centralization risk where one entity with large compute dominates the network.
For Aztec’s Public Testnet, anyone can spin up a prover node and start generating proofs. Running a prover node is more hardware-intensive than running a sequencer node, requiring ~40 machines with an estimated 16 cores and 128GB RAM each. Because running provers can be cost-intensive and incur the same costs on a testnet as it will on mainnet, Aztec’s Public Testnet will throttle transactions to 0.2 per second (TPS).
Keeping transaction volumes low allows us to test a fully decentralized prover network without overwhelming participating provers with high costs before real network incentives are in place.
Finally, Aztec will launch with fully decentralized governance.
In order for network upgrades to occur, anyone can put forward a proposal for sequencers to consider. If a majority of sequencers signal their support, the proposal gets sent to a vote. Once it passes the vote, anyone can execute the script that will implement the upgrade. Note: For this testnet, the second phase of voting will be skipped.
Decentralized governance is an important step in enabling anyone to participate in shaping the future of the network. The goal of the public testnet is to ensure the mechanisms are functioning properly for sequencers to permissionlessly join and control the Aztec Network from day 1.
One additional aspect to consider with regard to full decentralization is the role of network users in decentralizing the compute load of the network.
Aztec Labs has developed groundbreaking technology to make end-to-end programmable privacy possible. First with the release of Plonk, and later refinements like MegaHonk, which make it feasible to generate client-side ZKPs. Client-side proofs keep sensitive data on the user’s device while still enabling users to interact with and store this information privately onchain. They also help to scale throughput by pushing execution to users. This decentralizes the compute requirements and means users can execute arbitrary logic in their private functions.
Sequencers and provers on the Aztec Network are never able to see any information that users or applications want to keep private, including accounts, activity, balances, function execution, or other data of any kind.
Aztec’s Public Testnet is shipping with a full execution environment, including the ability to create client-side proofs in the browser. Here are some time estimations to expect for generating private, client-side proofs:
Aztec’s Public Testnet is designed to rigorously test decentralization across sequencing, proving, and governance ahead of our mainnet launch. The network design ensures no single entity can control or censor activity, empowering anyone to participate in sequencing transactions, generating proofs, and proposing governance changes.
Visit the Aztec Testnet page to start building with programmable privacy and join our community on Discord.
When Aztec mainnet launches, it will be the first fully private and decentralized L2 on Ethereum. Getting here was a long road: when Aztec started eight years ago, the initial plan was to build an onchain financial service called CreditMint for issuing corporate debt to mid-market enterprises – obviously a distant use case from how we understand Aztec today. When co-founders Zac Williamson, Joe Andrews, Tom Pocock, and Arnaud Schenk, got started, the world of zero-knowledge proving systems and applications weren’t even in their infancy: there was no PLONK, no Noir, no programmable privacy, and it wasn’t clear that demand for onchain privacy was even strong enough to necessitate a new blockchain network. The founders’ initial explorations through CreditMint led to what we know as Aztec today.
While putting corporate debt onchain might seem unglamorous (or just limited compared with how we now understand Aztec’s capabilities), it was useful, wildly popular, and necessary for the founding team to realized that no serious institution wanted to touch the blockchain without the same privacy assurances that they were accustomed to in the corporate world. Traditional finance is built around trusted intermediaries and middlemen, which of course introduces friction and bottlenecks progress – but offers more privacy assurances than what you see on public blockchains like Ethereum.
This takeaway led to a bigger understanding: the number of people (not just the number of institutions) who wanted to use the blockchain was limited by a lack of programmable privacy. Aztec was born out of the recognition that everyone – not only corporations – could use permissionless, onchain systems for private transactions, and this could become the default for all online payments. In the words of the CEO, Zac Williamson:
“If you had programmable digital money that had privacy guarantees around it, you could use that to create extremely fast permissionless payment channels for payments on the internet.”
Equipped with this understanding, Zac and Joe began to specialize. Zac, whose background is in particle physics, went deep on cryptography research and began exploring protocols that could be used to enable onchain privacy. Meanwhile, Joe worked on how to get user adoption for privacy tech, while Arnaud focused on getting the initial CreditMint platform live and recruiting early members of the team. In 2018, Aztec published a proof-of-concept transaction demonstrating the creation and transfer of private assets on Ethereum – using an early cryptographic protocol that predated modern proving schemes like PLONK. It was a limited example, with just DAI as the test-case (and it could only facilitate private assets, not private identities), but it garnered a lot of early interest from members of the Ethereum community.
The 2018 version of the Aztec Protocol had three key limitations: it wasn’t programmable, it only supported private data (rather than private data and user-level privacy), and it was expensive, from both a computation and gas perspective. The underlying proving scheme was, in the words of Zac, a “Frankenstein cryptography protocol using older primitives than zk-SNARKs.” These limitations motivated the development of PLONK in 2019, a SNARK-based proving system that is computationally inexpensive, and only requires one universal trusted setup.
A single universal trusted setup is desirable because it allows developers to utilize a common reference string for all of the programs they might want to instantiate in a circuit; the alternative is a much more cumbersome process of conducting a trusted setup ceremony for each cryptographic circuit. In other words, PLONK enabled programmable privacy for future versions of Aztec.
PLONK was a big breakthrough, not just for Aztec, but for the wider blockchain community. Today, PLONK has been implemented and extended by teams like zkSync, Polygon, Mina, and more. There is even an entire category of proving systems called PLONKish that all derive from the original 2019 paper. For Aztec specifically, PLONK was also instrumental in paving the way for zk.money and Aztec Connect, a private payment network and private DeFi rollup, which launched in 2021 and 2022 respectively.
The product needs of Aztec motivated the development of a modern-day proving system. PLONK proofs are computationally cheap to generate, leading not only to lower transaction costs and programmability for developers, but big steps forward for privacy and decentralization. PLONK made it simpler to generate client-side proofs on inexpensive hardware. In the words of Joe, “PLONK [was] developed to keep the middleman away.”
Between 2021 and 2023, the Aztec team operated zk.money and Aztec Connect. The products were not only vital in illustrating that there was a demand for onchain privacy solutions, but in demonstrating that it was possible to build performant and private networks leveraging PLONK. Joe remarked that they “wanted to test that we could build a viable payments network, where the user experience was on par with a public transaction. Privacy needed to be in the background.”
Aztec’s early products indicated that there was significant demand for private onchain payments and DeFi – at peak, the rollups had over $20 million in TVL. Both products fit into the vision Zac had to “make the blockchain real.” In his team’s eyes, blockchains are held back from mainstream adoption because you can’t bring consequential, real-world assets onchain without privacy.
Despite the demand for these networks, the team made the decision to sunset both zk.money and Aztec Connect after recognizing that they could not fully decentralize the networks without massive architectural changes. Zac and Joe don’t believe in “Progressive Decentralization” – the network needs to have no centralized operators from day one. And it wasn’t just the sequencer of these early Aztec products that were centralized – the team also recognized that it would have been impossible for other developers to write programs on Aztec that could compose with each other, because all programs operated on shared state. In 2023, zk.money and Aztec Connect were officially shut down.
In tandem, the team also began developing Noir (an original brainchild of Kevaundray Wedderbaum). Noir is a Rust-like programming language for writing zero-knowledge circuits that makes privacy technology accessible to mainstream developers. While Noir began as a way to make it easier for developers to write private programs without needing to know cryptography, the team soon realized that the demand for privacy didn’t just apply to applications on the Aztec stack, and that Noir could be a general-purpose DSL for any kind of application that needs to leverage privacy. In the same way that bringing consequential assets and activity onchain “makes the blockchain real,” bringing zero-knowledge technology to any application – onchain or offchain – makes privacy real. The team continued working on Noir, and it has developed into its own product stack today.
Aztec from 2017 to 2024 can be seen as a methodical journey toward building a fully private, programmable, and decentralized blockchain network. The earliest attempt at Aztec as a protocol introduced asset-level privacy, without addressing user-level privacy, or significant programmability. PLONK paved the way for user-level privacy and programmability, which yielded zk.money and Aztec Connect. Noir extended programmability even further, making it easy for developers to build applications in zero-knowledge. But zk.money and Aztec Connect were incomplete without a viable path to decentralization. So, the team decided to build a new network from scratch. Extending on their learnings from past networks, the foundations and findings from continuous R&D efforts of PLONK, and the growing developer community around Noir, they set the stage for Aztec mainnet.
The fact of the matter is that creating a network that is fully private and decentralized is hard. To have privacy, all data must be shielded cheaply inside of a SNARK. If you want to really embrace the idea of “making the blockchain real” then you should also be able to leverage outside authentication and identity solutions, like Apple ID – and you need to be able to put those technologies inside of a SNARK as well. The number of statements that need to be represented as provable circuits is massive. Then, all of these capabilities need to run inside of a network that is decentralized. The combination of mathematical, technological, and networking problems makes this very difficult to achieve
The technical architecture of Aztec reflects the learnings of the Aztec team. Zac describes Aztec mainnet as a “Russian nesting doll” of products that all add up to a private and decentralized network. Aztec today consists of:
At the network level, there will be many participants in the decentralization efforts of Aztec: provers, sequencers, and node operators. Joe views the infrastructure-level decentralization as a crucial first stage of Aztec’s mainnet launch.
As Aztec goes live, the vision extends beyond private transactions to enabling entirely new categories of applications. The team envisions use cases ranging from consumer lending based on private credit scores to games leveraging information asymmetry, to social applications that preserve user privacy. The next phase will focus on building a robust ecosystem of developers and the next generation of applications on Ethereum using Noir, the universal language of privacy.
Aztec mainnet marks the emergence of applications that weren't possible before – applications that combine the transparency and programmability of blockchain with the privacy necessary for real-world adoption.
From the early days of blockchain, great minds and stakeholders have been concerned about on-chain privacy. The reason is simple: no matter how excited we are about DeFi, on-chain identity, or any other area, it just doesn’t make sense to store all personal data on-chain. Doing so would make it accessible to anyone, anywhere, at any time.
However, to convert a system that is designed to be transparent into a private one is a tricky task. It’s even harder if the goal is to provide dApps with “privacy as a feature” (i.e. privacy should be optional and flexible) not something that changes a transparent system into a fully private one.
In this article, we’ll talk about one of the core components unlocking privacy on Ethereum: state management. We’ll shed some light on programmable and composable privacy which allows dApp developers to choose what they want to make private and what to leave public. That allows for an ecosystem of privacy-preserving dApps that can communicate with each other as well as Ethereum.
Building programmable and composable privacy on Ethereum is Aztec’s core mission. There are two critical pieces needed to make this happen:
In this piece, we will explore how different state modes enable this functionality, and explain how state management works on the Aztec Network.
For state management, Ethereum utilizes an account-based model. Whatever data needs to be stored, it takes the form of “key: value,” where “key” is derived from the account address, and “value” can be, for example, the account’s balance.
Here is a database showing some sample keys and associated values:
When a new transaction is executed, account balances are adjusted. For example, if Alice sends Bob $10, the new state will be the following:
This is the core property of the account-based model: account states are adjusted with each transaction.
But, what if we want a transaction—for example, a transfer—to be private? Can we simply encrypt all entries in the database to create privacy?
The answer is no, we can’t.
It leaks privacy.
If we execute a transaction on encrypted entries, people can still see which entries were modified: that constitutes a leak in privacy. If two transactions engage the same account one by one, it’s clear that this particular account state was modified.
By retrospectively analyzing account activity and the connections between them, one can retrieve tons of information. This means the account-based model doesn’t qualify for privacy needs.
UTXO stands for unspent transaction output. In the UTXO model, the account state is represented as a record of unspent assets.
Unlike in the account-based model, in the UTXO model, account states cannot be modified. Instead, the model operates in an append-only manner. Whenever someone needs to update an account state—for example, the balance—they have to destroy some existing notes and create some new notes.
Going back to our previous example, Alice transfers $10 to Bob.
The updated database is:
*In the example above, “crossed-out” indicates destroyed entries.
So using UTXO, if we want a transaction to remain private, we can encrypt all the entries without causing a privacy leak:
When one entry is destroyed and a new entry is created, observers can’t determine if these entries refer to the same account or to different accounts. No additional information can be gleaned by analyzing accounts’ activity.
And that’s exactly what we need.
Aztec utilizes the UTXO model for private state management and the account-based model for public state management. Public state is universal (i.e. one for the whole network and available for anyone) while private state is individual to every user.
A smart contract on Aztec consists of both private and public functions. When a smart contract is executed, the first thing that happens is all private functions are executed client-side and the user's private state is updated. After that, all public functions are executed and the transaction execution is reflected in the public state update.
As we discussed earlier, for the sake of privacy, private state operates in the append-only mode. At the same time, modifying an entry in the UTXO model means “destroying” the existing entry (or multiple entries) and creating new entries reflecting the transaction. (In our example, a note with a transfer to the receiver and Alice’s updated balance).
How can the note be destroyed in an append-only mode? Using nullifiers.
A nullifier is a commitment corresponding to a private entry that was destroyed. Only the note owner is aware of the correspondence between notes and nullifiers. For everyone else, it’s impossible to define which nullifier was created for which note.
Every note can be consumed only once. When a new transaction emits a nullifier the sequencer has to check that this nullifier hasn’t existed before (to prevent double-spend).
Let’s circle back to our example: Alice has $100 and she is sending Bob $10.
Let’s think of another example. Alice has two notes, $50 and $60, and she wants to transfer $100 to Bob. For this transaction, she has to destroy both notes, emit a note for Bob with a value of $100, and emit a note for herself updating her remaining balance of $10. That is to say that an arbitrary amount of notes can be consumed per transaction.
More generally, any state (i.e. not just balances) can be represented with notes. For example, if someone keeps a counter that they increase every time they send a transaction, they can store the value of the counter in a note. Every time they send a new transaction, they nullify the existing counter note and create a new one with the updated value.
Although notes and nullifiers are emitted client-side, it’s the sequencer who grabs the notes’ hashes and nullifiers (as commitments) and adds them to the databases (i.e. updates the state). That is to say, a client is always running its private execution environment in an “old” state.
However, what if someone picks an old state root that satisfies some logic that the current state root would not satisfy?
Circling back to our second example, imagine someone has a note where they keep an increasing counter. The counter owner is allowed to do something only if that counter is less than 10. So they can always pick a state root where the counter was less than 10 (even if it was 10 years ago) and just run their transaction over that state.
To mitigate this issue, the note must be nullified even if it was only read without spending it. This introduces the nullify-on-read concept that whenever someone reads a private note and performs some action on it (e.g. reading a note grants permission to make a call), they must nullify it and recreate it with the same value. Which means the content of each unique note can be read only once.
In this article, we’ve explored the core concepts behind Aztec’s state management mechanism, which allows builders to get programmable and composable privacy. Now, it’s your turn!
Ready to put your hands on on-chain privacy and kick off the next big thing for Ethereum? – this is your next step.
Stay updated on all things Noir and Aztec by following Noir and Aztec on X, and join the Aztec developer community on Discord.
We are constantly striving to make the Aztec Network more secure by developing internal tooling and seeking external expertise.
To prepare for a barrage of future audits before the mainnet launch, we ran a test exercise with three well-established auditing companies including ZKSecurity, Zellic, and Spearbit.
These three partners performed an audit of the same piece of code. The goal was to check the quality of the audits and establish a working relationship with the teams.
We chose to check out a circuit standard library primitive called Bigfield for a few reasons:
We are happy to announce the completion of all the audits and thank all companies for the collaboration and showing great expertise. The reports can be found here, and you can view a table with comparison issues (with low severity or higher) here.
Stay updated on all things Noir and Aztec by following Noir and Aztec on X, and join the Aztec developer community on Discord.
Since Aztec's launch seven years ago, we’ve been on a mission to solve one of the biggest barriers to mass blockchain adoption – privacy.
The journey towards building a fully decentralized, privacy-preserving network is a massive undertaking. From the beginning, we’ve been committed to building in the open and involving our community in major decisions through discussions, grants, and ongoing builder competitions.
Our team and community have worked tirelessly to bring this vision to life, and their efforts have paid off. In August of this year, we delivered the first major milestone towards our vision by unveiling a live Aztec Devnet. Many puzzle pieces came together to reach this stage, including developing a novel proving system (Honk), creating an intuitive zk programming language (Noir), and building a private execution environment (PXE) to generate private, client-side proofs.
Together, these components unlock one of the most powerful missing pieces for protecting user data on blockchains: client-side zk proof generation. Developers don’t need to struggle to implement these privacy features - they can simply specify which functions will run privately and which will run publicly.
But privacy is only half of the story. We are committed to decentralizing every aspect of the network, from sequencers and provers all the way to settlement on Ethereum. In September, we launched an early Provernet, a decentralized network of provers generating zk proofs for Aztec transactions. We were amazed by the passion of the participants to generate efficient proofs and contribute towards a decentralized future for the network.
Now imagine a world where both of these elements, privacy and decentralization, are seamlessly brought together. Where developers can write programs that protect user data but take full advantage of a trustless, permissionless system – all backed by the security of Ethereum.
This is what we’re working towards, and this product roadmap is how we get there.
Join us Thursday, October 10th at 9 a.m. PST on X to hear more about our road to mainnet from our Co-Founders, Zac Williamson and Joe Andrews. Stay updated on all things Noir and Aztec by following Noir and Aztec on X, and join the Aztec developer community on Discord.
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.
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
The proof generation for a privacy-preserving zk-rollup differs a lot from that of a general-purpose zk-rollup. The reason for this is that there is specific data in a given transaction (processed by private functions) that we want to stay completely private. In this article, we explore the client-side proof generation used for proving private functions’ correct execution and explain how it differs from proof generation in general-purpose rollups.
Contents
Disclaimer: If you’re closely familiar with how zk-rollups work, feel free to skip this section.
Before we dive into proofs on Aztec, specifically the privacy-first nature of Aztec’s zk-rollup, let’s recap how proofs work on general-purpose zk-rollups.
When a stateful blockchain executes transactions, it conducts a state transition. If the state of the network was originally A, then a set of transactions (a block) is executed on the network, the state of the network is now B.
Rollups are stateful blockchains as well. They use proofs to ensure that the state transition was executed correctly. The proof is generated and verified for every block. All proofs are posted on L1, and anyone can re-verify them to ensure that the state transition was done correctly.
For a general-purpose zk-rollup, proof generation is very straightforward, as all data is public. Both the sequencer and the prover see all the transaction data, public states are public, and the data necessary to reconstruct each state transition is posted on L1.
Aztec’s zk-rollups are a different story. As we mentioned in the previous article, in the Aztec network, there are two types of state: public and private.
Aztec smart contracts (written in Noir) are composed of two types of functions: private and public.
For both of these, we need proof of correct execution. However, as the anatomy of private and public functions is pretty different, their proof generation is pretty different too.
As a brief overview of how Aztec smart contracts are executed: first, all private functions are executed and then all public functions are executed.
However, diving into the anatomy of Aztec smart contracts is outside the scope of this piece. To learn more about it, check the previous article.
Here, we will focus on the correct proof generation execution of private functions and why it is a crucial element of a privacy-first zk-rollup.
The concepts of private state and private functions in blockchain might seem a little unusual. The following map describes the path of this article, where we will shed some light on the difference between how proofs work for private and public states respectively.
Let’s start by looking at public function execution, as it is more similar to other general-purpose zk-rollups.
Public state is the global state available to everyone. The sequencer executes public functions, while the prover generates the correct execution proof. In particular, the last step means that the function (written in Noir) is compiled in a specific type of program representation, which is then evaluated by a virtual machine (VM) circuit. Evaluated means that it will execute the set of instructions one by one, resulting in either a proof of correct execution or failure. The rollup-side prover can handle heavy computation as it is run on powerful hardware (i.e. not a smartphone or a computer browser as in the client-side case).
Private state on the other hand is owned by users. When generating proof of a private transaction's correct execution, we want all data to stay private. It means we can’t have a third-party prover (as in the case of public state) because data would be subsequently exposed to the prover and thus no longer be private.
In the case of a private transaction, the transaction owner (the only one who is aware of the transaction data) should generate the proof on their own. That is, the proof of a private transaction's correct execution has to be generated client-side.
That means that every Aztec network user should be able to generate a proof on their smartphone or laptop browser. Furthermore, as an Aztec smart contract might be composed of a number of private functions, every Aztec network user should be able to generate a number of proofs (one proof for each private function).
On the rollup side, block proofs are generated using ZK-VM (ZK virtual machine). On the private side, there is no VM.
Instead, each private function is compiled into a static circuit on its own.
When we say “a circuit”, we’re referring to a table with some precomputed values filled in. This table describes the sequence of instructions (like MUL and ADD) to be executed during a particular run of the code.
There are a bunch of predefined relations between the rows and columns of the table, for example, copy constraints that state that the values of a number of wires are expected to be the same.
Let’s take a look at a quick example:
In the diagram above, we have two gates, Gate 1 (+) and Gate 2 (x). As we can see, z is both the output of Gate 1 (denoted as w3, wire 3) and the left input to Gate 2 (denoted as w4, wire 4). So, we need to ensure that the value of the output of Gate 1 is the same as the value of the left input of Gate 2. That is, that w3 = w4. That’s exactly what we call “checking copy constraints”.
When we say that the verifier verifies the circuit, we mean it checks that these predefined relations hold for all rows and columns.
Disclaimer: the following example reflects the general logic in a simplified way. The real functions are much more complex.
Assume we have a function a2+b2=c2. The goal is to prove that equality holds for specific inputs and outputs. Assume a = 3, b = 4, c = 5.
As a piece of code, we can represent the function as the following:
When the function is executed, the result of each step is written down in a table. When this table is filled with the results of the specific function execution on specific values, it’s called an execution trace.
This is just a fragment of the table, with values and opcode names. However, to instruct the computer about which operation should be executed in which specific row, the opcode name is not enough; we need selectors.
Selectors are gates that refer to toggling operations (like an on/off switch). In our example, we will use a simplified Plonk equation with two selectors: qADD for the addition gate and qMUL for the multiplication gate. The simplified Plonk equation is: qMUL(a*b)+qADD(a+b)-c=0.
Turning them on and off, that is, assigning values 1 and 0, the equation will transform into different operations. For example, to perform the addition of a and b, we put qADD= 1, qMUL=0, so the equation is a+b-c =0.
So, for each performed operation, we also store in the table its selectors:
In the case of private functions, as each function is compiled into a static circuit, all the required selectors are put into the table in advance. In particular, when the smart contract function is compiled, it outputs a verification key containing a set of selectors.
In the case of a smart contract, the circuit is orders of magnitude larger as it contains more columns with selectors for public function execution. Furthermore, there are more relation checks to be done. For example, one needs to check that the smart contract bytecode really does what it is expected to do (that is, that the turned selectors are turned according to the provided bytecode commitment).
As a mental model, you can think about a smart contract circuit as a table where 50 out of 70 columns are reserved for the selectors' lookup table. Storing the entire table requires a lot of memory.
Now you see the difference between circuit size for client-side and rollup-side proof generation: on the client-side, circuits are much smaller with lower memory and compute requirements. This is one of the key reasons why the proofs of private functions' correct execution can be generated on users’ devices.
Client-side proof generation is a pretty novel approach for the blockchain domain. However, for privacy-preserving solutions, it is an absolute must-have. Aztec Labs has spent years developing the protocol and cryptography architecture that make client-side proof generation performance feasible for the production stage.
You can help build it further.
Today we are thrilled to announce that Aztec Network has raised $17 million in Series A financing to bring programmable privacy to Web3.
The round was led by Paradigm with support from existing partners a_capital, Ethereal Ventures, and Libertus Capital, and participation from Variant Fund, Nascent, IMToken, Scalar Capital, Defi Alliance, IOSG Ventures, and ZK Validator, along with leading angels including Anthony Sassano, Stani Kulechov, Bankless, Defi Dad, Mariano Conti, and Vitalik Buterin.
“Privacy is a fundamental right. Aztec’s rollup, powered by their pioneering academic research on Plonk, is solving for high privacy while also allowing access to Ethereum’s DeFi. We’re incredibly pleased to partner with them and help advance this work.”
- Georgios Konstantopoulos, Research Partner and Chief Technology Officer, Paradigm
At Aztec we believe decentralization is premised on individual rights. Without widely accessible privacy, we compromise our ability to choose how we live our lives and earn our livelihoods.
That’s why we’re building Aztec Network to deliver privacy without compromise:
“When we started Aztec, the technology to scale blockchains privately didn’t exist. Since then, we’ve assembled a team of world-class cryptographers who continuously redefine the state-of-the-art. Inventing PLONK — the paradigm-defining universal zk-SNARK — showcases our ability to produce technology that matches our ambitions: unlocking an entire universe of blockchain applications that couldn’t exist without privacy.”
- Zac Williamson, CEO and Cofounder, Aztec
Our first product was zk.money, a private transfer protocol built on Aztec. Since launch, zk.money has had over 20,000 registered users, 50,000 transactions, and $35 million in total deposits, all while being 96% cheaper than existing private transfer protocols.
We are now excited to announce Aztec Connect, the first private bridge for Ethereum’s decentralized finance ecosystem. It allows users to confidentially access world-class DeFi services on Ethereum with up to 100x cost savings, all while strengthening Aztec’s existing privacy guarantees.
At launch, Aztec Connect extends the capabilities of zk.money, adding functionality from blue-chip DeFi partners. Soon thereafter, the Connect SDK will allow any Ethereum project to permissionlessly integrate Aztec, unlocking instant privacy and cost-savings.
“We are excited to bring Element’s fixed rates to L2 by integrating with Aztec’s zk-rollup technology. Users will benefit from the same privacy they have come to expect from zk.money with the option to earn fixed rates on their shielded balances, all while saving up to 80–90% in gas fees over L1.”
- Jonny Rhea, CTO and Cofounder, Element Finance
Aztec Connect accomplishes the above while maintaining two significant advantages over other scaling solutions:
“Privacy needs an active financial market to be useful. Aztec Connect was designed with this in mind — its goal is to deliver value to users of existing DeFi protocols by adding iron-clad privacy guarantees and reducing transaction costs.”
- Joe Andrews, Head of Product and Cofounder, Aztec
Proceeds from the Series A will be used for network decentralization, Aztec Connect Grants, and continued development of our class-leading zero knowledge proving systems.
We are grateful for the community of users and developers supporting Aztec’s mission to build the programmable privacy layer for Ethereum and Web3.
To join our community or develop on Aztec Connect, please follow us on Twitter, find us on Discord, and check out the Aztec Connect Starter on Github.
We are always looking for talented and passionate contributors to Aztec. If you’re interested in joining our mission, browse our full time roles here.
Aztec Network is the first private ZK-rollup on Ethereum, enabling decentralized applications to access privacy and scale. Aztec’s rollup is secured by its industry-standard PLONK proving mechanism used by the leading zero-knowledge scaling projects.
For press inquiries please reach out to jon@aztecprotocol.com.
A full media kit can be found here.
How do you benchmark SNARKs?
It’s a problem because different SNARKs will perform differently on various circuits — it’s not a matter of ‘PLONK is 5x faster than Sonic every time’.
Well, a critical measure is how efficiently a SNARK can verify a hash operation. But why are hashes important? This article describes how zero-knowledge assets are stored in the Two-Tree Model, and therefore why fast hashes in SNARKs are mission-critical.
Before explaining how the Two-Tree Model works, here’s a reminder of what a Merkle tree actually is.
Remember, the purpose of a Merkle Tree is to generate a single short digest (hash) of many pieces of data, so that if asked, one can prove that any one piece of data is ‘guaranteed’ by that hash without revealing all the other pieces of data.
In the diagram below, data pieces A, B, C and D are separately hashed. Next, each pair is hashed together (turning 4 hashes into two hashes). Finally, those two hashes are hashed to form the ‘Merkle Root’.
The Merkle Root changes if and only if a single piece of data changes (i.e. if A, B, C or D are modified / edited). Here’s the picture to have in mind:
We introduce the classical model for storing ZK Assets.
This system is built around a UTXO model like Bitcoin — i.e. each asset is recorded via so-called ‘notes’ of ownership. An asset with $1,000 total global supply is held in the form of one-or-more notes by each owner.
Alice may hold $10 of this asset in (say) three notes: $7, $2 and $1. Transferring ownership involves a ‘join split’ transaction which takes input notes (e.g. say the $7 and $2 notes above), and printing new output notes (say $8 and $1).
Instead of creating output notes and destroying input notes, we instead record this process in two trees —
The idea is — instead of deleting a note from the Note Tree, you need to check whether that note also turns up in the Nullifier Tree to work out if it’s already spent. If it’s not there, it’s still spendable.
A join-split transaction adds the output notes to the Note Tree, and the input notes to the Nullifier Tree.
Let’s take a closer look at these structures.
Locations in Tree = ~2³⁰ leaves (dense Merkle Tree)
The first tree — the Note Tree — determines the current state of all data inside the system — smart contracts, registers of ownership of assets — everything. For now, let’s focus just on recording the ownership of assets through notes.
Suppose Alice sends Bob 50 zkDai and the Note Tree has slots 1, 2, … n filled up. Then the following is added to the Note Tree:
Encrypt (
{
owner: [Bob's Address], asset: 0x40a5a9872e73de550516d8ec43c6990f8247441d, amount: 50
}
)Locations in Tree = ~2²⁵⁶ leaves (sparse Merkle Tree)
The second tree — the Nullifier Tree — determines which notes have been spent — we add the following to the Nullifier Tree to mark Alice’s Input Note of 50 zkDai as spent.
Hash (
{
owner: [Alice's Address], asset: 0x40a5a9872e73de550516d8ec43c6990f8247441d, amount: 50
}
)
The ‘random’ nature of the Hash means the note in the nullifier set can’t be traced to the newly-added note in the Note Tree.
The two-tree diagram above is actually slightly misleading in one respect — it shows the spent note being added to position 3 (out of 4) in the Nullifier Tree, at the same location it was originally created in the Note Tree.
However, these two trees have significantly different structures.
The Note Tree is actually encoded as a ‘dense’ Merkle Tree — that is, a tree designed to hold ~2³⁰ notes, and therefore requiring 30 hashes to add a note. You add the notes in the order in which they are created over the lifetime of the asset— first note at position 1, second note at position 2, etc. This tree is ‘dense’ because leaves are all created as immediate next-door neighbours.
The Nullifier Tree, however, looks very different — addresses, instead of running in order, are determined by the hash of the nullifier note data (detailed above). This of of course means that the Nullifier Tree is a sparse Merkle tree — that is, a tree with 2²⁵⁶ theoretically-available leaves — each containing the number 0. The note is added at the address determined by that hash — that’s right, the note hash’s value *also* doubles as its location in the tree. In other words, the Nullifier Note is placed into the Nullifier Tree amid a wilderness of zeros.
Notice that this means that the position of a note in the Nullifier Tree (i.e. being marked as spent) is ≠ the position in the Note Tree.
There are two excellent reasons for this:
Observation: Even though the Nullifier Tree has 2²⁵⁶ locations, and therefore 256 hashes between a leaf and the Merkle Root, most of the locations always hold the default value 0 (i.e. most locations are unused). This allows us to get the number of hashes needing verification nearer to 30, rather than 256.
The following computation is indicative only — AZTEC is actually going to use more SNARK-friendly hashes e.g. Pedersen commitments.
But to complete the exercise:
Each SHA-256 hash in PLONK requires ~27,000 gates for a 64 byte input, so 60 hashes consume ~1.6m gates. The actual smart-contract logic can often be run in a handful of gates — sometimes 10s, 100s, or 1,000s of gates depending on the smart contract in question.
That leaves hashing algorithms dominating > 99% of the computation. And that is why benchmarking SNARKs on hashing algorithms is the crucial barometer of speed.
We’re on the lookout for talented engineers and applied cryptographers. If joining our mission to bring scalable privacy to Ethereum excites you — get in touch with us at hello@aztecprotocol.com.
