The Ethereum Privacy Stack: Private Reads, Networking & the Hidden Leak

Transcript

The fictional RPC provider letter

Hey everyone. So I'm Andy and um wanted to introduce a topic that I think it's not often discussed in the Ethereum ecosystem and it is uh extremely important and as you might have uh noticed from the the side and the present the the introduction it's related to privacy and how we are underprotected and we don't even notice. So let me start with uh a letter that I that someone wrote to you guys. Dear valuable user, thank you for your 847 queries that you did this month. We really enjoyed getting to know you. We know that you hold ETH across three different wallets. We know that you checked the price of ETH 94 times last Tuesday. It was a very rough day for

everyone. So, no judgment. You also check the price of bit uh BTC price, but uh it's interesting because you don't hold any Bitcoin. Are you thinking of diversifying? uh that will be between us and of course our analytic partners. You are also watching two unis swap pools very closely and you check your avid health factor 14 times last week. You might want to relax or just add some collateral on Thursday. You also check it three times within 12 minutes and you were very worried. you lo you looked at uh four different ENS names or either you're starting a new project or you might have an identity crisis and you always go quiet between 11 p.m. and 7 a.m. Mountain time. So we're fairly confident that you're based in Boulder

How you leak data without signing transactions

or close. You never sign a SQL transaction through us. You never had to. Your curiosity told us everything warmly your RPC provider. So of course this is a fixtures letter but something that we do leak every day. Even if you're not doing any single transaction, any action on chain, you're basically telling everything that any analytics and company will love to get uh their hands on that data and and your your behaviors. So what is really really going on right now in the privacy world? I see that we put a lot of emphasis on onchain privacy or what we in PSC called uh private rights like all the actions that you do onchain and it makes sense, right? those

actions get recorded forever. It gets transmitted around the world. So it does make sense to not leak your address with a specific action. And we do put a lot of emphasis on tooling as well, right? Like your data sources um your I don't know proofs and and DSLs and languages that we can use to more give more tools to developers and express and build uh stronger apps that have more privacy onchain. But I want to argue in this uh presentation that we don't don't put nearly enough uh attention and effort into these other domains which is what we call private reads which is whenever you query data from a blockchain you're leaking a lot of information and private networking even before anything arrives onchain all the traffic all the things

Private writes vs private reads

that you do you're leaking and to get a little bit slightly more technical right like all the RPC calls like fgget balance uh f call if call and if get log box. All of those things are requests on the plain text that go to RPC providers that get related with your IP. And with this information, it it becomes very very easily to profile people to segregate segregate and to create behaviors. And this can be used against you. As you would imagine, um, information is power and the more p information people have about you and your behavior, the more power they have on you. And most people don't realize and most people will say like, okay,

well, uh, it doesn't really matter because this is not like critical information or it could also think like the more activity there is, the more protected I will be, which this is entirely not true and counterintuitive. in onchain actions or whenever there's anonymity sets it does help that the more users the more privacy there is the harder like you blend in into people but with these things because things are more uh they're not interchangeable uh the more activity you you transmit the more things and actions you do the richer the correlation surface and the easier it is to create a profile about your your actions so whenever there's like defy mania like you know NFT craziness and all these things people become more sloppy OBSAC of course gets

Why does more activity increase profiling risk

thrown out of the window and it's much much easier to dean anonymize people based on these um activity patterns behaviors that that most people just fall into. So I want to start um high level well some technical aspects about how is this landscape and where should we attack it what what's needed who's working on what this is a a talk that I'll try to go some topics like more technical and subtopics more high level conceptual so you can take some some value out of this for for everyone so I want to present this uh which is what I call like the Ethereum privacy stack or the layers of the Ethereum privacy stack and I think this is useful to reason about If we really really want privacy, we don't

