Private Information Retrieval for Ethereum

Transcript

[music] [music] >> Um good morning everyone. Um thanks for joining. Um I know it's early and it's the last day of the event. So, I really appreciate um for for you being here. Uh I'm Keywo. Uh I'm a cryptographer at the Ethereum Foundation. Uh I'm part of the research team uh in the access layer cluster where I work on private information retrieval or PIR, which I'll be talking about today.

Um and I want to mention that this talk is based on joint work with um Andy, Cass, and Ali. Um I'd like to start with the saying that goes um you are what you read. Uh it usually means that what we read shapes who we are, um like how we think, what we care about, and what we believe. But, let's flip that around and look at it from a privacy perspective. Um after all, uh what we read can also reveal a lot about us, like our interests, circumstances, and even intentions.

Um and I'd argue this is especially true in the Ethereum ecosystem. Um to see why, uh let's look at how we access Ethereum state. Ideally, we would run our own node and access Ethereum state locally. But, running a full node, and especially an archive node, uh requires substantial resources. So, in practice, most of us connect our wallets to remote um RPC providers. Um and this makes accessing um Ethereum state much easier um and convenient, but the trade-off is uh is that that RPC provider sees our queries.

Um for example, when a wallet calls um eth_getBalance, the RPC provider sees which account we are asking about. And over time, the provide the provider may infer address relationships, asset and defy interests, um behavior patterns from these queries. Um and this opens the door to financial profiling, targeted scams, and selective censorship. Um to be clear, I'm not suggesting that RPC providers are actually malicious, but the good intentions are not a security guarantee. Um in crypto, we often talk about uh moving from don't be evil to can't be evil, right?

Um after all, uh even honest providers can be hacked, and recent advances in AI have already made cyberattacks um easier to carry out and scale. So, rather than trusting providers to keep our queries private, we want to design systems uh where they cannot learn which records we are requesting in the first place. Um that brings us to the question on the slide. Um can wallets and light clients access Ethereum state without compromising in privacy? And this is exactly the kind of problem we work on uh in the research team at the Ethereum Foundation.

Um our mission is to preserve Ethereum's core values when users access Ethereum state. This includes privacy, um censorship resistance security including verifiability and availability. And today's talk's focus is on private reads, privacy. And for privacy, there are two complementary goals. Uh first, obliviousness on the left, um the goal is to hide what is being read. So, the server only learns that Alice read something.

Um there are several like cryptographic primitives to achieving obliviousness, including PIR, which I'll be talking about today, and TEE uh plus ORAM, and another approach is to combine ORAM with um and MPC in place of um TEE. Um so, some of these alternatives can offer better performance than PIR, but they come with additional trust assumptions. For example, T plus or M relies on trust hardware. Uh and if you replace T with MPC across multiple non-colluding servers, then we are assuming the non-colluding servers.

Um so like so I'm focusing on single-server PIR because it doesn't require either of the either of these assumptions, extra assumptions. And second, anonymity on the right. The goal is to hide who is reading. So the server only learns that someone read, let's say, address ABC. Um onion routing like Tor and mixnets like Nym can help with this. But I'll say neither of obliviousness and anonymity alone is sufficient. With anonymity alone, the query itself may reveal the user's identity.

For example, if Alice requests her own publicly linked wallet address, um the server may able to deanonymize the queries. Um with obliviousness alone, the server may still know who is connecting. And it can also observe metadata like timings and um request frequencies, which may reveal access patterns in the user's activity. So ideally, we want both anonymity and obliviousness. By combining them, the server only learns that someone read something. Um and nothing more. So for the rest of this talk, I'll be focusing on the obliviousness through PIR.

Um and my colleague Andrew will be talking about anonymity through Anon RPC right after this session in the same stage. So yeah, I hope you um stick around. Um yeah. Uh finally, let's take a closer look at what PIR actually is. Uh on the left is API for doubly stateless single-server keyword PIR. I'll come back to what this um doubly stateless means and why it matters for Ethereum later in this talk. But, yeah. Uh let's consider a database as a dictionary mapping keywords to records. Um and then the this API for PIR consists of four algorithms:

