Vitalik Buterin’s talk on Ethereum Privacy @ W3PN HACKS, Berlin [June 2025]

Topic for today will be first getting serious about privacy.

We'll talk first a little bit about Ethereum, the approach that I've been thinking about in terms of how Ethereum can move forward on privacy, what kinds of things we should do, in what order, what kinds of things we should do that we have not been thinking about before so far, what kinds of things we should not do.

What we've seen so far is that Ethereum has led the way on privacy research and development in a lot of different ways. Zcash, of course, was the first major production implementation of on-chain privacy. Systems on Ethereum were probably either the second or close to the second. So back in 2019, we had the ECMUL and ECADD and ECPAIRING opcodes that enabled all kinds of on-chain privacy solutions to start happening.

Then we saw Tornado Cash launched on Ethereum. It was the chain where the entire arc of that very complicated story happened. By the way, free Roman Storm. Roman Storm continues to need help.

Then PSE - the Privacy & Scaling Explorations in the Ethereum Foundation. They have worked on many kinds of ZkSNARK protocols, a lot of low-level protocol-related research, dev tooling-related & implementation-level work. PSE has been a bedrock of a lot of very bottom-level tooling and ideas on zero-knowledge proofs for scaling and zero-knowledge proofs for privacy.

L2s have contributed a lot. Aztec, in addition to releasing already multiple test versions, I believe Mainnet coming soon, has also been experimenting with a lot of very innovative ideas regarding privacy, but also lower-level things like the Noir language, the entire Plonk and plookup category of algorithms.

Intmax, fully ZkSNARK-based plasma rollup hybrid. Nightfall from EY, championed by Paul Brody quite a bit. Ethereum has been a home for a huge amount of valuable privacy-related work. But the problem is that on real-world value delivered to users, we are far behind where we could be. So, if you're actually using a privacy protocol on Ethereum today, shout them out.

A lot of things are starting to happen, but what does using a privacy protocol today look like? My experience is, one, it requires you to have a separate seed phrase. You have this totally separate thing that you have to worry about holding and not losing and not having stolen if you want to use your assets. That's one.

Two is there is no multi-sig option. The only option is a single key option, which is pretty scary for large amounts of funds.

Three, it requires opening a separate wallet. So whenever you want to do a private send, you have to go and open the thing and then slowly starts loading. It goes from zero to 100. You have to wait 30 seconds.

Four, you need a total of about five clicks to private send and withdraw.

When I use Railway, I count, click one, open the railway wallet, and then click two, you have to click on unshield, which is a different thing than send, the thing that I think of as sending is actually unshielding, sometimes I click send and then I realise that's the wrong thing and I have to do a third click of clicking unshield. Two, click on Shield. Then three, click on Generate Proof. Then you wait. Then four, click on choosing a public broadcaster. And then when the proof is done, it's usually a fifth click to actually start the whole process.

It's a much more complicated gist on a raw UX level than it could be. And also the public broadcaster mechanism, this is something common to Tornado Cash and Railway and anyone of these systems that tries to actually be decentralised.

These things are brittle, these things often break, these things within the last six months I've had situations where it just broke completely on one version and I had to switch versions at some point. Broke completely on one internet connection. I had to either turn a VPN on or turn a VPN off.

So very far from perfect and we can do better.

Why now?

Why do we want to really push for privacy now as opposed to pushing for privacy in, say, either 2021 or 2029? First of all, at the top of all this, privacy is important, right?

Privacy is freedom, privacy is order, privacy is progress, privacy is a bedrock of a lot of things that we care about in this world.

Privacy is not just an abstraction in the same way that something like decentralisation or credible neutrality is. Privacy is a concrete benefit that is directly appealing to users. You can understand what it means to transact privately. Transacting privately as opposed to transacting publicly is something that actually has meaningful differences in the kind of experience you will have during the transaction, but more importantly, after the transaction.

Freedom of speech is easy. Freedom after speech is the harder thing. Also, the technology is mature enough today. This was not true four years ago. Today, we can do it, and therefore, we must.

The way that I think about "privacy on Ethereum is", I break it up into three categories.

First, privacy of writes on-chain. Basically when you perform operations and things like sending, those operations happen on-chain. By default, everything you do on-chain creates a public link between every operation and every other operation. How do we do with these things without creating the on-chain public link?

Then number two, privacy of writes off-chain. So in this case, how do you avoid leaking information when you're sending transactions, like basically all the parts other than the blockchain itself?

And number three, privacy of reads, right? When you read the chain, the chain reveals a lot of things about who you are and what you're doing. And how do we actually try to minimise that?

So let's start with privacy of writes.

Three categories that we can focus on short term. One is funds transfers, two is DeFi, three is voting. These are basic category of operations and there are strong cases to have privacy for each of these.

Private funds transfers. We all know about them. Private DeFi, so Railway, for example, has private DeFi inside of it. Adding privacy to DeFi has value in a lot of different ways. So it's valuable for people not to know what your investments are, what your strategies are. It's valuable for people to not know what your liquidation price is. It's valuable for people to not know everything you're doing in real time so that they can front run you. There's all kinds of reasons why it's important to be private in DeFi in order to protect you.

Having private DeFi increases the amount of funds that people are willing to store in a private context, which in turn makes it more viable to make private transactions.

Privacy in voting, also super important. Projects like MACI are moving forward, starting to actually get used more. Also, other forms of ZK voting already exist and are already increasing in their user friendliness and their integration. So without privacy, voting turns into a very toxic social game and that’s why we need to really make privacy in any kind of on-chain voting a reality at the default.

Then the holy grail of course is to have privacy of general computation. Privacy of general computation is hard for a bunch of reasons. One of those reasons is that general computation involves doing a VM, and VMs involve client-side proving, and client-side proving is even harder to make efficient than server-side proving. And another reason is that privacy, in a general-purpose way, requires rethinking the software development model, because you don't just think about who owns what assets, you have to also think about who has access to what pieces of data.

Things like what Aztec has been doing in terms of figuring out Noir and figuring out their entire account and contract model. It's actually a pretty intricate and challenging amount of work, but ultimately this is the Holy Grail.

Privacy of rights off-chain. Okay, basically, this one's actually the easy one. So basically, the thing that matters here is send raw transaction as well as the various equivalents for ERC-4337, for intent-based transfers, like 7683, for every type of send needs to be able to happen through a mixnet so that when you do these operations, there is not a public link between your IP address and the transaction.

We should not expect that the Ethereum network is private by default. We should expect that people who want to see things are going to run like 30% of the nodes in the network just so that they can see everything that's going on. And the demand for this to increase as on-chain data leakage decreases. And so we need to increase the amount of network layer privacy as well.

Now, privacy of reads is something that we have not been talking about nearly enough, right? So, basically, your chances are, you leaked everything about yourself to whatever RPC provider you're using. This is a problem that can be fixed.

I see two tracks for solving this. One of them is keeping the form factor of a small light client connecting to a large RPC server, but making that connection actually be private. We've been thinking about making light client connections secure for a long time. I've been talking about Helios for a long time. Noah Citron has been heroically working on Helios for a long time. What Helios does not do is to give you light client security, it does not give you any kind of privacy.

And actually, a lot of the time, the more harmful thing that an RPC can do to you is not feed you bad information, even though feeding you bad information can totally cause you to lose huge amounts of money in a DEX. Rather, it's stealing your information and then potentially selling it off and potentially sending it out somewhere else.

The idea here is basically we use cryptographic technologies in order to make it possible for people to ask RPC servers for information, get back responses, without the RPC servers even knowing what they answered. So there is a short-term approach which uses trusted execution environments together with oblivious RAM, basically using these trusted hardware-based security models to reduce the opportunities for data leakage. And ORAM basically makes the TEE problem easier because you don't have to worry about leaking memory access patterns. Instead, the thing that has to be private is basically just a much smaller thing that has basically all of one memory in it. But then, of course, hardware-based security models are very imperfect, and there is a more holy grail solution, which is private information retrieval, PIR.

This thing has a lot of challenges in terms of efficiency, but the efficiency of PIR has been improving more and more with every passing year, and it is something that we actually can get to doing.

Making hardened RPC nodes is one of these paths. The other one of these paths is making it easier and more practical for a user to run their own node, even as Ethereum L1 scales.

Who here runs their own node or has run their own node in the last 12 months? Okay, someone shout out how many gigabytes it takes on your hard drive. A few hundred? Okay. Mine is like 2048, but I got a fancy laptop to play around with self-hosted LLMs.