only need privacy onchain, but we also need privacy in all these layers of the stack. Similar as you can see like I don't know the life cycle of a transaction um the OC model and all these you know technology layers. I argue we could um create a standard or some sort of like ecosystemwide acknowledging that there are some layers. Maybe this is not the final form but I think this is arguably already useful. So the top is the application layer. So whenever you visit a website of course you're leaking what you're visiting right and people can start profiling anonymity sites credentials they can start linking to your IP where you're visiting even if you don't even you know do anything right the next one is the wallet layer whenever you do any action you don't only leak information

to the app layer but also to the gateways whenever you do an action at the wallet level and while it's right now are very complex and they integrate with so many other systems and services and you leak a lot more information than what you imagine. Even if you just like open your wallet and query the price of ETH or open your wallet as your balance, you're leaking um everything. Um then you see gateways, you know, the RPCs, the the proxies, the relayers. Um you leak again more metadata. Um then, uh what people would imagine as the the onchain element, which is whenever things are queried on the on either on the EVM like the state or the execution patterns. So for example query the

Introducing the Ethereum Privacy Stack

balance of something or if you want to see the state of a smart contract uh this is the layer and finally the consensus where is like all the validators depending if you're writing things onchain or if you're reading onchain uh you might also touch the memple of course so this is just some examples and there's like another vertical which is what we call networking which is transversal or like cross cross layer like cross cutting all these layers right so for example uh right now you visit a website and the server knows your IP but what if you visited that website through tour or any other you know on your network you would know the IP address of the website but they wouldn't know yours but what if that um IP is uh hosted in a in a

country where recently you know started censoring all crypto things probably that website and that company would also want to hide their IP and would also want to hide their domain behind like a onion uh domain you know So those are the type of things that it does make sense, right? We need to go layer by layer hardening everything, analyzing through the eyes and lenses of like a very disruptive um attacker who wants to censor everything. And this is the type of things that even if we don't do it and and we say like oh we live in a good enough state. Um this information gets recorded now and forever will be hosted by a lot of people that you don't even know, right? a lot of companies that just get like start selling your data and eventually in 5 years somebody

Application layer privacy leaks

might ban might ban like crypto and we'll say like oh anybody who used unis swap in the last 5 years I'm the IRS I'm going to you know start knocking and like get you to jail or whatever right like these dystopian scenarios which happen in the world right now in different countries around the world so this is okay if you're in privacy stack uh where should we focus in this uh presentation I want to talk about these two areas right like the private reads which is like whenever you access state from onchain you talk you you touch all these layers right from the app let's say I want to query um the price of ETH from the app to the wallet to the gateways to to basically a node that is running Ethereum if you know the EVM and then back from the database and uh or or

Wallet layer metadata leakage

well yeah basically it's a RPC provider or like indexer or something and then the private networking which is all the actions that happen um you know on on the networking layer And this is what we want to harden. So there's three pillars that that I think they are critical for us to achieve this. We want to hide and make private the data itself. We want to hide and make private the traffic itself. And then we want to make it uh very performant and and and useful and practical and cheap and all of these elements. And these are all you know this is summarizing a lot of like information and things that are going on in the ecosystem. But I think it's useful to kind of like you know paint the lay of the land and what are the most uh the leverage points that we can

RPC gateways & execution layer exposure

do to to accelerate. So data what is it that we want to protect? We want to hide what information you're asking from these servers. We want to hide that the the patterns that you do uh through accessing this data. So not only the content but also the the patterns that you do and there are different techniques like um well the the principal technique is you know there's nothing right you you just leak everything you leak like whenever you connect your wallet you tie your IP address with a contract that you're querying with a specific if balance um if address and that's that's it right um if you're even if you're in a privacy protocol let's say in tornado cache and you want to query uh the state of the

Merkel tree and if you if you leak what is the path that you're quering uh the leaves you either have to download the whole tree which is like not very performant or you leak your path reducing your anonymity set. So again even just using a very privacy protocol like tornado cache is not enough you if you don't protect your networking and your access patterns from data. So one is like no protection. The other one is okay some sort of like proxy relays you know you have a lot of machines that just like they don't know where the request comes from and they just eventually retrieve that. that's not very you know it's not very practical and and not very uh trustless then you got tees which is a step forward and there's this is where I think some teams are are um offering these services