preprocess, query, answer, and extract. Um Now, let's see how these algorithms work together uh using a um example. Uh using example um private balance retrieval. Um Suppose the database maps Ethereum address to their balances. Uh and address ABC maps to a has a balance of five ETH. First, the server runs preprocess uh algorithm on its database uh to obtain a prepared database D.

Um this is a one-time operation, one-time setup for a given database snapshot, and its output can be reused across different queries and clients. Um then the client runs query on address of his her interest, let's say uh address ABC. This generates a query Q and some local secret state ST. The client keeps ST secret and sends only Q to the server. Then the server runs answer algorithm on the prepared database D and the query Q and sends back the response A.

And finally, the client runs extract uh using ST and um the answer A to a response A to recover the balance um five ETH. And the key privacy requirement here is that the server um must not be able to distinguish which keyword was queried. Uh we won't go into construction's detail of construction today, but if you're familiar with the concept of fully homomorphic encryption or FHE, uh there's a simple way to see how PIR is possible.

The client can encrypt the keyword using fully homomorphic encryption and sends it to the server. Then the server just homomorphically evaluates the database lookup function lookup circuit on the encrypted keyword and returns the encrypted output of the lookup. Then the client decrypts to recover the record. And yeah, in fact many PIR schemes borrow techniques from homomorphic encryption although they do not require like full-fledged FHE in general. And now the PIR is not a new idea.

As we've just seen the retrieving information without revealing what you're reading is a very like fundamental question or problem in cryptography. PIR was first introduced in 1995 and since then it's been studied for over 30 years by a rich research community. And what's exciting is that PIR is now finding its way into real world applications. Like even at scale. In fact, Apple began deploying PIR in its products a couple of years ago.

I won't go into details about this their deployment but if you're interested in how Apple is using PIR, I'd recommend checking out this article. And of course we'd like to bring this kind of privacy into Ethereum as well. And given Apple's deployment you might expect that to be fairly straightforward. But Ethereum comes with its own set of challenges. First is that the state is updated almost continuously with new blocks roughly every 12 seconds.

And second the database is like huge. The current Ethereum state is roughly 100 GB 300 GB. And our data can be can reach uh multiple terabytes. And third uh is that um most of the use cases we can think of from Ethereum, the latency matters. Uh like many Ethereum state queries are part of interactive wallet um operations. So, users expect um reasonably fast responses. And now I will like briefly discuss some of the approaches we've been exploring or taking. Um as we've just seen, a PIR has been studied um for over like 30 years. And over that time, researchers

have proposed a huge variety of PIR schemes um designed for different settings and different um assumptions or um scenarios. So, figuring out um which scheme is the best suited for Ethereum um is already a challenging in itself. Um even deciding how to organize um this landscape took some took some thought. And after considering different ways of um classifying PIR schemes, uh we found that a particularly useful distinction for Ethereum is what what state the client and server need to maintain.

And this led us to focus on doubly stateless PIR. So, here the client statelessness client statelessness means that um clients don't need to maintain database uh dependent hints, which is especially important when the database changes frequently. And the server statelessness means that the server don't need to maintain per client state. And this is essential for preserving unlik- unlinkability when combining PIR with anonymity systems like Tor.

Because like otherwise, persistent client-specific keys could allow the server to link the request uh even if the user's network identities um anonymized. And yeah, to mention, uh one example of doubly stateless PIR is um the scheme called Inspire, uh developed by researchers at a research team at Google. And we've been building on this scheme for our Ethereum PIR um implementations. Um next is um continuous serving. Inspire, for example, can require expensive um and time-consuming pre-processing.

To So, to keep the serving through frequent updates, uh we handle recent changes separately from the main database snapshot and rebuild it in the background without downtime. And finally, for scalability, uh we are accelerating PIR um PIR algorithms using GPUs, while exploring data curation and sharding to reduce the amount of data uh each PIR engine needs to process. And yeah, if you're uh interested in more details, I've included some resources at the bottom of the slide.

And yeah. So, now I'd like to share some performance numbers from our GPU PIR implementation. Um these measurements are for index PIR, where we retrieve a record by its position in the database, um and keyword PIR can be built on top of index PIR using techniques like cuckoo hashing. Um we are using a single RTX 5090 GPU and 120 byte records. And the implementation is available on um GitHub at the link above.