Who here has on the hard drive of their laptop more than 256 gigs of disk space? Or more than 512? Now in the EIP over 9000, I forget the exact number, in the proposed EIP that specifies Ethereum node requirements, the expected amount of disk space is four terabytes. So who here has four terabytes? Now this is a problem, right?

There actually is a pathway to make the node running requirements decrease massively. And that pathway basically is one, history expiry, make it so that nodes do not have to store history. If you even only do that, then two is you do things like block level access list and zkEVMs.

And so you basically get verified blocks, and the only thing that you have to track is the state itself. Then you just get fed verified deltas to the state, you can apply the deltas directly, then that can reduce, even today, a node's storage requirements to something like 50 to 80 gigabytes.So who here on their laptop has, let's say, at least 80 gigabytes of space? Who here has that on their phone? With today's numbers, we can actually make state-storing nodes pretty viable. Now, of course, the argument is what happens if L1 scales by 10x? Then within a few years, we expect that to increase back to the hundreds of gigabytes.

The solution is partial state nodes, basically nodes that only store parts of the state. And we need to figure out some kind of way of basically splitting apart parts of the state that are spam for parts of the state that are relevant to important applications, and then you as a user can store only those parts of the state. So if you make queries that touch only those parts, then nobody outside of you and your computer actually needs to find out anything about what reads you're making. This is another piece of privacy of reads. 

A third piece of privacy of reads is identity and accounts. Who here has used zkEmail? Anon Aadhaar, any of the ZK wrappers? Who here has a World ID? I mean, I had one and I lost it. Then, so, you know, hopefully their recovery. Now, who here has used ZK Passport? Actually, I have two.

One of the parts of this, basically, what is identity API used for? Identity is an important piece in all kinds of different applications. It can be used to prove that you are the same person that previously did some action. It can be used to prove that you're not a robot. It can be used to prove that you are a member of some community. But at the same time, identity has all kinds of risks if it's done incorrectly. So single global identifiers are something that could be abused for deplatforming, especially if they're not implemented well single.

If you have a single global identifier, even if everything is done through nullifiers, you can still be coerced into revealing your nullifier. So a lot of challenges in getting into this whole space and doing it well. This is something where the world is moving forward into these kinds of things. Our community might be the most well positioned to actually figure out a well-designed privacy-friendly and pluralistic form of identity and reduce the chance that the thing that the world standardises on is just terrible across multiple dimensions.

Privacy of ID is something that directly comes into wallets themselves. So private account abstraction, right? Right now, to use Railway or to use Privacy Pools or any of these, you need to have one single key. Who here would feel comfortable trusting one single key with $1 million? $10 million? Okay. Let me ask the question another way: more than 10% of your assets? More than 50% of your assets? See, very few hands raised, right? And so basically, for privacy to be viable, we need the underlying accounts to actually be much more secure than single keys.

The most very basic thing you can do is, of course, multisig, right? But the real long-term thing that we can do is private account abstraction, right? Basically, whatever your normal account is, the account that you use to send normal transactions, In order to spend from private accounts that are ZK-linked to that account, you have to provide a zero-knowledge proof that you still control that account. And then on top of that, you have to reveal that you control some extra secret, and the point of that extra secret is just the privacy part.

If we do this, then we can make ZK accounts much more secure. We can basically enable much more secure and zero-knowledge ways of revealing who you are both to your on-chain account and to all kinds of other on-chain applications, and we can make this work seamlessly with your existing accounts on Ethereum.

So this is kind of my general privacy mind map. There are other important things to think about here.

One of those things is when do we get into doing privacy on the L1? I think this is a topic worth exploring. The reason to not do this literally tomorrow is basically that if you implement that and there's a bug in the privacy mechanism, then someone can print infinite money and you won't even be able to tell. So it's... pretty scary in that sense. We should wait until our privacy stack is and our ZK stack is formally verified proven to a much greater extent and ideally we can do that for the ZK that we use to scale Ethereum and for the ZK that we use to make Ethereum private at the same time.

ZkSNARKs on their own are not enough for a lot of things. There are things that require FHE, though even with FHE, you need to have basically a multi-sig backdoor committee that reveals when things get decrypted, which is scary in its own way.

For me, the holy grail is obfuscation. Maybe we actually might get obfuscation in the not-too-long-term future. We'll see.

There's things that are worth thinking about in terms of the Ethereum of 2040 from that point of view. It's a discussion that we should consider. My view on short-term things the L1 should do for privacy is basically that whatever we do in terms of L1 account abstraction and L1 fossil support should be designed with privacy protocols in mind. That's the basic bottom line that we should agree on in terms of what L1 does for privacy in the short and medium term, at least until we were confident enough in the cryptography to actually stick privacy features into the L1 directly.

In conclusion, privacy on Ethereum is happening, and there are already things that are underway on each of the items that I talked about. And I think anyone who is here can actually help build out any part of that map, right?

For anyone of these bubbles, anyone of these things, there are things that people in this room can go and contribute to. If you are someone who is good at hacking around Ethereum clients, you can go build a partial state node. If you're someone who is good at figuring out private account abstraction and some of the challenges around doing on-chain reads and doing the client-side proving, you can work on that. Working on client-side proving enables a lot of these, so client-side proving work is important. Privacy-preserving voting is important.

Each and every one of these items here are potential hackathon projects and are potential long-term projects for people here to put a lot of effort and time in. Let's work together. Let's make the best privacy-preserving user experience on Ethereum possible.

Recording

How would you explain what a nullifier is and why can it be coerced easily?

V : Okay, so the way that the math works right is that you have a secret and then using that secret you can think of it as you hash the secret plus one and then you get a public number and then you hash the secret plus two and then you get your nullifier.

What you do if you have some resource that can only be spent once, then when you receive the resource, you publish the first number and then when you spend it, you publish the second number along with a proof that there exists some first number that someone was publish someone published previously where that basic the same secret was used to generate both, right? And because the secret always stays private to you permanently, you're the only one that's able to make the proof. You're the only one that's ever able to actually know that link. And so what this means is that essentially, you're able to make a proof that says I'm using or I'm allowed to take this action because I have a resource of a particular type. And this proof at the same time the nullifier being published basically prevents you from claiming the resource twice. It prevents you from dossing the system.

The issue with coercion is basically that someone can always if they see that there is an any action and that action is connected to you um then which they could find out offline or through any other way then they know that you're you are a user of this system and they can force you to reveal your secret and I mean potentially they can torture you or lock you up until you actually reveal the secret that that maps to that nullifier. And then once you do that then that also reveals your original ETH value and then potentially that reveals your entire history. Right?

These are the kinds of issues that ZK by itself and especially ZK identity because it creates this persistent object that you end up creating like many application specific nullifiers from right is like needs to solve for right because if you don't then like someone can basically kind of force you to reveal your entire identity that you used to sign everything.

Do you have an opinion on the EIP-7503 Zero-Knowledge Wormholes and do you think there's plausible deniability maybe possible?

V : Yeah, I think it's cool. I saw there were some recent improvements to it. Things like making it work off of receipts instead of state proofs which I think really improves the simplicity, reduces code complexity which is good. For me personally to feel comfortable with it, the main blocker is basically that ZK technology needs to get mature enough.

It needs to get to the point where we have really really strong assurance that this kind of thing is not going to be broken, right? Because if someone breaks it, they can actually can print basically an unlimited amount of money, right? Because the size of the anonymity set it's not even the set of all explicit depositors. It's basically the set of all people who have transferred ETH into accounts where it has not been spent from. And so it's the like someone could just print tens of millions of ETH before we know what's going wrong, right?

Being really solid on security is the big prerequisite for me. And there's also smaller things like the fact the 80 bytes kind of thing and that even with the grinding it only has 92 bits of collision security which is on the boundary of like being okay. think if we're going to take time to be confident on security we should also take time to like maybe figure out how to finally move away from 20 byte addresses. Some security related things need to be figured out. Personally if the security related things were already solved like I would totally love it and like want it to be in ASAP but it will take time and at some point we'll get to the point where we're comfortable with things like that.

You mentioned that you want to see our privacy tech stack formally verified. Obviously formal verification comes in many formats. Can you talk just what you would like to see under what paradigm to give you the confidence in the next?

V : Yeah so one analogy is like the way that we're approaching formal verification of the zkEVM right and there there's two aspects to it one is formally verifying the arithmetization. Basically this prover creates a machine-verifiable proof of the mathematical statement that if you have a valid witness like valid polynomial values for these for these polynomial then that means that you have a valid execution of the underlying VM that's like and some implementation of that in lean that where the you know like final state is some particular value right and then on top of that you can even prove other statements so like for example there are some ZKVMs that have already proven a property called determinism which basically means that the ZK EVM accepts exactly one post state route. That's powerful because it means that like there aren't bugs that allow an attacker to just prove anything.

