Ethereum Privacy

Transcript

Um, yeah. Um, I think yeah, this is going to be a a bit of a more high-level talk. I want to talk you to you guys about like the plans we have for privacy on Ethereum. Uh, mostly from a protocol perspective. Um, so yeah, I'll start with the Okay, also feel free to interrupt me anytime. Um, it's a workshop, so uh, hopefully we can sort of have a a bit of a discussion. So, I think the global overview for what we're going to do in the short to mid-term is um, to try to get what we call native privacy on on Ethereum. And that by native we mean um, something quite specific. Um,

basically what we want to give um, private transactions is all the properties that can be guaranteed by uh, the Ethereum protocol. Meaning we want them to be trustless. We want let them to be censorship-resistant. And we want them to be you know, post-quantum secure and then cheap or at scale. And so, what we're going to do um, first is a bit different from approaches like um, Zcash for example. Like we're not going to enshrine like a single pool. Um, what we're going to do instead is like we're going to let um, a bunch of privacy apps live on Ethereum just like today.

But we're going to remove all the sort of like hurdles and and things that make it um, quite bad. Um, so one of the obvious things that make it quite bad today is um, basically because you have the account model and um, you need to fund your account with um, gas that's in ETH. Um, there's no really way around it um, that leaks like who you are. And so, what people do today is like they basically the video they build their transactions and they send it to like a third party. Let's call like a relayer or like a broadcaster. And that third party will basically submit it on your

behalf. And that's how you sort of you deal with it. So, instead of like sending it yourself, you have that other sort of like third party sending for send it for you. And it works-ish in practice. But of course, like that third party is can be unreal- unreliable. Um and, you know, they can go offline, they can censor your transactions. So, it's it's it's very just like not ideal. And so, you don't like the private transactions today do not hinder it like all the sort of full protocol guarantees that they could, uh which is a bit annoying.

And so, what we're going to go for is like, you know, you'll have like many apps, um privacy apps, which makes sense also because like Ethereum is programmable. Like I I mean, maybe yeah, I don't think it's controversial to say like on Zcash just transfer. So, it makes sense to enshrine like the one pool that like handles transfers. But like on Ethereum, you can actually sort of sort of like do a lot of more things. Um so, it makes sense to allow like more apps to exist. But each of the transactions that are coming out of these privacy apps should still like sort of like inherit um and benefit from the full protocol guarantees.

So, that's what basically we are going to go for. And I'm going to talk a bit about like what's the the the plan. Um also, we can also discuss the trade-offs because of course, like there are trade-offs. Like if you have many privacy apps, um it's sort of like splits the anonymity sets. Um so, you have to maybe like find find a solution for for this. Uh okay. So, this is the I guess the near-term plan. Um what we are planning or trying to to to ship for for Hegota, which is um not the next fork, but the next fork is going to come very soon. So, it's like fork n plus n plus one.

Uh hopefully mid-2027. Uh we'll see how that goes. But basically, what we're going to do is trying to get these EIPs through. And each of these EIP basically gives private transactions uh specific properties. Um the one that completely unlocks the the design space is EIP 8141. You might have heard about it. It's been like I don't know. It's been We've been working on this for 4 years. Like I think 7 or 8. It's like the native account abstraction EIP. And so, what it allows you to do is to basically um have transactions that are like now completely composable and programmable.

Um and instead of um having this sort of like fixed rigid code, uh you can now have a friend tran- friend transaction where you set um you know, the sender and the payer of the transactions to the address of the pool or like the privacy pool or the app. And you get rid of basically this sort of like problem uh where you need to trust uh a third party like a relayer to um to to unlink yourself from from from that transaction. So, that does most of the job. Um incidentally, it also allows you to use, you know, PQ signature schemes. Um so, yeah. It's a It's a really cool sort of like EIP overall, but it's very useful for