And just to give you a sense of the cost, um you can rent a RTX 6090 for about a dollar per hour. Um on the left, uh batch server throughput, which is about 579 queries per second for a 1 GB database and 115 for 16 GB of database. And on the right, for a 16 GB database, a single query without batching takes about 30 milliseconds um of server runtime and the query the query is 371 kilobytes and the response is 12 kilobytes and pre-processing takes about 8 seconds on GPU.

Depending on your expectations for PIR, the performance might look either fast or slow, but compared to the CPU implementation we started from we've seen more more than a 100x improvement. And I think these numbers at least show that practical PIR serving is now within reach. And I also should confess that I'm not a like GPU expert, so I suspect there's still plenty of rooms to improve these numbers especially for the batch server throughput. And for example, like we could learn from recent work such as sender's PIR which leverages the tensor cores and we inspire which is a follow work of inspire.

And I'd like to talk about integration of our PIR backend into Kohaku. Kohaku is a privacy focused wallet stack for Ethereum Ethereum that makes it easier for developers to add privacy features to their wallets. So if you were at Nico and Vitalik's talk on Vitalik's session on Tuesday, you probably heard them mention mentioning private reads and PIR several times. And yeah, what what I've been talking about today is exactly the backend we've been building for that functionality.

And I won't repeat the demo they already showed on Tuesday, partly because it's probably the least exciting demo you can imagine. It looks just like a regular wallet except except for the with a bit bit more of waiting. And if you miss their talk and are interested in Nico and Vitalik's take on private reads, I recommend watching the recording. And what kinds of private reads do we actually support? As you can see on the left, left. Right.

Our back end covers all the privacy sensitive RPC calls using Quorum balance workload. This includes account balances and nonces EIP-702 delegation, balances of major ERC-20 tokens, name lookups through ENS, GNS, WNS, and stealth meta stealth meta address lookups through the ERC-6538 registry. We benchmarked a wallet refresh involving five addresses and 60 26 logical lookups using a single 200 GPU.

On a hotel Wi-Fi, a plain RPC refresh took about 0.3 seconds and with PIR, it took 11.7 seconds. We also tested PIR over Tor and it took 44.7 seconds. With GPU acceleration, the main bottleneck is now network communication and not the computation. And each wallet refresh uploads about like 20 megabytes of PIR queries. So with the roughly 20 megabit upload speed we had, communication alone takes like roughly eight eight seconds.

Of course, this is not perfect yet, especially when it comes to latency over Tor. But I think it's a good start. We now have a working integration and much more clear picture of what needs to be improved. So here's the TLDR of this talk. So first, you are what you read. Second, PIR keeps what you read private. And third, we are bringing PIR to Ethereum. Of course, there is still plenty of work ahead of us.

First is performance. There is room for further optimization both in GPU implementation and in underlying PIR algorithms. We are also interested in multi-query PIR or client-side um which could significantly reduce the communication cost when a wallet needs to retrieve multiple records at once simulta- simultaneously. Um and another interesting direction is doubly efficient PIR, um which aims aims for sublinear online server work. This is particularly interesting in a like theoretical perspective um historically, although it is yeah, like it is still far from the practical deployment yet, but yeah.

And next ability. Uh ideally, we'd like a private version of Eth get proof, allowing um wallets to retrieve Merkle proofs without revealing which state entries um we are interested in. And finally, decentralization. Uh we'd like to make PIR serving practical on also on ordinary CPUs, so that even home nodes uh could serve PIR um private reads without uh without specialized GPUs. And but like making this happen will make more than just our team.

So, here's my call to the Ethereum community, um to researchers and developers that research and develop. Uh there are plenty of interesting problems to solve and systems to build. And I think there's a chicken and egg problem between infrastructure supply and user demand. Um infrastructure providers need enough demand to justify running these PIR servers, while it is hard for user to demand um user demand to emerge uh when there are like no accessible um PIR servi- services to try in the first place.

So, infrastructure pri- uh providers um please um consider serving private reads. And if there's anything that makes PIR serving impractical for you, um please let us know so that um we'd work uh we'd love to work on addressing addressing those um challenges. And to Ethereum users, I'd encourage you to um demand private reads um and let wallet developers and infrastructure providers know that private reads are something we actually want. And yeah, that's it. Thank you for your attention.