Networking as a cross-layer vulnerability

companies and I think this this is a good step forward but not enough uh again because of the cost of um attacking TE is dropping a lot and and corrupting and perhaps for certain critical use cases this is not enough for many others day-to-day it could be enough there's other teams talking about OMAP oblivion use map axis patterns and oram um can't remember what it stands but these are just like similar techniques where where it tries to obuscate what parts of the data set you're trying to to access so instead of you know saying I want to access um the balance from this if address until this if address the server doesn't know you know you you're just like randomly accessing

Three pillars: data, traffic, performance

different things and the I would argue one of the most um you know the endgame uh of these will be PI which I will go into more details but it just means private information retrieval which means your ser the server doesn't know um what you're quering and doesn't learn anything about about it okay uh so private information retrieval is like a super powerful technique uh in cryptography and it's going to be used a lot there's just two variances like indexp where if you have like structured data under index if it's indexed uh you can use those schemes or keyword P which yeah as the name tells like you query per keyword is very hard to have one scheme that works for everything.

Ethereum state is huge uh is very different like logs yesterday I was you know learning that it's just like append only but the account model is different some gets updated very frequently some don't um and and some can be depending on how you slice and dice you can have megabytes of data terabytes of data gigabytes of data so and yeah and very different like patterns of like numbers and you know ask etc. So the proposal that we're working within uh PSSE and and this is I'm gonna I'm going to be like talking conceptually and then talking about specific project that we're doing at PSC and other things that I'm seeing in the ecosystem. Okay. Um by the way this is a 35 minutes uh presentation. So if there are questions

Private Information Retrieval (PIR) explained

I'm super open to kind like just answer them. I know it's not the the format perhaps that that other speakers but like I'm super open because otherwise could be a bit boring and and dry. Uh okay. So P the architecture that we're proposing is like a multi-agent architecture. There's no single um scheme that is perfect for all Ethereum states. But if we can slice this Ethereum state per type or for access patterns etc. we could find very good schemes for each of them. So what if we all we have a service uh a company that just run this um this uh multi- aent architecture and then depending on the type of queries and where they might be located on the Ethereum state they will run one one um one scheme or another and

this it's already like get us very very closely to to something that is feasible and production and and and capable to offer to the ecosystem. This will require something called like a unified API. So like the wallets, the indexers, the the users, the DAP developers don't need to worry about, you know, what is the scheme and how you call it. You just like have the standard API and you just, you know, have someone else worried about the implementation details. And we're already doing this and implementing two different schemes. We will uh open for grants and we're trying to coordinate more people on the ecosystem to to tackle some of these and see which ones are the most needed for for for Ethereum. Um this is just a num a few numbers about um yeah different P

ORAM, TEEs & why they’re not enough

schemes and some you know throughputs communication overhead etc and and even like it's hard uh because different apps have different access patterns right some um access a lot of receipts like a right some want to access more the state like rod key some access more transactions like Helios etc etc right so um yeah just want to say like there's no silver bullet and most likely like something mixed um architecture will be helpful. We're also doing a systematization of knowledge. So if if this is interesting to you uh we can share this and this is just some teams and forgive me if you are a part of a team or if somebody sees the recording and um I didn't include you just please let me know and I can you know start

adding and start talking about these things uh working on these areas. The other one so we we said data right uh the other big bucket is traffic. So how do we hide traffic? What do we want to hide? In very simple terms, we want to hide uh the client and the servers IPs from each other and from the rest of the world that might be snooping traffic. Um and and we have different techniques. We have onion services, we got mixets, we got VPNs, we got DC nets and there might be other classifications. I'm just going to talk about the first two.

Multi-agent PIR architecture