Once you have and then another part of the proof is like actually proving the kind of correctness of the proof systems themselves, right? And that's something that I think we've gone into less because we're still in the arc of optimizing the proof systems but at some point we need to start doing that. So that's the basic thing. Similar types of things can be done for client-side proving, right? We can potentially even mathem like convert statements like if you put one coin into Railway then you can take one coin out into a mathematical statement that you can actually verify ends to end right or you can do similar things to virtual machine execution right.

We do things like that then like we can get more comfortable with the actual safety of all of this zero knowledge machinery that in the future millions of ETH will be dependent on.

Do you agree with the with the community's reaction to the ban of the Tornado Cash some years ago and if not how do you to the and how do you prevent how do how do you prevent it in the future?

V : I mean what to you what was the Ethereum community's reaction to the Tornado Cash ban?

I thought that many node runners started to to censor transactions and also I don't know if there was public support for developers of Tornado Cash.

V : Yeah. Yes. There was definitely a scare back in about 2022 to 2023 regarding block builder censorship, right? And this is like an intersection of the privacy legal issues and the whole like builder centralisation problem. So my view on the builder centralisation problem right now is that like we need Fossil um as a way of mitigating the mitigating it. Like basically what Fossil does is it creates 16 different actors per slot who have the power to force any transaction to get included inside of that slot. We get like very strong censorship resistance even if the entire block building market gets monopolised by one actor like not saying we should let that happen right but even if as a second layer of defense I know there are people who are working on multi-party block building technologies like basically market designs where blocks get built through the collaboration of multiple actors by default and if that happens that also helps kind of decrease the risk of single block builder dominance. That's strategy two and strategy three is like I think we should at least explore some kind encrypted mempool ideas in parallel.

To me those are the top three and I think if privacy is going to be first class importance for Ethereum it should be then like we needs to have multiple paths toward continuing to make sure that we have it right and also I mean in general like these things should be the responsibility of L1. We should not require individual like identified actors including builders or even including application developers to be virtuous, right? We should really ensure censorship resistance of the L1 and also we should do a version of account abstraction that is friendly to privacy protocols. 7701 for example does this and so that way Privacy pools and Railway and Tornado cash will be able to get rid fully of the of the public broadcaster dependency.

You showed a slide with a lot of things that could be paralysed like the reads, the rights, etc. Were those use cases what you had in mind when Ethereum came out with with Whisper? And if so because you also said that off-chain is good because it doesn't leak as much metadata. Is there a strong case for for the adoption of off-chain peer-to-peer like I'm going to say Waku? Would Waku make sense for a bunch of those?

V : Yes. Waku is a successor to Whisper. So Waku is very important work and I know it's already starting to be used in messengers. These things are good. I think Waku actually is one of the things that we should explore for the privacy preserving send RPC transaction use-case.

I do think that like Waku-type things are insufficient in a couple of ways. Maybe one or two years ago the vision for how privacy would happen is basically you would have things like the portal network and so you would you which would not just cover history it would also cover state and if you wants to make a state read then you would ask the peer-to-peer network and you connect to it through Waku and then it would give you back a Merkle branch right the reason why I think this is insufficient is that anonymisation is not enough.

Let's say I do a Railway withdrawal and I withdraw into account X right and then right before I do this there is in the network a query that goes to account X and also a query that goes to account Y right then what's actually happened is while there is information that is out there in the public that linked X to Y it actually doesn't even matter that theoretically X and Y might have been mapped to different nodes. Because even just those two accesses happening at the at the same time is still enough information to probabilistically narrow the user down to a very small number of participants.

For that reason we don't just need anonymisation. like we actually need a mechanism that allows users to do reads without those the the content of the read like the index or the address that you're reading being exposed to anyone except for the user themselves.

I view those two technologies as as being highly complimentary for the Ethereum use-case. Like I think for for this for the sending transaction aspect mixnet type things which includes Tor and ITP which which can also include Waku is indispensable.

Yeah I mean that is a legal question which is above my pay grade. Imagine there are definitely very passionate legal people who have been exploring ways to do that but I'll leave the question to them.

Talk about Waku again in back in 2021 I built a messaging app that was and using Waku and of the interesting things is that because the node was running in browser I didn't have to require the user to do some operation like run a node. What do you think about because I'm running also many nodes archive so I use my own explorer have my own RPC which is private but we have learned that people don't want to run their own so is there any way we could have something similar that says in order to access the service you have to even without knowing it?

V: I mean the challenge with the without knowing it part is that even a partial state node is going to take tens of gigabytes and you can't like ask people to download tens of gigabytes in the background without telling them because like at the very least it's going to like destroy a bunch of people's phone plans, right? I think the anything that is like seamless and fully in the background is something that realistically is just going to require um some kind of like light client based approach.

Now, what you could do potentially is you could have like an even more radical partial state node, like a node that only like stores the state of like say a privacy protocol and nothing else. And so it's obvious to the network that you're a user of the privacy protocol, but not but but they don't see anything else, right? And that's interesting.

That would be like one thing that is important to keep in mind. Right, but I mean in general I mean the other challenge of course of this kind of run a node without the user even knowing it is basically that then like if the ecosystem standardises too much over that then like users don't become aware of like what security guarantees they have. So the type of approach that I would favor is where this is related to the whole problem of embedded wallets in general. Where if you use an application with an embedded wallet then by default the embedded wallet does its thing but also if it detects that you have a browser wallet then it automatically switches over to the browser wallet and then the browser wallet can run the checks itself and give you a guarantee that you're being secure even if like the dapp interface has been hacked.

Just wondering about governance and privacy. I know you mentioned the on-chain voting as well as the fund transfers and kind of the important privacy elements there. Are there any other specific use-cases around governance that get you excited and where you think it's crucial to enable privacy?

V: I mean I think for me like governance is it's like often one part voting and two parts communication, right? And so having privacy preserving comms and having privacy preserving comms with the level of UX quality that people are willing to actually adopted and defaults to it is something that's very valuable. So I mean Signal I think has done quite a good job but also like Signal definitely lags behind other apps on at least some dimensions. I mean I know increasingly you've been seeing people migrating to Mattermost which is like self-hosted over Slack though which is like I think fine for the context of an organization for the context of something more diffuse like a DAO like you probably want people to be able to communicate in a way where the trust guarantee doesn't even depend on the operator.

Having like something stronger and sort of even more cypherpunkish would actually help a lot. That's one and then for the voting part basically every part of a governance process should be ZKed right and then like basically the principle is sort of only necessary transparency right so the the rules of the of the game have to be transparent and have to be very clear to everyone but in the context of the actions like only the contents of the action that need to be public would be the contents of the action that actually get made public. And like we can think about that as a starting principle. Apply that across all the different you know regular DAO voting, quadratic voting, quadratic funding sort of designs. I mean sortation is interesting also right because you should be able to have zk sortation where nobody else knows if you've been chosen right because if you have been chosen that's like a very easy coercion vector. We need to think privacy-first across all of these things.

Any work on reintroducing interfaces to allow for encryption decryption keys which might be derived from a root key via a standardized API. So, this is is this like the equivalent of what MetaMask did back in the day with giving you like an encryption?

V: Yeah, this is a good idea. This is actually not too far from some ERC's that have already been made. Like I think 5564 is the ERC for stealth addresses and stealth addresses implicitly depend on a public key encryption technology, right?

So if you generalize that only a little bit then you can basically have a system where each account can publicly show like what its encryption key is and then you'd be able to do encrypts to an account and I think that would be super valuable. Maybe as a portal app it would also be super cool to set a small defined restricted payload which can be decrypted right we don't need to make it big like a very small interface very clearly defined to just send something in for encryption decryption.

V: Oh, I see. So, you mean like the equivalent of a Zcash memo field? Yeah, I would support that.

Is Railgun ever going to lower their quarter % fee? Do you know?

V: I mean that's that's a question for them. Realistically for higher levels of adoption at some point they will have to but I think this is this is their choice.

Lots of privacy projects will help to corporations. How do you see the synergy between B2B privacy and sort of like human privacy and where are the disconnects between them?