>> [applause] >> That was a great talk, Kiwoo. It's time for some questions and answers. [snorts] Remember we have 5 minutes and you have the QR codes there. We already have some nice questions here, but feel free to keep adding them and we'll go as we can, right? So, would you like to choose one question to start? >> Ah, okay. Like I can see here. >> I'll I'll rank them rank them now for the the next few minutes. >> So, how can I verify the result without breaking the privacy? So, this is something I'm considering for the verifiable PIR or the private Merkel proof retrieval because like actually like we we can verify these RPC providers response through this Merkel proofs already, right? But what we don't

have right now is the private version of it. And yeah, like just we can retrieve the um Merkel proof through through PIR, then we can verify the result without breaking the privacy. That's the basic idea. >> Thank you. >> And second one, what are the costs associated with PIR today? Will such friction hurt adoption? I think it really depends because like um how much do we want to pay for privacy? I think that's the trade-off we are making. If you really care about privacy, you can pay like way higher than and and then like if we less care about privacy, maybe like we don't want to pay this overhead. So, what what we

are trying to do is trying to suppress this trade-off curve as low as possible. But like I think it's also important for us to bring this awareness of privacy so that at some point we we meet in the middle so that everyone is like happy with the um yeah, it's somewhere the middle. >> Yeah. Will PIR only be possible via RPC servers or also by talking to EL nodes via devp2p directly? >> I think PIR itself is very like general technique, so I don't think it's like kind of tight to these RPC nodes, um but the reason we started with RPCs um we can assume maybe the

uh kind of like specialized hardware or like expensive um hardware like GPUs on those type of servers. So, that's the tackle on things we tackle, but like uh the the open question we had is kind of like can we do this on the like home nodes with regular CPUs um or the reasonable um reasonably re- reasonable hardwares. So, yeah. >> Yeah. And uh what about the GPU layer? Are you just running CUDA on Nvidia and doesn't that create an adoption blocker?

>> Um Y- yes, I'm currently using CUDA. Uh in the AI area, doesn't that create an adoption blocker? I'm not sure what's the exact question on this. Yeah. >> I'm I'm assuming it could be referring to the costs. >> Uh okay. >> the scarcity in supply. >> Yeah, that's true, but um at the the the the machine that I'm I'm using is like A20 and it's like available on RunPod and like very yeah. It's not I I think it's not like too hard to um access to those machine, I think.

>> Yeah, very so. A very pragmatical question, do we need to update preprocessing after every new block? >> So, this is um the thing that I mentioned as a like lazy update or the sidecar pattern, so that you only keep the delta of the updates for a while, so that you can do the updates like not every block, but like let's say every five block or something because the for like for say le- let's say like uh schemes like Inspire requires um Um some time to preprocess, so like you are delaying it to serve without downtime.

So, yeah, basically you can like push back on the uh pre-processing timing. >> Mhm. We have roughly 1 minute left. From these questions, which do you think will be most relevant to answer? >> Um do you need update um how's Uh how's the performance for archival data according with PIR? Like I think we haven't reached that um yet, but I think it's very cool to um yeah, cha uh it's a very good challenge. And the path that we are seeking is kind of sharding the database into smaller chunks, but not seeing the um database as a whole. So, that maybe we can chunk the like multi-terabyte into um like thousands of 1 GB databases, and then

run the PIR um algorithm on each of the things. So, that in that sense, like we will be losing some kind of anonymity set, but I think 1 GB is already a quite a good amount in practice for a an anonymous set. So, that's something we have considered, but not actually implemented yet. >> [snorts] >> Well, this was a great presentation. Someone is also asking if the slides are down low ball downloadable. I just know that you have a very cool personal website as well that people can access for your speaker profile on the Devcon app, which works great. And yeah, I was just very happy to have you on stage. I really enjoyed your message of we are what we what we read. I hope you're also reading some nice books

here and not just scrolling mindlessly through our rage-baiting Twitter. And I was also very happy to see the stealth addresses inclusion in in Koaku. If you know me, you know that I'm a an advocate and a fan um >> [snorts] >> and a builder around >> [music]