privacy. I think the sec- like the two EIPs in the middle I are basically um add-ons to [snorts] 8141. Specifically targeted to make privacy work. Um so, a good example is like um key nonces or two nonces. Um basically, if you know, you have like a lot of people that want to send out transactions and they use the privacy app as the sender, you have like nonce conflicts. So, because like they will all sort of like aim for the same nonce, but there is only one. Um so, you need like key nonces or two nonces to have like parallel transactions that can come in the mempool and still be included in the same block and for that you need an

EIP like hidden nonce. So, those are like small improvements over all like private transactions to make privacy specifically work. Uh recent roots is also about posting the the Merkle roots uh for the private notes uh in the in the same place so it can benefit EIPs like fossil. And fossil is not privacy um it's not only for privacy, it's more for for transactions generally. But what it gives you is like this sort of like unstoppable property um extremely good inclusion guarantees um which um is great because now for public or private transactions, when you submit it in the mempool um you have a way to force include most transactions that are coming through the mempool to

make sure they actually end up being in a block and you don't have like these sort of like big builders that we have in Ethereum today that can censor them. Um and of course we want to give that property to private transactions. Um so that's why I put it in the in the sort of like Hegota bundle. Um Okay. Um another like thing that we are thinking a lot about is um how you know, I think we talked about it like in an in an earlier session but like it's worth thinking about like the whole broader picture and not just the protocol.

Um and so you know, today you already have like privacy apps on Ethereum. You have Tornado.cash and uh privacy pools, you have um uh Railgun, you have a lot of them. And what we are doing is basically a lot of research and prototyping to make sure, you know, when we ship these EIPs in Hegota you have like the private private applications that exist on Ethereum today um [snorts] can upgrade and benefit from it because if you ship something at the protocol level and no one uses it, it's a bit pointless. So, there is uh quite a lot of work going into that.

Uh um you know, you have the wallet um and and there is a lot of work uh going >> [clears throat] >> uh on to the wallet as well, mostly from uh the Kohaku effort uh and and wallets like Embargo that have like um try sort of like that are trying to integrate Kohaku, which will be an SDK that can be sort of like integrated by all the wallets um to give users like um sort of like easier user UX and end time um dealing with a with with privacy.

And so, it's kind of fun, but like now we have all these initiatives um that we are trying to sort of like experiment experiment with so that by the time we ship Hegota, we have like, you know, uh a full sort of like end-to-end UX experience and flow for for uh Ethereum users. Um okay. Let me take you a bit of water. Uh Yeah, and then the next priority is um PQ and scale because yeah, I've talked about all the things we want to ship uh for Hegota, but that's not going to be cute just because we are waiting

on core elements that we just like don't have. And the core elements are, you know, LinVM that uh Emil already talked about a bit um uh and a bunch of other things that I can talk about now. But basically, there is this EIP that's called um 8288 and that was written by by Vitalik. And it what it does is like it uh completely changes the way we're going to think about transactions uh and the mempool and um Ethereum I guess in in general on the execution layer um by having these sort of like um dependency frames.

Um So, I talked about frame frame transactions and now you have this specific uh type of frame within frame transactions that are basically just like um linking transac- transactions to proofs, but but proofs can be independently sort of like broadcast in the main pool and every main pool node will be recursively aggregating proofs and then propagating it around until it just um uh sort of like converges to that sort of like final proof block. I will also show a an animation later on um so we can visualize it a bit more, but um I I still want to sort of like

say that it's it's still work in progress and we have quite a lot of different things to to do. Um one thing is the NVM, so it's like it's going to be the core engine. It's so like critical to everything we are going to do on it in on Ethereum at all the different layers. Um there is the networking part because aggregating proofs in the main pool is like something we haven't really done uh before. There is uh client-side proving because the the the users will be the ones sort of like generating the proofs and we need to make sure it's uh viable.

And then um yeah, we need like a sort of like crucial part of this uh which I looked a bit into this like this past few weeks is uh exposing an ISA. Like we need to expose an ISA for users to [snorts] write their code in and that's going to be a big part uh big big discussion because right now only the EVM is exposed and you know, whether we want to expose RISC-V or like a custom ISA is like a still a an open question and you know, if people have thoughts, I'm I'm curious to hear it.