V: So I think they share a lot on technology right and like enterprise privacy projects and my kind of look these sort of grassroots Ethereum ecosystem privacy projects have contributed to the same code on many occasions many of them are forks of each other there's a lot of implicit collaboration at the tech level often one thing that's happened in practice so far is that the B2B privacy use cases they've decided that for their compliance needs they have to have some kind of backdoor whereas I think for these more consumer oriented privacy protocols like there's been a strong standard of them being backdoor free and things like Privacy pools and Railgun that basically allow people to like publicly say I am not like one of these depositors like that's fine right but the thing that's not fine is a system where your privacy can retroactively be rug pulled, right? If you think you're private, you should stay private. And this kind of guarantee is incompatible with the kind of approach that B2B has been taken and like the B2B protocols compliance needs. So that's like probably the biggest disconnects that we've seen so far.

I mean my personal dream is of course that over time kind of norms keeps changing and the compliance needs on even the B2B side will start shifting toward more like a kind of privacy pools and Railgun style selective disclosure approach but that's something that of course we'll continue taking time but no I mean in general I do see those ecosystems as being very collaborative just because even if they make different decisions, they use like 90% of the same code.

What is privacy end-game?

V: Privacy endgame is basically that like you should be able to have your digital life without revealing information to other people that you do not want to reveal or that you do not know you're revealing. I think privacy is also valuable in physical space and like I definitely do not appreciate all of the people that just like randomly I mean like photo me and then put me up on crypto Twitter and then there's like people talking about like oh you know like this is what Vitalik is doing now. Unfortunately those kinds of problems are kind of outside of our area of expertise to solve.

The domains that I think will matter over the next two decades right I think are like especially as physical privacy keeps decreasing digital privacy needs to keep increasing to compensate and this involves privacy of communications this involves privacy of funds transfers this involves privacy of governance operations and ultimately like those three things you know they're not entirely separate categories. They're a continuum, right? Like any funds transfer is at least in part of communication. You know like any communication is at least in part a governance operation, right? But then other categories that will pop up privacy of AI so AI is like increasingly becoming sort of a second brain and like chatGPT seeing all of that as something that should not happen.

Who here, has a local LLM installed on their devices now? You should. Who here has bought a some kind of computer or GPU specifically to be able to run better local LLMs? Okay.

One thing that you can do by the way that's like actually economically optimal is buy something powerful but share it between you and a group of your friends, right? So like for example like if you look at a Mac studio the if you with top end specs like the cost does go to the crazy side it's $12,000 but the way the thing that the property that LLM use has is basically you're only actually using it like 1% of the time right and a full-size Mac studio is actually powerful enough to run full-size DeepSeek at a very good speed and so one thing you could do is you could basically take one such device and basically give you know yourself and a few a few or like or a dozen or a few dozen people that you know like you reasonably trust access to it, right?

There's a lot more experimentation with kind of local and even kind of going up to the larger model is a good thing. Because yeah the AI is going to become more and more a part of your thought we're also going to get start getting BCIs very soon brain computer interfaces and so privacy of BCIs is literally privacy of your mind basically you know privacy will go down a lot if we're not careful and if we are careful and if we do the right thing we can keep it at a similar level or even increased and I think this is a very valuable project to push for.

Can you share the perception of cypherpunk within two years because the first year once you published the article and I'm just checking a Devcon talks only Peter Van Valkenburgh from CoinCenter was the only one talking about the cypherpunk then some B2B companies were exploring like how they can talk about this what legal would allow them to talk about and what's the state of this cultural shift and change.  

V: This is actually a very good political moment to start talking about cypherpunk and privacy topics more openly. And I think this is actually true for a couple of reasons.

One of those reasons is that the just the global political environment is much more unfriendly than it was I mean more than two years ago, definitely more than four years ago and like way more than than 10 years ago. And so the idea that you know, oh, you can just go run one of these centralized things and it's run by like nice idealistic tech people and like they're definitely not going to do anything bad or get captured by people who will make them do anything bad is just like more obviously completely false. And this is not something that like grassroots rebels care about. This is something that institutions care about. This is something that governments care about, right? That's like one thing.

In this kind of like much less friendly and much more unstable environment, having more sovereignty over your own data at an individual level and at a group and community level is more important. And the other thing is that like there are people who have talked about the current era as being an era where you can just do things. And sometimes of course this is bad because just doing things sometimes involves just shooting missiles.

At the same time from an individual point of view like you know you can just do things does mean you know you can just go and make privacy protocols. You can just go and send people $10,000 without telling anyone and like you can just really go much further in asserting your digital rights than people were comfortable with a few years ago. And there's like basically from both of those angles. The need has increased and the opportunity has increased and supporting kind of personal and local community security and seeing privacy as being a core part of that security is something that is very important to I mean both talk about and make a reality right now.

Since it's very important for you to keep your thoughts private and you run a local LLM how do you deal with the your location privacy?

V: Yeah, currently not well. I do not claim to have good solutions.

And one of the challenges here, right, is that like even if you do you know like burner phones and literally rotate them every month like even a month of data is totally enough to uniquely fingerprint and identify you. So it's a hard problem.

If you want to like really go further out on location privacy then like we will have to figure out kind of lifestyle alternatives to having your internet constantly with you on the go that provide something close to that level of quality and like that basically means much more accessible mesh networks that might even mean kind of more piratey stuff like something that automatically connects to Wi-Fi networks and automatically does the click through and like you know like goes through passwords or whatever. You need an alternative to that for connectivity is probably the number one thing but then even kind of beyond the the beyond that right the other thing is just like the ease of in person surveillance and just all of the cameras that are everywhere right and the more realistic thing to do is to just kind of continue to fight for laws that kind of restrict those kinds of things and like and put controls on them, right?

People can get around them, but like it like every single one of those things does push the people creating the cameras to be more careful and to kind of not be as brazen in data collection or in like in letting the data get leaked. But no, going further beyond that like I definitely admit it's a challenge.

What's your opinion on the how privacy projects can reach product market fit because we're talking with the folks on the scene and only barely a few for example for Railgun it took three years to hit the break even barely any self-funded project of three people can reach this state for Rotki is based on the personality of Lefteris and there's not many people like him so what how would you suggest privacy builders to go post hackathon in their way to find that product market fit.

V: We should learn a lot from Signal, right? Signal is like the one reasonably cypherpunk project that like actually has gotten a huge amount of adoption to the point where you know famously even the US government uses it. That's Bitcoin. Well Bitcoin I would not call Bitcoin a privacy project right. We should like from from my point of view like what succeeded with Signal is like it actually does have a good enough UX that it's a kind of like maybe like 80 to 90% capable drop in like Skype or Telegram replacement and then like that's good enough to the point where like basically you have these spikes of adoption that happened you know Snowden revelations and then the whole like Pavel Durov situation last year and like basically every time this happens more and more people become interested.

But in order for that to happen your project has to be ready for it right and so to me like one of the warnings is basically just improve UX right though I mean at the same time where like even Signal is like it's definitely not strong enough on the metadata privacy and so we do need to keep pushing harder there.

Usually developers when they do hackathons overscope what's possible within three days. What would be the the low hanging fruit in terms of dev hours spending on privacy.

V: So if you want to work on like for example PRI then one simple thing is instead of focusing on state you focus on history and the easy problem that you do is basically that the input is a log topic and the output is and basically the client asks the server give me what the log the one log in the previous block that is compact that has that log topic and then the server rep like scans overall of the logs in just that one block. So that's like a set of size 100 to like maybe between 100 and a thousand then replies back with that like if you just have that like that already is the seed of privacy preserving history query and like that's a thing that I mean I think especially in the GPT era lots of people here are very able to go and vibe code um well or hopefully the you know like locally running DeepSeek like 0525 or like whatever the most recent one um era um so then If um you know we're talking about like ease of use then like build a wallet that like creates a one-click experience for Privacy pools or Railway operations.

Then if we're talking about like ZK voting, actually fork one of the some DAO-like governance framework and basically rip out the backends and make it private. And otherwise, make it look as close to identical as possible.

I think that's kind of roughly the the bite-sized chunk you'd want to do for the hackathon.

What are your thoughts about whistleblowing rights and how they intersect with privacy data?

V: Yeah, I mean in general I think whistleblowing is absolutely important and I'm generally a big believer of know Julian Assange's maximum, maxim of privacy for the weak and transparency for the powerful and I generally think that like actively forcing powerful organizations including companies including governments to be more open than they otherwise would be is like actually one of the more important counterforces to reduce the risk of like some kind of single actor dominating the world in in some irreversible way in the future. To me whistleblowing is definitely an important part of that. One area where ZK tech would help is it can actually make whistleblowing credible right because not only can you reveal information but you can reveal information attached to a zero knowledge proof of the truth of that information.

What do you think about zkTLS for? zkTLS is good. Yeah, you should use it.

Thank you.

Note: speech has been turned from video to text & modified for reading experience. If you saw any conversion artifact - contact us.