Um so onization like to um basically how do you call this um frontier these like type of techniques which kind like encrypts in layers and then it gets decrypted in layers as well. So like people in between can never know the origin some people will never know the destination and some people will never learn anything. They just like act as like router patterns. Um so in in TLDDR is like what if what if all the Ethereum ecosystem and traffic we could route it through the tour network to say to but there are other options right we would um help protect the sender IP like we would not be leaking your phone your your laptop your you know whatever you're you're sending or sending sending

transactions or requested information and of course the receiver the the server we would also protect it so let's imagine if in I don't know Iran China, North Korea or like Venezuela, how whatever uh somebody's trying to host a DeFi protocol or a service and it's censored by their country, this is an option, right? That that will protect their lives and will um open to Yeah, just a good pattern. So, bypass censorship uh also hide from ISP, internet service providers. Like we all know that these are tapped by intelligence agencies and they're just like snooping everything. So, this this helps and the goal is to have a drop in replacement. So an SDK the wallets and dab developers and you know

Onion routing & Tor integration

infrastructure providers don't need to worry about the implementation details. They just know that if they use this SDK the traffic gets uh onionized or encrypted and and it's hard. So uh there's a team and shout out for the broom wallet team who started like echelot which is like open source javascript implementation because this exists right now like there's exist like to clients but on c and they just run on your you know on your on your on your um browser or you need a special browser but what if I want to add this to meta mask right or to kohaku wallet or to amber to all these other rabbi etc. uh we need like JavaScript um SDKs and and and W was so like started echelot then we um the to project has um a new implementation being developed called RT

like it's the next generation of their client but we need an ember embedded RT so something that RT can be compiled it's ROS based but needs to be compiled was and to be able to run on your browser so you can just import it really really easily so we're having basically collaborations with to our team every week calls and and some like projects and partnerships together. Um, and then on the mixet side, I want to give a shout out to several teams. I'm going to get ahead just one slide. Several teams that are approaching through this like the NIM team, uh, Hopper also one of the first ones. Well, there's BPN's Nosis. There's two others that I didn't know before anyone protocol and I think somebody of that team should be here in Denver and

Mixnets & Ethereum-specific privacy networking

seeking net some other new ones. So there's like many teams working on these like mixnetVPNs like other approaches and we want to see what if we create a purposely designed mixnet for Ethereum that we can try RPC traffic because with mixn nets um they have strong guarantees but they add a lot of latency. So for some use cases it's all fine, right? Like it you don't it doesn't matter if it takes a little bit longer as long as you have privacy. But some things like DeFi and trading and others it's extremely unlikely that these will get adopted if it has latency. So what's the the the fastest that we can run with the highest privacy guarantees?

Um yeah, shout out to some of these teams. Again, if there's someone from you know working on these areas and I haven't added you to this, I would love to chat. And the last thing I want to chat uh uh or like the third pillar to make this reality happen is performance. So we want these things to run fast to run cheap. Um I have an idea like a principle which is like these things won't get adopted if the cost is higher than the benefit and the cost mean um the cost for the user user experience time effort but also cost for the developers and for the infrastructure is this very expensive to run etc. So we need to lower the cost as much as we can and there's two initiatives high level that that I can talk to. One is UBT and

Unified Binary Trees (UBT) & ZK state transforms

depending on how much you are involved in the like protocol EIP you might have heard of this. Right now we have Merkel Patricia tree which is like useful but not very useful for CK and and and other cryptography type of stuff. And there is a proposal EIP7864 which is moving not to Berkel trees but to uni unified binary trees. And this is much much efficient for um querying state and then doing operations on cryptography like CK. So um we have a project that it's a verifiable UBT which is basically you add a sidecar to a specific um to any like Ethereum client which instead of running an MPT database it has like uh a UBT state database and

then you prove that this transformation from MPT to UBT uh it's valid using a CKVM. So this is already very powerful and um once we manage to do this things like light clients could use this to increase their performance and things like P could run much faster. So we have a project doing this. Um and the other aspect is GPU acceleration. We have um we can run these things much faster if we optimize lower levels of the stack. GP GPU is one or CPU accelerations as well. But the like these these things will probably run on servers not on phones. So it's also like very valuable to start u exploring how can we yeah just create these lower