Um Yeah. Okay, so this is the animation I wanted to show. I don't know if it's going to work, but okay. It looks like it's working. Right, so yeah, this is a full flow of how I imagine the future is probably going to look like on on Ethereum for for privacy um or private transactions. So, you have you know, Alice with the witness that's hidden.

Uh you have the public statement. You have the relation that's um sort of like specified by the the pool or the privacy pool. Um and then you use uh LinVM. Oh. Wait. Okay. There are some things that are missing, but whatever. Uh you you generate a proof. Oh. Here it is. Okay. Uh you generate a a proof. Uh and then basically what happens is like you you're going to build your frame transaction. Um yeah.

You're going to build your frame transaction, and you can see there are like verify frames. You have dependency frames that I talked about. And you have the sender frame that's about sort of like execution and and the code data. And what you what you do um is uh yeah. You need to sort of like um check every parts of the transactions uh every part of the transaction again the the against the pool rules. And once you do that um you can see [snorts] how Let me use the Yeah.

I think this is the interesting part. Um Basically, what you can do is Okay. Sorry. The the video is actually not working super well. But what you're going to have is like your transaction and alongside it you're going to have a proof. And the idea is that um the proofs are going to be recursively aggregated and propagated through the mempool. Um uh and you know, until the block builder actually gets and constructs this this sort of like final proof um that is going to link all the transactions uh in the block so that validators can just verify one proof, check that it it's sort of like uh

it works for all the different transactions in the block. Um, and yeah. And so that completely sort of like changes the the the idea we have about the mempool today. And uh yeah, I was hoping this was going to be a smoother thing, but >> Uh I I have a question. >> Yeah. >> Um, so if nodes receive transactions in a different order, >> Yeah. >> how do you stop them aggre- ending up with different aggregations and then the final aggregate includes a transaction more than once?

>> Uh yeah, so you have a way to exclude transactions. Um, so you get the you get you get your transactions, you get your proofs, um and then, you know, if there are like some more transactions that are sort of like coming in, um you just like at the end of the day, like every node will still have to reconstruct a a new proof um that is including more transactions. So, that the fact that you're reconstructing the a new proof doesn't really change, right? Like uh and then on only the builder is basically responsible for choosing the ordering, but the mempool nodes don't really care because um they are not going to be in charge of the final ordering. So, in on on

Ethereum, like the block builder still, you know, has the power of uh extracting MEV basically and ordering transactions as they want. But the the mempool nodes are supposed to do something very mechanical because they don't extract any sort of like profit or benefits from from doing it. So, you get the transactions and it doesn't really matter in what order they are. You just build your proof and you propagate it. Um, and yes, it will create like a different proof if you have like different transactions in different order, but it should like mempool nodes shouldn't care, really. >> But But doesn't that mean a lot of duplicated work?

>> Um, I mean, yeah, if you but if you if you receive uh a proof for transactions you've already seen >> Mhm. >> and you're not adding more transactions to like the new proof you want to generate, then you wouldn't do it. >> Okay. >> You know what? Like Yes. >> How would fee pay Is fee payment public? >> The what? >> Fee payment. Like I'm doing a private transaction. Does everyone know that I'm the one paying 0.01 gas?

>> Uh no. So, that's uh what changes even like starting with Hegota. Basically, the the the fee is going to be included in um your statement. Um but the sender and the payer are going to be set as the privacy pool, so as the app. So, you there is no way and and you know, they will pay for your gas and they will extract uh you know, get compensated by the fee you've attached in your statement.

But but so, you have no way to sort of like actually know who was behind the transaction. Um >> Can you get fee refunds as well? >> Exactly, yeah. Yeah. >> So, your refunds go to privacy app and then in a future transaction, the privacy app would send it back to me as I claim it or >> Uh yeah, you So, basically, as long as you set you the fee in your statement high enough so that the pool can pay for you, you you you'll you'll get refunded by the pool. >> Is the refund a separate transaction or same?