Vitalik Buterin’s talk on Ethereum Privacy @ W3PN HACKS, Berlin [June 2025]

Topic for today will be first getting serious about privacy.

We'll talk first a little bit about Ethereum, the approach that I've been thinking about in terms of how Ethereum can move forward on privacy, what kinds of things we should do, in what order, what kinds of things we should do that we have not been thinking about before so far, what kinds of things we should not do.

What we've seen so far is that Ethereum has led the way on privacy research and development in a lot of different ways. Zcash, of course, was the first major production implementation of on-chain privacy. Systems on Ethereum were probably either the second or close to the second. So back in 2019, we had the ECMUL and ECADD and ECPAIRING opcodes that enabled all kinds of on-chain privacy solutions to start happening.

Then we saw Tornado Cash launched on Ethereum. It was the chain where the entire arc of that very complicated story happened. By the way, free Roman Storm. Roman Storm continues to need help.

Then PSE - the Privacy & Scaling Explorations in the Ethereum Foundation. They have worked on many kinds of ZkSNARK protocols, a lot of low-level protocol-related research, dev tooling-related & implementation-level work. PSE has been a bedrock of a lot of very bottom-level tooling and ideas on zero-knowledge proofs for scaling and zero-knowledge proofs for privacy.

L2s have contributed a lot. Aztec, in addition to releasing already multiple test versions, I believe Mainnet coming soon, has also been experimenting with a lot of very innovative ideas regarding privacy, but also lower-level things like the Noir language, the entire Plonk and plookup category of algorithms.

Intmax, fully ZkSNARK-based plasma rollup hybrid. Nightfall from EY, championed by Paul Brody quite a bit. Ethereum has been a home for a huge amount of valuable privacy-related work. But the problem is that on real-world value delivered to users, we are far behind where we could be. So, if you're actually using a privacy protocol on Ethereum today, shout them out.

A lot of things are starting to happen, but what does using a privacy protocol today look like? My experience is, one, it requires you to have a separate seed phrase. You have this totally separate thing that you have to worry about holding and not losing and not having stolen if you want to use your assets. That's one.

Two is there is no multi-sig option. The only option is a single key option, which is pretty scary for large amounts of funds.

Three, it requires opening a separate wallet. So whenever you want to do a private send, you have to go and open the thing and then slowly starts loading. It goes from zero to 100. You have to wait 30 seconds.

Four, you need a total of about five clicks to private send and withdraw.

When I use Railway, I count, click one, open the railway wallet, and then click two, you have to click on unshield, which is a different thing than send, the thing that I think of as sending is actually unshielding, sometimes I click send and then I realise that's the wrong thing and I have to do a third click of clicking unshield. Two, click on Shield. Then three, click on Generate Proof. Then you wait. Then four, click on choosing a public broadcaster. And then when the proof is done, it's usually a fifth click to actually start the whole process.

It's a much more complicated gist on a raw UX level than it could be. And also the public broadcaster mechanism, this is something common to Tornado Cash and Railway and anyone of these systems that tries to actually be decentralised.

These things are brittle, these things often break, these things within the last six months I've had situations where it just broke completely on one version and I had to switch versions at some point. Broke completely on one internet connection. I had to either turn a VPN on or turn a VPN off.

So very far from perfect and we can do better.

Why now?

Why do we want to really push for privacy now as opposed to pushing for privacy in, say, either 2021 or 2029? First of all, at the top of all this, privacy is important, right?

Privacy is freedom, privacy is order, privacy is progress, privacy is a bedrock of a lot of things that we care about in this world.

Privacy is not just an abstraction in the same way that something like decentralisation or credible neutrality is. Privacy is a concrete benefit that is directly appealing to users. You can understand what it means to transact privately. Transacting privately as opposed to transacting publicly is something that actually has meaningful differences in the kind of experience you will have during the transaction, but more importantly, after the transaction.

Freedom of speech is easy. Freedom after speech is the harder thing. Also, the technology is mature enough today. This was not true four years ago. Today, we can do it, and therefore, we must.

The way that I think about "privacy on Ethereum is", I break it up into three categories.

First, privacy of writes on-chain. Basically when you perform operations and things like sending, those operations happen on-chain. By default, everything you do on-chain creates a public link between every operation and every other operation. How do we do with these things without creating the on-chain public link?

Then number two, privacy of writes off-chain. So in this case, how do you avoid leaking information when you're sending transactions, like basically all the parts other than the blockchain itself?

And number three, privacy of reads, right? When you read the chain, the chain reveals a lot of things about who you are and what you're doing. And how do we actually try to minimise that?

So let's start with privacy of writes.

Three categories that we can focus on short term. One is funds transfers, two is DeFi, three is voting. These are basic category of operations and there are strong cases to have privacy for each of these.

Private funds transfers. We all know about them. Private DeFi, so Railway, for example, has private DeFi inside of it. Adding privacy to DeFi has value in a lot of different ways. So it's valuable for people not to know what your investments are, what your strategies are. It's valuable for people to not know what your liquidation price is. It's valuable for people to not know everything you're doing in real time so that they can front run you. There's all kinds of reasons why it's important to be private in DeFi in order to protect you.

Having private DeFi increases the amount of funds that people are willing to store in a private context, which in turn makes it more viable to make private transactions.

Privacy in voting, also super important. Projects like MACI are moving forward, starting to actually get used more. Also, other forms of ZK voting already exist and are already increasing in their user friendliness and their integration. So without privacy, voting turns into a very toxic social game and that’s why we need to really make privacy in any kind of on-chain voting a reality at the default.

Then the holy grail of course is to have privacy of general computation. Privacy of general computation is hard for a bunch of reasons. One of those reasons is that general computation involves doing a VM, and VMs involve client-side proving, and client-side proving is even harder to make efficient than server-side proving. And another reason is that privacy, in a general-purpose way, requires rethinking the software development model, because you don't just think about who owns what assets, you have to also think about who has access to what pieces of data.

Things like what Aztec has been doing in terms of figuring out Noir and figuring out their entire account and contract model. It's actually a pretty intricate and challenging amount of work, but ultimately this is the Holy Grail.

Privacy of rights off-chain. Okay, basically, this one's actually the easy one. So basically, the thing that matters here is send raw transaction as well as the various equivalents for ERC-4337, for intent-based transfers, like 7683, for every type of send needs to be able to happen through a mixnet so that when you do these operations, there is not a public link between your IP address and the transaction.

We should not expect that the Ethereum network is private by default. We should expect that people who want to see things are going to run like 30% of the nodes in the network just so that they can see everything that's going on. And the demand for this to increase as on-chain data leakage decreases. And so we need to increase the amount of network layer privacy as well.

Now, privacy of reads is something that we have not been talking about nearly enough, right? So, basically, your chances are, you leaked everything about yourself to whatever RPC provider you're using. This is a problem that can be fixed.

I see two tracks for solving this. One of them is keeping the form factor of a small light client connecting to a large RPC server, but making that connection actually be private. We've been thinking about making light client connections secure for a long time. I've been talking about Helios for a long time. Noah Citron has been heroically working on Helios for a long time. What Helios does not do is to give you light client security, it does not give you any kind of privacy.

And actually, a lot of the time, the more harmful thing that an RPC can do to you is not feed you bad information, even though feeding you bad information can totally cause you to lose huge amounts of money in a DEX. Rather, it's stealing your information and then potentially selling it off and potentially sending it out somewhere else.

The idea here is basically we use cryptographic technologies in order to make it possible for people to ask RPC servers for information, get back responses, without the RPC servers even knowing what they answered. So there is a short-term approach which uses trusted execution environments together with oblivious RAM, basically using these trusted hardware-based security models to reduce the opportunities for data leakage. And ORAM basically makes the TEE problem easier because you don't have to worry about leaking memory access patterns. Instead, the thing that has to be private is basically just a much smaller thing that has basically all of one memory in it. But then, of course, hardware-based security models are very imperfect, and there is a more holy grail solution, which is private information retrieval, PIR.

This thing has a lot of challenges in terms of efficiency, but the efficiency of PIR has been improving more and more with every passing year, and it is something that we actually can get to doing.

Making hardened RPC nodes is one of these paths. The other one of these paths is making it easier and more practical for a user to run their own node, even as Ethereum L1 scales.

Who here runs their own node or has run their own node in the last 12 months? Okay, someone shout out how many gigabytes it takes on your hard drive. A few hundred? Okay. Mine is like 2048, but I got a fancy laptop to play around with self-hosted LLMs.

