Paths to a Private L1

Transcript

Oh, okay. Cool. Yeah. Uh, I'm Jos. I work at the EF. Um, and I'm talking about paths to a private L1 today. So, on the straw map, one of the Northstar goals is listed as a private L1 defined as privacy as a first class citizen via L1 shielded transfers. and I wanted to find out what all of the possible research directions are that could lead to a private L1. Like I wanted to enumerate all of them, the good, bad, and the ugly solutions. Um, I have a full write up on my Twitter that I'll show at the end, but this talk was going to be very very quick run through of like about half of those topics. Uh, I don't really have time to get into the blockers or like how it works, but I'll give you like a

highle overview of some of them. Uh so first I'm going to talk about the directions that are being actively pursued today that are being actively speced and tested and uh that's like in the near term. So first we have Kohaku. Kohaku is an SDK and CLI for interacting with application layer privacy on Ethereum. Uh there's a demo of it later today. Definitely go check it out. And uh Kohaku is mainly aimed at wallets to integrate. Um, and an interesting feature is if all wallets integrate Kohaku and all wallets also make Kohaku the default way of integrating with Ethereum, it's very similar to actually having privacy at a protocol layer with, you know, some caveats. Um, next we have the relayer death stack as I like to

call it. This is a collection of EIPs headlined by frame transactions that basically make it so you can withdraw from a private privacy protocol on chain from a fresh wallet and it can go through the public mempool. Uh with some caveats, but this is like steroids for like all privacy applications on Ethereum including Kohaku. Uh stealth addresses super cool cryptographic technique for uh sending somebody some funds. You basically if I want to send funds to Bob, I can generate a public key for Bob, send the funds there, and then Bob uh and only Bob can generate the private key for that public key. Um unlin from the rest of his things onchain. Uh next, these are some topics that are like a little bit further in

the future, like they're speced out, but they might not have enough consensus to act on them yet. Or some open questions. We have lean staking. Uh it's an interesting EIP that's mainly about validator anonymity uh by turning the deposit pool into a shielded pool. But what we can do, we going to shoehorn transaction privacy into this if we also allow non-validators to use this shielded pool. Um so it would be a very strong anonymity set because you have all of the validators and all of like the Ethereum stake within within this anonymity set. A really cool feature is that you get plausible deniability where uh you can't tell if an address interacting with the shielded pool is a validator or is simply making a private transaction. Another idea is enshrining a specific shielded pool uh to Ethereum.

And what this would look like is you basically take like a smart contract on the application layer and turn it into a system contract. Uh this idea is talked about a lot and it's kind of a decision of like would we want to do this or just let it live at the application layer. An example implementation of this is EIP8182. And then the last group uh that I have written up is kind of like the experimental zone. These are the ideas that are like blocked or have big open questions or like not really written up anywhere. These are like the more fun ideas I think. So the first one is ZK wormholes. This is a fan favorite. Uh the idea is you can send ETH to an address that you provably don't have access to and then the protocol mints you some ETH to some other address and

it has very strong plausible deniability because you can never tell if any transaction is a wormhole transaction or just like a regular transaction. Uh unfortunately there's a hard blocker where Ethereum execution layer addresses are actually too small. Uh so you end up in potentially like a double spend. So it's pretty hardly blocked. Um, another proposal is Vitalik's extremely lean chain. This is just an ETH research post and this is also it's mainly targeted towards like validated anonymity and state minimization. But we can shoehorn privacy into this one as well. The idea is that validators don't actually have like a registered pub key on chain. They use a new pub key every day and generate a ZK proof to reprove their balances.

Um, and if we have an enshrined shielded pool, we could require validator withdrawals to go through that shielded pool. And then we get the really strong anonymity set of all of the validators and everybody doing uh private transactions at the protocol layer. Uh, and in addition to that, you get um plausible deniability of not knowing whether a shielded transaction was a validator or uh just a regular transaction. Um, I'm very over time it looks like. Uh, but the full talk is on my Twitter. Uh, check it out. I have a lot more information and a lot more uh topics on that. Thank you.

>> Great. We have the Q&A session. Who has any questions? Raise hands. Anyone have any questions? >> Uh actually I have one. So out out of all these sort of the proposals, which one you feel like >> is the most um urgent sort of we need to solve? >> The most urgent? >> Yeah. >> Well, there's like there's things that are like what easiest to implement would be things on the application layer. Uh like Kohaku that'd be easiest to implement.

Like what would be the coolest I think to implement is some sort of like base layer privacy by default. Like one of the ideas that I uh didn't have time to talk about is just the idea of like a uh all EOAs are private by default on the base layer. I think that would be the most cool. I think any notion of like privacy at the protocol layer is pretty urgent I'd say. >> Yeah. >> And um just Andre mentioned about question. >> Oh great. >> Hello. Hello. Okay. Um do you see any risks like um if we have like too much privacy on on on Ethereum like that it becomes like a Monero and uh and get

blocked on on on um central exchanges and like with additional requirements. >> Um I mean there's a lot of privacy protocols out there that like are accepted um by uh centralized exchanges. I I think I'm more concerned of what uh you know I'm a big believer of like privacy as like an inaliable like human right so I'm a bit less concerned with uh like how to handle like the exchanges I'm not sure I'm not sure but maybe yeah okay thank you >> um I have one more question since you are here uh Justin this morning just announced like u to prioritize like the PQ for this Ethereum L1 road map um how

much do you think it will impact >> PQ? Well, I didn't get to talk about it in the talk, but PQ is actually a large blocker in a lot of these uh privacy protocols. So, like working on PQ and finding PQ solutions is kind of the first step to a lot of these ideas that I was talking about today. I see.