>> Uh it's uh same transaction. It's in the same transaction. Yeah. >> We talked about infrastructure in the in the previous session. So, how do you think about who's the maintains the mempool, who does the aggregation? >> Yeah, I think it's one of the biggest question and uh you know, I I uh I was asking questions about Dcash about like who how interest introducing new new new trusted third parties.

Um yeah, I I think we'll need to benchmark it. Hope The hope is that, you know, mempool nodes with the their hardware requirements today can have like minimal overhead in doing that aggregation and that they can all do it. So, you actually get like the sort of like, you know, same guarantees, but if it's not the case and we need to introduce like special case rules for aggregators and they get incentivized, then we are like back into the same question of like, yeah, you introduce like, you know, new trusted third parties and I think it matters a lot because

um the mempool is what it's what's supposed to give you the censorship resistance you want. So, if it's bottlenecked by a few aggregators um because they have special rules and like dedicated hardware, you lose the guarantees we have today. So, it's a it's a big trade-off to make. Yeah, so hopefully we won't get there. Like the the goal for now is to be very optimistic and say, "Hey, um it's going to be a minimal overhead and mempool nodes can all do it." Um the idea also is like that mempool nodes will, you know, maybe propagate proofs every second or something based on their capacity. Like um so, you you prove all you can prove

within like a given amount of time, um but if you have like lower hardware and you're not like super super performant, um it's fine. Like you'll still like you'll prove less and still generate a proof and help uh the mempool. >> And which as a follow-up like which is the key uh bottleneck here from your perspective? Is it Is it uh bandwidth? Is it the or is it the execution speed of the for the aggregator Yeah, uh themsel- Like what is the If you had to sequence or prioritize the the the bottlenecks?

>> I mean, with B Q, I think it's bandwidth um because yeah, proofs are large, signature signatures are large, uh and that's why we are doing this sort of like recursive mempool aggregation in the first place, right? Like, if if signatures were small, if proofs were small, you you wouldn't even you would stay with like closer to what we have today as a model. Um so, yeah, I think the bottleneck is going to be bandwidth for sure, um and we need to optimize it away. Um >> So, so how do you measure the trade-off between mempool nodes doing more work >> Yeah.

>> and the benefit of the bandwidth improvement? >> Uh yeah, I mean, it's uh I think it's a performance versus uh censorship resistance trade-off, basically. Like, >> I see. >> It's you need to optimize for one and you need to land at a point that fits like what people expect from a a given blockchain. But like, if you increase, you know, like the performance of of mempool nodes, like then less mempool nodes would arguably be able to do it, and you'll reduce uh like, you'll increase throughput.

>> So, so is it okay to make being a mempool node more expensive in order to um get more bandwidth? >> Uh I mean, I would say well, I would phrase it differently. I would say like, I don't think it's okay, but people will have to decide where they where we land on the trade-off spectrum. Like, I hope we can keep mempool nodes as they are and still make make it performant enough so we have like decent throughput on Ethereum. But if we can't, we'll need to sort of like find uh other solutions.

>> I mean, I guess it depends on the cost of the um recursive proving. >> Exactly. Yeah, that's why we need to make it like as efficient as possible, basically. Um yeah. Uh yeah this uh uh This is a you know a road map with all the things we are thinking about uh for the privacy on the protocol side of things. Um one thing I didn't talk about but that also links to people that were here in the morning is that um for handling nullifiers because you know it's state that can never be deleted which is very annoying.

Um we thought of doing it the Taiko way um but we think we have another cool idea is to use um Bloom filters. Um and so yeah. I I think actually like um other chains could sort of like do it as well. Uh and if you're interested um we can talk about it later but the idea is basically that you can instead of like storing all the nullifiers you store you get a a Bloom filter and so you don't have to store the whole thing and it can still allow you to determine with like full confidence that you this you know this nullifier wasn't seen before uh which is pretty cool uh for for scaling without having to introduce yet like another

sort of like third party in the mix where you know you're trying it's like in the hot path of you trying to submit your transaction so um to come back to this morning we could have like light uh OSS nodes uh that are like just storing like a lot less state basically uh which is I think kind of cool. Uh yeah. That's it. Thank you.