Who here has on the hard drive of their laptop more than 256 gigs of disk space? Or more than 512? Now in the EIP over 9000, I forget the exact number, in the proposed EIP that specifies Ethereum node requirements, the expected amount of disk space is four terabytes. So who here has four terabytes? Now this is a problem, right?

There actually is a pathway to make the node running requirements decrease massively. And that pathway basically is one, history expiry, make it so that nodes do not have to store history. If you even only do that, then two is you do things like block level access list and zkEVMs.

And so you basically get verified blocks, and the only thing that you have to track is the state itself. Then you just get fed verified deltas to the state, you can apply the deltas directly, then that can reduce, even today, a node's storage requirements to something like 50 to 80 gigabytes.So who here on their laptop has, let's say, at least 80 gigabytes of space? Who here has that on their phone? With today's numbers, we can actually make state-storing nodes pretty viable. Now, of course, the argument is what happens if L1 scales by 10x? Then within a few years, we expect that to increase back to the hundreds of gigabytes.

The solution is partial state nodes, basically nodes that only store parts of the state. And we need to figure out some kind of way of basically splitting apart parts of the state that are spam for parts of the state that are relevant to important applications, and then you as a user can store only those parts of the state. So if you make queries that touch only those parts, then nobody outside of you and your computer actually needs to find out anything about what reads you're making. This is another piece of privacy of reads. 

A third piece of privacy of reads is identity and accounts. Who here has used zkEmail? Anon Aadhaar, any of the ZK wrappers? Who here has a World ID? I mean, I had one and I lost it. Then, so, you know, hopefully their recovery. Now, who here has used ZK Passport? Actually, I have two.

One of the parts of this, basically, what is identity API used for? Identity is an important piece in all kinds of different applications. It can be used to prove that you are the same person that previously did some action. It can be used to prove that you're not a robot. It can be used to prove that you are a member of some community. But at the same time, identity has all kinds of risks if it's done incorrectly. So single global identifiers are something that could be abused for deplatforming, especially if they're not implemented well single.

If you have a single global identifier, even if everything is done through nullifiers, you can still be coerced into revealing your nullifier. So a lot of challenges in getting into this whole space and doing it well. This is something where the world is moving forward into these kinds of things. Our community might be the most well positioned to actually figure out a well-designed privacy-friendly and pluralistic form of identity and reduce the chance that the thing that the world standardises on is just terrible across multiple dimensions.

Privacy of ID is something that directly comes into wallets themselves. So private account abstraction, right? Right now, to use Railway or to use Privacy Pools or any of these, you need to have one single key. Who here would feel comfortable trusting one single key with $1 million? $10 million? Okay. Let me ask the question another way: more than 10% of your assets? More than 50% of your assets? See, very few hands raised, right? And so basically, for privacy to be viable, we need the underlying accounts to actually be much more secure than single keys.

The most very basic thing you can do is, of course, multisig, right? But the real long-term thing that we can do is private account abstraction, right? Basically, whatever your normal account is, the account that you use to send normal transactions, In order to spend from private accounts that are ZK-linked to that account, you have to provide a zero-knowledge proof that you still control that account. And then on top of that, you have to reveal that you control some extra secret, and the point of that extra secret is just the privacy part.

If we do this, then we can make ZK accounts much more secure. We can basically enable much more secure and zero-knowledge ways of revealing who you are both to your on-chain account and to all kinds of other on-chain applications, and we can make this work seamlessly with your existing accounts on Ethereum.

So this is kind of my general privacy mind map. There are other important things to think about here.

One of those things is when do we get into doing privacy on the L1? I think this is a topic worth exploring. The reason to not do this literally tomorrow is basically that if you implement that and there's a bug in the privacy mechanism, then someone can print infinite money and you won't even be able to tell. So it's... pretty scary in that sense. We should wait until our privacy stack is and our ZK stack is formally verified proven to a much greater extent and ideally we can do that for the ZK that we use to scale Ethereum and for the ZK that we use to make Ethereum private at the same time.

ZkSNARKs on their own are not enough for a lot of things. There are things that require FHE, though even with FHE, you need to have basically a multi-sig backdoor committee that reveals when things get decrypted, which is scary in its own way.

For me, the holy grail is obfuscation. Maybe we actually might get obfuscation in the not-too-long-term future. We'll see.

There's things that are worth thinking about in terms of the Ethereum of 2040 from that point of view. It's a discussion that we should consider. My view on short-term things the L1 should do for privacy is basically that whatever we do in terms of L1 account abstraction and L1 fossil support should be designed with privacy protocols in mind. That's the basic bottom line that we should agree on in terms of what L1 does for privacy in the short and medium term, at least until we were confident enough in the cryptography to actually stick privacy features into the L1 directly.

In conclusion, privacy on Ethereum is happening, and there are already things that are underway on each of the items that I talked about. And I think anyone who is here can actually help build out any part of that map, right?

For anyone of these bubbles, anyone of these things, there are things that people in this room can go and contribute to. If you are someone who is good at hacking around Ethereum clients, you can go build a partial state node. If you're someone who is good at figuring out private account abstraction and some of the challenges around doing on-chain reads and doing the client-side proving, you can work on that. Working on client-side proving enables a lot of these, so client-side proving work is important. Privacy-preserving voting is important.

Each and every one of these items here are potential hackathon projects and are potential long-term projects for people here to put a lot of effort and time in. Let's work together. Let's make the best privacy-preserving user experience on Ethereum possible.

Recording

How would you explain what a nullifier is and why can it be coerced easily?

V : Okay, so the way that the math works right is that you have a secret and then using that secret you can think of it as you hash the secret plus one and then you get a public number and then you hash the secret plus two and then you get your nullifier.

What you do if you have some resource that can only be spent once, then when you receive the resource, you publish the first number and then when you spend it, you publish the second number along with a proof that there exists some first number that someone was publish someone published previously where that basic the same secret was used to generate both, right? And because the secret always stays private to you permanently, you're the only one that's able to make the proof. You're the only one that's ever able to actually know that link. And so what this means is that essentially, you're able to make a proof that says I'm using or I'm allowed to take this action because I have a resource of a particular type. And this proof at the same time the nullifier being published basically prevents you from claiming the resource twice. It prevents you from dossing the system.

The issue with coercion is basically that someone can always if they see that there is an any action and that action is connected to you um then which they could find out offline or through any other way then they know that you're you are a user of this system and they can force you to reveal your secret and I mean potentially they can torture you or lock you up until you actually reveal the secret that that maps to that nullifier. And then once you do that then that also reveals your original ETH value and then potentially that reveals your entire history. Right?

These are the kinds of issues that ZK by itself and especially ZK identity because it creates this persistent object that you end up creating like many application specific nullifiers from right is like needs to solve for right because if you don't then like someone can basically kind of force you to reveal your entire identity that you used to sign everything.

Do you have an opinion on the EIP-7503 Zero-Knowledge Wormholes and do you think there's plausible deniability maybe possible?

V : Yeah, I think it's cool. I saw there were some recent improvements to it. Things like making it work off of receipts instead of state proofs which I think really improves the simplicity, reduces code complexity which is good. For me personally to feel comfortable with it, the main blocker is basically that ZK technology needs to get mature enough.

It needs to get to the point where we have really really strong assurance that this kind of thing is not going to be broken, right? Because if someone breaks it, they can actually can print basically an unlimited amount of money, right? Because the size of the anonymity set it's not even the set of all explicit depositors. It's basically the set of all people who have transferred ETH into accounts where it has not been spent from. And so it's the like someone could just print tens of millions of ETH before we know what's going wrong, right?

Being really solid on security is the big prerequisite for me. And there's also smaller things like the fact the 80 bytes kind of thing and that even with the grinding it only has 92 bits of collision security which is on the boundary of like being okay. think if we're going to take time to be confident on security we should also take time to like maybe figure out how to finally move away from 20 byte addresses. Some security related things need to be figured out. Personally if the security related things were already solved like I would totally love it and like want it to be in ASAP but it will take time and at some point we'll get to the point where we're comfortable with things like that.

You mentioned that you want to see our privacy tech stack formally verified. Obviously formal verification comes in many formats. Can you talk just what you would like to see under what paradigm to give you the confidence in the next?

V : Yeah so one analogy is like the way that we're approaching formal verification of the zkEVM right and there there's two aspects to it one is formally verifying the arithmetization. Basically this prover creates a machine-verifiable proof of the mathematical statement that if you have a valid witness like valid polynomial values for these for these polynomial then that means that you have a valid execution of the underlying VM that's like and some implementation of that in lean that where the you know like final state is some particular value right and then on top of that you can even prove other statements so like for example there are some ZKVMs that have already proven a property called determinism which basically means that the ZK EVM accepts exactly one post state route. That's powerful because it means that like there aren't bugs that allow an attacker to just prove anything.