GPU acceleration & performance constraints

level libraries to to run way faster. So okay uh doing a recap uh so far right this is like what is it like part two we got three pillars. Um let me just I I like doing recaps now that I have time. Uh we have these five layers. We want to cover these uh use cases right now in this presentation. And there are three pillars data, traffic and performance, right? Data we have proxies, T's, ORAMS, O maps and P traffic we got mixnets uh onions and others and performance we got UBT and um G um GPU and if you want to read more about at least the the contributions that PSC is doing uh you can go PSC.devs orearch.

So what is success? How can we measure it? Coming back to these um layers, if I want to say like Ethereum is the most private, if I want to be able to claim that Ethereum is the most private chain and and what is the endgame, I will say like I will need to feel comfortable with all these layers extremely hardened, right? So like how would I measure it? I I would expect more websites and and um yeah like dabs front ends to be hosted behind like onion domains. I would love to like Wallace to natively use like anon routing and and gateways as well and RPC pattern RPC providers and indexers and etc etc and I would love like I would just measure a

percentage. So the question is like from the current Ethereum ecosystem frontends how many of them are hosted behind like toward you know the onion domain I will say like extremely few right like 1% if if if any right um and I would love for things to you know for me to feel good and say like yeah we did it like we would probably need more than 80% at all of these layers like how many wallets right now are routing traffic through through these you know anon routing techniques very few like very very fee and the same way with you know RPC providers uh do they offer the PI offering these you know providers no right so for me to claim success is for all of these layers and the actors that

Measuring success: 80% adoption target

are on these layers to be adopting these type of technologies and at least 80% of or the teams or the traffic or the queries uh adopt these type of technologies this is one thing that we can be jealous of of Bitcoin right like I'm you know for all the critiques that they have This is a picture when we um in November of last year that 64% of their nodes of the full nodes are hidden behind onion domains. Can we do it ourselves right? Can we say this is like lower level consensus level uh privacy but like could we say that our nodes like full nodes uh validator nodes are behind uh onion um network or or or mixets. We should I I I definitely

think we should and we are probably less than 1% and we have other challenges that they don't have. We run much faster. Um there's yeah there's consensus is different. Um I would love to have dashboards like this and say like I don't know more than 80% of the wallets have adopted these type of technologies and more than you know RPC providers and explorers and frontends and load balancers and SDKs like I would love for this um list to grow. And um I took the liberty of like last night and the night before just like starting seeing how you know through this lens of layers how do we compare like the Ethereum ecosystem compares to things like Sana and Bitcoin and Ccash and Monero and things in yellow are

Bitcoin’s onion node comparison

things that are um optin techniques. So I think we're very good things in blue there are proposals and some of them are protocol proposals. Things in green are like things that are enforced at the protocol layer. So because of our 10-year history of like being a public chain, I think it's going to be hard to catch up with things like Monero and Ccash to be, you know, add this like um natively. But I think we can do a really really good job at getting opt in and culturally, socially um influence the the teams, the users to to adopt more of these techniques and things like you know, Bitcoin and Sena are I think are they have their own challenges and I think they'll be further behind at least on these private things. So my goal and the goal that I

Comparing Ethereum to Monero & Zcash

want to put in your mind is for Ethereum to become the most private, permissionless, trustless, and programmable ecosystem in the world. We got some other payment private chains and that's great and they're like very good, but I think they will have a much harder um job at becoming programmable and creating the ecosystem that we have created. My challenge to you guys and of course to me and my team is to become the most from the programmable ecosystems the most permissionless trusses and private and we can only focus on the onchain elements. We need to focus on all of these layers, right?

Final challenge: Make Ethereum the most private programmable chain

So if you're working in private reads, networking, PI implementations, GPU acceleration, data structures, UBT networking, infrastructure providers from here, validator, I would love to chat with you afterwards and yeah, thank you very much. Ethereum is for privacy.