Aztec Labs chief executive officer Zac Williamson explains why bringing privacy to Ethereum is more than a technical upgrade but a necessity.
Zac Williamson is the co-founder and CEO of Aztec Labs, a layer-2 network focused on bringing privacy to Ethereum (ETH). Before crypto, he earned a PhD in particle physics from Oxford and worked at CERN. In the blockchain world, he’s best known as a co-inventor of PLONK, one of the most widely used zero-knowledge proof systems today.
In a recent conversation with crypto.news, Zac explains why privacy isn’t just a nice-to-have but a core part of what Ethereum needs to grow. He talks about what legitimate privacy in blockchain really means, how privacy pools can offer both privacy and compliance, and why private layer-2s could make it easier to bring real-world assets on-chain.
CN: How do you define privacy in a blockchain context? Is it about anonymity, selective disclosure, or something else entirely?
When I talk about privacy in blockchain, I break it down into three core pillars.
First, there’s user privacy, which means hiding the identities of both the sender and the receiver. Then you have data privacy, which is about keeping transaction amounts confidential. And finally, there’s code privacy, where even the logic being executed on-chain is hidden.
To me, achieving all three is the holy grail of blockchain privacy. That’s the level we should be aiming for if we’re serious about building truly private systems.
And I guess, more generally, privacy in a blockchain context is the ability to leverage information asymmetries on-chain. As in, I can perform a transaction where I know something you don’t know. And this is foundationally important for a lot of basic types of interactions in our daily lives.
For example, when you vote in elections, that’s an information asymmetry. I know how I voted, you don’t know how I voted.
CN: What are the biggest misconceptions about privacy in crypto that you wish the broader ecosystem understood better?
ZW: The biggest misconceptions about privacy and crypto, I think, are that:
a) It’s just about tokens and private token transfers, and;
b) It’s currently viewed as this completely separate sphere from the rest of crypto, like you have DeFi, NFTs, and then privacy, etc.
Well, both of these are wrong, and they’re a function of the technological immaturity of privacy solutions so far. Privacy is not a separate little sphere of crypto, and I think that in the future, all crypto will be private.
If we want crypto to break out of its bubble and interact with the real world systems and more than just technological early adopters, or even compete on a level playing field with web2 and TradFi, we need to provide the same kind of privacy benefits that users normally expect.
With the technology we’re trying to build at Aztec and others in the ecosystem, we have this concept of composable privacy, where just like in an Ethereum smart contract, you get to define the rules and the logic around how you like your transactions.
You can code up your own digital assets, but unlike in transparent blockchains, you have private data as a first class primitive. You can hide who the message and recipients are. You can perform compliance checks on people that require knowledge of sensitive information and ensure that information stays encrypted and nobody sees it, things like that.
CN: Do you think there’s a moral imperative for public blockchains to offer private options, especially in authoritarian contexts? If so, how should the Ethereum community define “legitimate privacy”?
ZW: Well, the main thing about blockchains, one of its core values, is that they’re neutral and permissionless. Anybody can transact on a blockchain and code up their own digital assets. And so, I don’t think it’s really my place to determine what is and isn’t a moral imperative on a blockchain.
There’s a space for both public and private blockchains. However, private blockchains are going to be more valuable and useful. But it’s important to define legitimate privacy, and I think it’s actually quite simple.
As a user, I should have confidence that I’m not enabling bad actors, and because of my participation, I’m not making life easier for criminals and bad actors to use the network for nefarious acts.
To give an example, when you use Tornado Cash, you’re helping bad actors, because you’re increasing the size of the anonymity set that the bad actors can hide in. If you’re using privacy pools, you’re not.
CN: And how does censorship resistance fit into this context?
ZW: The network itself should be censorship-resistant. No one should be able to censor transactions at the protocol level. However, if I’m programming a smart contract on that network, I should have the freedom to define what constitutes a legitimate transaction within that contract.
Privacy is a fundamental human right, and I believe people should have the ability to present themselves privately on-chain. That said, I don’t believe users are entitled to interact with any application however they choose, especially if their actions go against the intentions of the developers or the rules coded into the smart contract.
CN: What’s your take on the Privacy Pools model, which has enjoyed support from Vitalik Buterin, as a middle ground between full anonymity and full transparency?
ZW: I think Privacy Pools is a good first step — one of many. When it was being developed, it had to work within really fierce technological constraints. The idea was, how do we create private transaction tech that can work on Ethereum today? And that means the ZK tech they’re using is relatively primitive, which limits what you can do with it. So yeah, I think it’s a good starting point, but definitely not the end goal.
What we’re chasing at Aztec is full programmability. I’ll give an example of what I mean. There’s a company in our ecosystem called ZKPassport. Basically, modern phones have NFC scanners, and modern passports have NFC chips that can sign digital signatures.
ZKPassport built an app where you can tap your passport to your phone and get a ZKP that shows you have a valid passport. You can choose what information you want to disclose — your nationality, your date of birth, your name, whatever you decide.
You could use that tech for, say, a DeFi application that only citizens of a certain country can access. Instead of someone manually checking passports, the proof happens automatically with digital signatures and ZKPs. It’s permissionless, it’s privacy-preserving, and it ensures strong compliance.
Honestly, that’s a lot more powerful in many ways than what Privacy Pools currently offer. And once you have full programmability in privacy networks, you can build an almost infinite variety of things on top of it.
CN: Are there any design patterns or UX breakthroughs you think will be key to mainstreaming private transactions?
ZW: Yeah, totally. PLONK is one of the enabling design patterns for UX breakthroughs, I guess. But there are a lot of breakthroughs needed to make private transactions mainstream. The complexity of a private transaction is way higher than a transparent one, because you can’t just broadcast sensitive information to the blockchain. You have to construct everything privately on the client side.
And so the real question becomes: who pays for that complexity? Right now, in 2025, the answer is — the application developer pays, and the user pays. The app developer has a much harder time creating a usable application, and the user is going to have a harder time too. They’ll have to wait longer for proofs to be constructed, and the apps they use might struggle to integrate with the wider web3 ecosystem because they’re operating under different privacy standards.
Within Aztec, my general operating principle has been: okay, complexity in private transactions is much higher — who pays? And my answer is: the cryptography researchers pay, by creating better ZK tech. That’s what we did back in 2019 when we created the first practical universal ZK-SNARK. Since then, it’s been iterated on a lot. The version of PLONK we’re using today is about 250 times faster than what we had in 2019. That allows much more performant applications.
Then, you have language designers and tooling engineers. Their job is to create a programming language that can efficiently turn programs into zero-knowledge proofs — a language where writing private smart contracts is intuitive and simple. That’s what we’ve been doing with Noir, our programming language. It lets you build efficient private apps without needing to be a cryptographer.
Finally, the protocol engineers and blockchain designers have to handle complexity by building chains that have private state semantics baked in from the start, meaning the blockchain understands what’s public, what’s private, that a transaction sender can be anonymous, and so on. That takes an enormous amount of work.
And beyond all that, you need a massive amount of tooling so that developers can build compelling private applications without having to understand deep, sophisticated cryptography. We’re about to launch our testnets, and we’re very confident that the complexity of developing compelling private apps has dropped by orders of magnitude because of what we’ve built.
CN: Do you believe Ethereum should be a fully private base layer eventually, or is privacy better served at the edges with apps or layer-2s like Aztec?
ZW: Privacy comes with a lot more complexity, and I think it’s appropriate for that to be handled by L2s or specialized L1s. It comes with trade-offs. If Ethereum had been private by default, it probably wouldn’t have launched yet. It would be harder to develop, and there would be more security risks.
I do think L1s are going to incorporate more and more privacy tech over time. Building composable privacy requires re-architecting the blockchain model from the ground up. For existing L1s, I think that’s too much of an ask, because it would inevitably break backwards compatibility with their current ecosystems. So yeah, for now at least, I think privacy should very much stay in the domain of L2s and the apps built on top.
CN: Are ZKPs alone enough for privacy, or do we also need network-layer protections like mixnets or private mempools?
ZW: Yeah, we need all of it. We need good infrastructure, we need private mempools. The whole point is to have an end-to-end encrypted blockchain. If I’m doing a very sensitive transaction, like something significant in the real world, nobody should be able to see what I’m doing, apart from whatever app I’m interacting with.
The only entities that should know what I’m doing are the ones needed for the app to function. For example, if I’m paying my mortgage, there shouldn’t be anyone snooping on that. If I’m interacting with a DAO and I live in a country where that kind of work might be disapproved of, I should still be able to do that safely.
I think privacy is a human right, and to really fulfill that, it’s not just blockchain-level privacy. We need full network-layer protections too.
CN: Is the fragmentation of ZK tooling (PLONK, STARKs, SNARKs) a strength or a bottleneck for ecosystem maturity?
Very much a strength. Right now, ZK tech is still in its relatively early stage. There’s a lot of diversity in technologies and proving systems because it’s not clear yet what’s going to be the best long-term solution. Research is evolving every six months in this space.
Every technology solution comes with trade-offs. Some trade-offs will be appropriate for certain applications and not for others. What we need is experimentation. We need a diversity of ideas where multiple pathways are tried out, tested, and either succeed or are destroyed.
I’ll give a minor example of how early standardization can kill a network: France’s Minitel. France basically had a version of the internet decades before anyone else, in the 1980s, because the French government built a proto-information network.
People could access things like train tickets, university exam results — all kinds of services. But they chose terrible architecture. It was highly centralized. Unlike today’s internet, where anyone can build a website, with Minitel you had to petition the government to run an app.
So they were ahead of the curve for a few years, but then they stagnated massively because they standardized on the wrong architecture. Right now, it’s way too early to standardize on anything in ZK. We need far more experimentation and research to figure out what’s really going to stand the test of time.
CN: So, another emerging privacy technology is fully homomorphic encryption. Where are we currently with FHE? Do you see a possibility of having the first fully fledged FHE applications in the market soon?
ZN: It’s extremely valuable, but it needs a few more years in the oven. I’d suggest you listen to people who are experts in FHE and don’t stand to benefit financially from the FHE hype to get a better understanding. It’s too early!
The amount of computation overhead you need to do things in FHE is just so heavy. Which means that, yes, I think it will be good for production soon, but only for extremely limited use cases. I think the state of FHE today is very similar to the state of ZK in 2010.