Once you have and then another part of the proof is like actually proving the kind of correctness of the proof systems themselves, right? And that's something that I think we've gone into less because we're still in the arc of optimizing the proof systems but at some point we need to start doing that. So that's the basic thing. Similar types of things can be done for client-side proving, right? We can potentially even mathem like convert statements like if you put one coin into Railway then you can take one coin out into a mathematical statement that you can actually verify ends to end right or you can do similar things to virtual machine execution right.

We do things like that then like we can get more comfortable with the actual safety of all of this zero knowledge machinery that in the future millions of ETH will be dependent on.

Do you agree with the with the community's reaction to the ban of the Tornado Cash some years ago and if not how do you to the and how do you prevent how do how do you prevent it in the future?

V : I mean what to you what was the Ethereum community's reaction to the Tornado Cash ban?

I thought that many node runners started to to censor transactions and also I don't know if there was public support for developers of Tornado Cash.

V : Yeah. Yes. There was definitely a scare back in about 2022 to 2023 regarding block builder censorship, right? And this is like an intersection of the privacy legal issues and the whole like builder centralisation problem. So my view on the builder centralisation problem right now is that like we need Fossil um as a way of mitigating the mitigating it. Like basically what Fossil does is it creates 16 different actors per slot who have the power to force any transaction to get included inside of that slot. We get like very strong censorship resistance even if the entire block building market gets monopolised by one actor like not saying we should let that happen right but even if as a second layer of defense I know there are people who are working on multi-party block building technologies like basically market designs where blocks get built through the collaboration of multiple actors by default and if that happens that also helps kind of decrease the risk of single block builder dominance. That's strategy two and strategy three is like I think we should at least explore some kind encrypted mempool ideas in parallel.

To me those are the top three and I think if privacy is going to be first class importance for Ethereum it should be then like we needs to have multiple paths toward continuing to make sure that we have it right and also I mean in general like these things should be the responsibility of L1. We should not require individual like identified actors including builders or even including application developers to be virtuous, right? We should really ensure censorship resistance of the L1 and also we should do a version of account abstraction that is friendly to privacy protocols. 7701 for example does this and so that way Privacy pools and Railway and Tornado cash will be able to get rid fully of the of the public broadcaster dependency.

You showed a slide with a lot of things that could be paralysed like the reads, the rights, etc. Were those use cases what you had in mind when Ethereum came out with with Whisper? And if so because you also said that off-chain is good because it doesn't leak as much metadata. Is there a strong case for for the adoption of off-chain peer-to-peer like I'm going to say Waku? Would Waku make sense for a bunch of those?

V : Yes. Waku is a successor to Whisper. So Waku is very important work and I know it's already starting to be used in messengers. These things are good. I think Waku actually is one of the things that we should explore for the privacy preserving send RPC transaction use-case.

I do think that like Waku-type things are insufficient in a couple of ways. Maybe one or two years ago the vision for how privacy would happen is basically you would have things like the portal network and so you would you which would not just cover history it would also cover state and if you wants to make a state read then you would ask the peer-to-peer network and you connect to it through Waku and then it would give you back a Merkle branch right the reason why I think this is insufficient is that anonymisation is not enough.

Let's say I do a Railway withdrawal and I withdraw into account X right and then right before I do this there is in the network a query that goes to account X and also a query that goes to account Y right then what's actually happened is while there is information that is out there in the public that linked X to Y it actually doesn't even matter that theoretically X and Y might have been mapped to different nodes. Because even just those two accesses happening at the at the same time is still enough information to probabilistically narrow the user down to a very small number of participants.

For that reason we don't just need anonymisation. like we actually need a mechanism that allows users to do reads without those the the content of the read like the index or the address that you're reading being exposed to anyone except for the user themselves.

I view those two technologies as as being highly complimentary for the Ethereum use-case. Like I think for for this for the sending transaction aspect mixnet type things which includes Tor and ITP which which can also include Waku is indispensable.

Yeah I mean that is a legal question which is above my pay grade. Imagine there are definitely very passionate legal people who have been exploring ways to do that but I'll leave the question to them.

Talk about Waku again in back in 2021 I built a messaging app that was and using Waku and of the interesting things is that because the node was running in browser I didn't have to require the user to do some operation like run a node. What do you think about because I'm running also many nodes archive so I use my own explorer have my own RPC which is private but we have learned that people don't want to run their own so is there any way we could have something similar that says in order to access the service you have to even without knowing it?

V: I mean the challenge with the without knowing it part is that even a partial state node is going to take tens of gigabytes and you can't like ask people to download tens of gigabytes in the background without telling them because like at the very least it's going to like destroy a bunch of people's phone plans, right? I think the anything that is like seamless and fully in the background is something that realistically is just going to require um some kind of like light client based approach.

Now, what you could do potentially is you could have like an even more radical partial state node, like a node that only like stores the state of like say a privacy protocol and nothing else. And so it's obvious to the network that you're a user of the privacy protocol, but not but but they don't see anything else, right? And that's interesting.

That would be like one thing that is important to keep in mind. Right, but I mean in general I mean the other challenge of course of this kind of run a node without the user even knowing it is basically that then like if the ecosystem standardises too much over that then like users don't become aware of like what security guarantees they have. So the type of approach that I would favor is where this is related to the whole problem of embedded wallets in general. Where if you use an application with an embedded wallet then by default the embedded wallet does its thing but also if it detects that you have a browser wallet then it automatically switches over to the browser wallet and then the browser wallet can run the checks itself and give you a guarantee that you're being secure even if like the dapp interface has been hacked.

Just wondering about governance and privacy. I know you mentioned the on-chain voting as well as the fund transfers and kind of the important privacy elements there. Are there any other specific use-cases around governance that get you excited and where you think it's crucial to enable privacy?

V: I mean I think for me like governance is it's like often one part voting and two parts communication, right? And so having privacy preserving comms and having privacy preserving comms with the level of UX quality that people are willing to actually adopted and defaults to it is something that's very valuable. So I mean Signal I think has done quite a good job but also like Signal definitely lags behind other apps on at least some dimensions. I mean I know increasingly you've been seeing people migrating to Mattermost which is like self-hosted over Slack though which is like I think fine for the context of an organization for the context of something more diffuse like a DAO like you probably want people to be able to communicate in a way where the trust guarantee doesn't even depend on the operator.

Having like something stronger and sort of even more cypherpunkish would actually help a lot. That's one and then for the voting part basically every part of a governance process should be ZKed right and then like basically the principle is sort of only necessary transparency right so the the rules of the of the game have to be transparent and have to be very clear to everyone but in the context of the actions like only the contents of the action that need to be public would be the contents of the action that actually get made public. And like we can think about that as a starting principle. Apply that across all the different you know regular DAO voting, quadratic voting, quadratic funding sort of designs. I mean sortation is interesting also right because you should be able to have zk sortation where nobody else knows if you've been chosen right because if you have been chosen that's like a very easy coercion vector. We need to think privacy-first across all of these things.

Any work on reintroducing interfaces to allow for encryption decryption keys which might be derived from a root key via a standardized API. So, this is is this like the equivalent of what MetaMask did back in the day with giving you like an encryption?

V: Yeah, this is a good idea. This is actually not too far from some ERC's that have already been made. Like I think 5564 is the ERC for stealth addresses and stealth addresses implicitly depend on a public key encryption technology, right?

So if you generalize that only a little bit then you can basically have a system where each account can publicly show like what its encryption key is and then you'd be able to do encrypts to an account and I think that would be super valuable. Maybe as a portal app it would also be super cool to set a small defined restricted payload which can be decrypted right we don't need to make it big like a very small interface very clearly defined to just send something in for encryption decryption.

V: Oh, I see. So, you mean like the equivalent of a Zcash memo field? Yeah, I would support that.

Is Railgun ever going to lower their quarter % fee? Do you know?

V: I mean that's that's a question for them. Realistically for higher levels of adoption at some point they will have to but I think this is this is their choice.

Lots of privacy projects will help to corporations. How do you see the synergy between B2B privacy and sort of like human privacy and where are the disconnects between them?

V: So I think they share a lot on technology right and like enterprise privacy projects and my kind of look these sort of grassroots Ethereum ecosystem privacy projects have contributed to the same code on many occasions many of them are forks of each other there's a lot of implicit collaboration at the tech level often one thing that's happened in practice so far is that the B2B privacy use cases they've decided that for their compliance needs they have to have some kind of backdoor whereas I think for these more consumer oriented privacy protocols like there's been a strong standard of them being backdoor free and things like Privacy pools and Railgun that basically allow people to like publicly say I am not like one of these depositors like that's fine right but the thing that's not fine is a system where your privacy can retroactively be rug pulled, right? If you think you're private, you should stay private. And this kind of guarantee is incompatible with the kind of approach that B2B has been taken and like the B2B protocols compliance needs. So that's like probably the biggest disconnects that we've seen so far.

I mean my personal dream is of course that over time kind of norms keeps changing and the compliance needs on even the B2B side will start shifting toward more like a kind of privacy pools and Railgun style selective disclosure approach but that's something that of course we'll continue taking time but no I mean in general I do see those ecosystems as being very collaborative just because even if they make different decisions, they use like 90% of the same code.

What is privacy end-game?

V: Privacy endgame is basically that like you should be able to have your digital life without revealing information to other people that you do not want to reveal or that you do not know you're revealing. I think privacy is also valuable in physical space and like I definitely do not appreciate all of the people that just like randomly I mean like photo me and then put me up on crypto Twitter and then there's like people talking about like oh you know like this is what Vitalik is doing now. Unfortunately those kinds of problems are kind of outside of our area of expertise to solve.

The domains that I think will matter over the next two decades right I think are like especially as physical privacy keeps decreasing digital privacy needs to keep increasing to compensate and this involves privacy of communications this involves privacy of funds transfers this involves privacy of governance operations and ultimately like those three things you know they're not entirely separate categories. They're a continuum, right? Like any funds transfer is at least in part of communication. You know like any communication is at least in part a governance operation, right? But then other categories that will pop up privacy of AI so AI is like increasingly becoming sort of a second brain and like chatGPT seeing all of that as something that should not happen.

Who here, has a local LLM installed on their devices now? You should. Who here has bought a some kind of computer or GPU specifically to be able to run better local LLMs? Okay.

One thing that you can do by the way that's like actually economically optimal is buy something powerful but share it between you and a group of your friends, right? So like for example like if you look at a Mac studio the if you with top end specs like the cost does go to the crazy side it's $12,000 but the way the thing that the property that LLM use has is basically you're only actually using it like 1% of the time right and a full-size Mac studio is actually powerful enough to run full-size DeepSeek at a very good speed and so one thing you could do is you could basically take one such device and basically give you know yourself and a few a few or like or a dozen or a few dozen people that you know like you reasonably trust access to it, right?

There's a lot more experimentation with kind of local and even kind of going up to the larger model is a good thing. Because yeah the AI is going to become more and more a part of your thought we're also going to get start getting BCIs very soon brain computer interfaces and so privacy of BCIs is literally privacy of your mind basically you know privacy will go down a lot if we're not careful and if we are careful and if we do the right thing we can keep it at a similar level or even increased and I think this is a very valuable project to push for.

Can you share the perception of cypherpunk within two years because the first year once you published the article and I'm just checking a Devcon talks only Peter Van Valkenburgh from CoinCenter was the only one talking about the cypherpunk then some B2B companies were exploring like how they can talk about this what legal would allow them to talk about and what's the state of this cultural shift and change.  

V: This is actually a very good political moment to start talking about cypherpunk and privacy topics more openly. And I think this is actually true for a couple of reasons.

One of those reasons is that the just the global political environment is much more unfriendly than it was I mean more than two years ago, definitely more than four years ago and like way more than than 10 years ago. And so the idea that you know, oh, you can just go run one of these centralized things and it's run by like nice idealistic tech people and like they're definitely not going to do anything bad or get captured by people who will make them do anything bad is just like more obviously completely false. And this is not something that like grassroots rebels care about. This is something that institutions care about. This is something that governments care about, right? That's like one thing.

In this kind of like much less friendly and much more unstable environment, having more sovereignty over your own data at an individual level and at a group and community level is more important. And the other thing is that like there are people who have talked about the current era as being an era where you can just do things. And sometimes of course this is bad because just doing things sometimes involves just shooting missiles.

At the same time from an individual point of view like you know you can just do things does mean you know you can just go and make privacy protocols. You can just go and send people $10,000 without telling anyone and like you can just really go much further in asserting your digital rights than people were comfortable with a few years ago. And there's like basically from both of those angles. The need has increased and the opportunity has increased and supporting kind of personal and local community security and seeing privacy as being a core part of that security is something that is very important to I mean both talk about and make a reality right now.

Since it's very important for you to keep your thoughts private and you run a local LLM how do you deal with the your location privacy?

V: Yeah, currently not well. I do not claim to have good solutions.

And one of the challenges here, right, is that like even if you do you know like burner phones and literally rotate them every month like even a month of data is totally enough to uniquely fingerprint and identify you. So it's a hard problem.

If you want to like really go further out on location privacy then like we will have to figure out kind of lifestyle alternatives to having your internet constantly with you on the go that provide something close to that level of quality and like that basically means much more accessible mesh networks that might even mean kind of more piratey stuff like something that automatically connects to Wi-Fi networks and automatically does the click through and like you know like goes through passwords or whatever. You need an alternative to that for connectivity is probably the number one thing but then even kind of beyond the the beyond that right the other thing is just like the ease of in person surveillance and just all of the cameras that are everywhere right and the more realistic thing to do is to just kind of continue to fight for laws that kind of restrict those kinds of things and like and put controls on them, right?

People can get around them, but like it like every single one of those things does push the people creating the cameras to be more careful and to kind of not be as brazen in data collection or in like in letting the data get leaked. But no, going further beyond that like I definitely admit it's a challenge.

What's your opinion on the how privacy projects can reach product market fit because we're talking with the folks on the scene and only barely a few for example for Railgun it took three years to hit the break even barely any self-funded project of three people can reach this state for Rotki is based on the personality of Lefteris and there's not many people like him so what how would you suggest privacy builders to go post hackathon in their way to find that product market fit.

V: We should learn a lot from Signal, right? Signal is like the one reasonably cypherpunk project that like actually has gotten a huge amount of adoption to the point where you know famously even the US government uses it. That's Bitcoin. Well Bitcoin I would not call Bitcoin a privacy project right. We should like from from my point of view like what succeeded with Signal is like it actually does have a good enough UX that it's a kind of like maybe like 80 to 90% capable drop in like Skype or Telegram replacement and then like that's good enough to the point where like basically you have these spikes of adoption that happened you know Snowden revelations and then the whole like Pavel Durov situation last year and like basically every time this happens more and more people become interested.

But in order for that to happen your project has to be ready for it right and so to me like one of the warnings is basically just improve UX right though I mean at the same time where like even Signal is like it's definitely not strong enough on the metadata privacy and so we do need to keep pushing harder there.

Usually developers when they do hackathons overscope what's possible within three days. What would be the the low hanging fruit in terms of dev hours spending on privacy.

V: So if you want to work on like for example PRI then one simple thing is instead of focusing on state you focus on history and the easy problem that you do is basically that the input is a log topic and the output is and basically the client asks the server give me what the log the one log in the previous block that is compact that has that log topic and then the server rep like scans overall of the logs in just that one block. So that's like a set of size 100 to like maybe between 100 and a thousand then replies back with that like if you just have that like that already is the seed of privacy preserving history query and like that's a thing that I mean I think especially in the GPT era lots of people here are very able to go and vibe code um well or hopefully the you know like locally running DeepSeek like 0525 or like whatever the most recent one um era um so then If um you know we're talking about like ease of use then like build a wallet that like creates a one-click experience for Privacy pools or Railway operations.

Then if we're talking about like ZK voting, actually fork one of the some DAO-like governance framework and basically rip out the backends and make it private. And otherwise, make it look as close to identical as possible.

I think that's kind of roughly the the bite-sized chunk you'd want to do for the hackathon.

What are your thoughts about whistleblowing rights and how they intersect with privacy data?

V: Yeah, I mean in general I think whistleblowing is absolutely important and I'm generally a big believer of know Julian Assange's maximum, maxim of privacy for the weak and transparency for the powerful and I generally think that like actively forcing powerful organizations including companies including governments to be more open than they otherwise would be is like actually one of the more important counterforces to reduce the risk of like some kind of single actor dominating the world in in some irreversible way in the future. To me whistleblowing is definitely an important part of that. One area where ZK tech would help is it can actually make whistleblowing credible right because not only can you reveal information but you can reveal information attached to a zero knowledge proof of the truth of that information.

What do you think about zkTLS for? zkTLS is good. Yeah, you should use it.

Thank you.

Note: speech has been turned from video to text & modified for reading experience. If you saw any conversion artifact - contact us.