Anna Rose (00:05): Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast we'll be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. (00:28): This week I chat with Ravital Solomon, the founder of Sunscreen. We chat about her interest in lattice-based cryptography, how this led to her work on FHE, first at NuCypher, and then with her own company Sunscreen. We explore the challenges of building with FHE, the power in the combination of ZKPs and FHE, as well as the early emergence of lattice-based zero knowledge proofs. Now before we kick off the episode, I do want to direct you to the ZK Jobs board. There you can find jobs from top teams working in ZK. So if you're looking for your next job opportunity, be sure to check it out and if you're a team looking to find great talent, feel free to add your job to the jobs board as well. I've added the link in the show notes. Now Tanya will share a little bit about this week's sponsor. Tanya (01:12): Polygon zkEVM is here. This performant, ZK-powered, open-source, EVM-equivalent rollup launched its Mainnet Beta last month. Polygon zkEVM is making scaling truly frictionless—fast finality and EVM-equivalence means devs can do everything they can do with the EVM, only cheaper. But a network that really wants to extend Ethereum’s blockspace needs Ethereum’s infrastructure. The infra needed to port, build, and deploy on Polygon zkEVM—oracles, RPC nodes, APIs, and tooling—are already onboard. Two years ago, Polygon Labs bet big on ZK technology. Collaboration among Polygon’s ZK teams and a build-in-public ethos has resulted in a big leap forward. Together, Ethereum users will discover what ZK can do. To connect to Polygon zkEVM, go to Polygon.technology Anna Rose (02:08): Today I'm here with Ravital Solomon, the founder of Sunscreen. Welcome to the show Ravital. Ravital Solomon (02:13): Thank you Anna. I'm glad to be here. Anna Rose (02:16): So today we're going to be diving back into the topic of FHE - fully homomorphic encryption - but before we do that, let's learn a little bit about you and also I just want to sort of figure out when exactly did we first meet. So I know you were a speaker at zkSummit4 and zkSummit6 online, but yeah, was zkSummit4 the first time we met? Ravital Solomon (02:38): I don't think so. So like I had just joined NuCypher and I had gone to zkSummit3 but it was, I believe Tux speaking, so I was just in attendance there. Anna Rose (02:49): Cool. Cool. So yeah, maybe start from you joining NuCypher. I want to hear a little bit about your story here. What were you studying before? What were you working on there? Ravital Solomon (02:59): Yeah, so I think my story when it comes to cryptography starts a lot earlier than NuCypher. So I went for my undergrad, I did it in math. I took my first cryptography course as a junior at Berkeley and I heard about this new emerging area of cryptography called lattice cryptography. It wasn't very popular at the time. There were no courses about it at either the undergrad or graduate level. So I tracked down this math professor and I was like, I really want to learn more about lattice cryptography. I really want to work in this area. So he agreed to work with me and start learning about lattices, that really started my journey in cryptography and I really loved it and wanted to continue. I assumed to pursue cryptography, you really had to be an academic. So, oh my gosh, I have to get a PhD. (03:51): The only way I'm going to get to do this is being a professor but for reference, both of my parents are academics or ex-academics. They didn't have a lot of good things to say about academia. So I was like, well what should I do? Should I go get a PhD? Like should I see if I even like research? So I found a more research-based master's program and that was in the UK. I went there, I did more stuff in lattice cryptography, I did lattice-based group signatures and I confirmed that I absolutely love lattice cryptography. I absolutely loved research, but I hated academia. So I was looking around at the time and I was like, well I really want to do lattice cryptography, but how am I going to do this? Like, is anyone going to pay me to work on this area? And I was super open-minded. I was like, anything to do with lattice cryptography I am open to and I was lucky to stumble across NuCypher on Hacker News since they're a YC company and they were hiring at the time. So I reached out to them. The first person I remember meeting was Tux there and that's how I really started and the blockchain and Web3 space. Anna Rose (05:01): Cool. It's interesting you talk about lattice cryptography. Maybe can you define what that is and is that the basis of FHE? Ravital Solomon (05:10): So you can think of lattice cryptography as a generalization of some of the math you've done in probably middle school or high school. When you're graphing points on some planes, you think of like an X and Y axis. They're both on the real line. Lattices is can be thought of as some sort of subset of these points in the space. So instead of taking arbitrary kind of decimal points, like you can think for the X and Y coordinate, maybe you have 1.001, you have 2.001, we're going to restrict it in the simplest case to just integer points. So you can think of it as some sort of discreet space sitting inside some kind of real space. Anna Rose (05:53): Oof. That is, that's tricky. It's hard to follow. But like what general area is lattice cryptography? Is it close to like elliptic curve cryptography? Is it a totally different world? Ravital Solomon (06:08): Yeah, yeah. So lattice cryptography is totally different from the others, like other areas of cryptography. What differentiates lattice cryptography from elliptic curve-based cryptography is that it's post-quantum. So it's secure against attacks from a quantum computer and I would say if you want to think about what area of math lattice cryptography falls under, it probably can be thought of as linear algebra on like steroids. So instead of thinking about linear algebra and like matrices and vectors with numbers, you're instead thinking about polynomials. Anna Rose (06:45): Oh cool. So you're saying this is the sort of basis like FHE is built around lattice cryptography? Ravital Solomon (06:51): Yes. Anna Rose (06:52): Is there other types of math in FHE that one should also be aware of or is if you have a good understanding of lattice, can you like lattice cryptography can you do a lot? Ravital Solomon (07:03): If you have a good understanding of lattices, you can do FHE for whatever reason. The only known FHE schemes are based on lattice cryptography. No one has been able to successfully construct an FHE scheme using other types of cryptography yet. Anna Rose (07:17): Cool. All right. So you were at NuCypher. Tell me a little bit about what kind of work you were doing there. What projects were you getting into? Ravital Solomon (07:26): Yeah, so I joined the company to really explore if fully homomorphic encryption could make sense for solving some of the privacy problems in Web3. It wasn't directly related to NuCypher's main work, but the founders were super interested in seeing how fully homomorphic encryption could fit into the Web3 space. I have to say when I joined NuCypher, I was not very optimistic about lattice cryptography making any sense for Web3. In general, it has a pretty negative perception when it comes to efficiency, but I was surprised to see in terms of the existing privacy solutions in the Web3 space FHE could actually be quite performant and could make sense for quite a few applications. Anna Rose (08:11): Were you also watching how quickly, like it's almost like these cryptographic concepts had been around for a long time. You had seen the progress go in that sort of academic way, slow and sure, but maybe a little bit niche, once you started to connect it to these like highly incentivized networks and throw a lot of funding at it, it started to obviously accelerate really quickly. Did that give you hope to, were you kind of like, maybe we don't have to worry about some of these inefficiencies because it could actually be accelerated faster? Ravital Solomon (08:44): No. So I am naturally a super pessimistic person and I hate this idea. I hate the idea of like relying on somebody else to build hardware accelerators to solve my problems. Anna Rose (08:56): Oh okay Ravital Solomon (08:56): So to me it was like is there an FHE scheme that makes sense right now as is to solve some of the problems in the space? I am biased. I obviously think the answer is yes, but no, I wasn't looking like with optimism or hope towards people building accelerators. Anna Rose (09:12): Okay. But when I say acceleration, I don't actually mean hardware acceleration. I mean just like the acceleration of research and technology. I mean, even in your experience you've now been in this, I mean if you're saying you were at zkSummit3, that was in 2019 I think, and you were definitely at zkSummit4. So yeah. In that time you've seen a lot of the proving systems be kind of optimized and like become faster and smaller and quicker. Like all these things have happened. Do you feel like in that time, have you seen FHE also or did you see similar growth in the on the FHE side? Ravital Solomon (09:51): Absolutely not. So definitely not. When it comes to like theory improvements, I was really hopeful. I had the same kind of expectation when I was thinking about FHE and compatibility with zero knowledge proofs. Certainly in this long, long timeframe there will be like a better zero knowledge proof system that's compatible with FHE. There's so many people working on this. But the answer is there weren't many improvements and FHE has a lot fewer people working in it than I think zero knowledge proof. So it's just, it's been a slower time. We haven't been here as long. FHE's been here, I think since 2009 zero knowledge proofs have had a huge headstart, they're from like the late eighties. So it'll take us a little bit of time to catch up Anna Rose (10:36): But when you say this, it also makes me think that this is actually a really interesting time to start looking at FHE. So it's a bit behind on the the ZKP front, but like it seems like there's a lot of space for improvement. Ravital Solomon (10:48): Definitely. So that's why I'm really excited to work in this space. I think this is the really early stages of FHE when it comes to usability and applications. And if you're working in the space right now, you get to really define what the feature of FHE will look like versus I think zero knowledge proofs. Some people have already defined what that landscape is going to look like. Anna Rose (11:11): Cool. All right. So you were working at NuCypher, you were working on this cool thing that would maybe, or maybe not sort of fit into the company's mission, but then you've spun out to create Sunscreen. Tell us a little bit about that. Ravital Solomon (11:25): Yeah, so at some point it became clear that to really pursue this mission of bringing fully homomorphic encryption to Web3, a lot of resources were needed and quite a bit of work needed to happen. And did it make sense for the NuCypher team to really pivot from whatever they were working on to like working on this brand new mission? Maybe, maybe not, but MacLane and Michael were super encouraging of me kind of going, starting my own venture, finding people to work on these problems. So that's exactly what happened. Anna Rose (11:58): Cool. So today tell us a little bit about what Sunscreen is actually building. Ravital Solomon (12:02): Yeah, so Sunscreen's mission is to bring advanced privacy technology to Web3 engineers and we're working on SDK that packages together fully homomorphic encryption and zero knowledge proofs to make privacy accessible to developers. Anna Rose (12:17): I did an episode with the CEO of Zama and we talked a little bit about some of the ideas that they had around, you know, putting computation into this private space. Like what is actually, what kind of FHE are you talking about? Like what would somebody use that space for? Is it almost like this enclave that's like totally cryptographic where you can do private computation or are you thinking about it in a different way? Ravital Solomon (12:43): There's quite a few applications of FHE and it depends like how you imagine FHE fitting into Web3. So one thing a lot of people are interested in is private smart contracts. So the idea that we can do computation directly on encrypted data, in this case, the workflow would roughly look like the following. The user encrypts their data using an FHE scheme. They produce some zero knowledge proofs, verifying conditions on their encrypted data. Then the validators of the system, they check the proofs and they use the homomorphic properties of the FHE scheme to perform the computation on the user's encrypted data and update the stake. But there are other applications of FHE we've seen quite a bit of interest in in the last few months. And some of those have to do with addressing MEV issues. (13:31): That use case, it's not quite as clear if you need zero knowledge proofs for it, but roughly speaking you can think of wanting to perform some sort of sealed bid auction and you would need to combine FHE with some other tools. You'd be looking at maybe threshold FHE, where you can imagine the trust is distributed between a few different parties and they would come together to decrypt things and you'd run an auction, you'd order a bunch of bids and you'd only reveal the winning bid that may or may not need zero knowledge proofs. It's not quite as clear. Anna Rose (14:06): Hmm. You just said threshold. Is it threshold FHE or threshold HE? Ravital Solomon (14:12): In this case we'd be looking at threshold FHE. Threshold HE is something a little bit different. Anna Rose (14:18): Okay. Ravital Solomon (14:18): So when you talk about homomorphic encryption, it may only support one type of operation on encrypted data. So maybe you could add encrypted data together mm-hmm or multiply encrypted data together. But you definitely can't do both. When you talk about threshold FHE, you want to be able to do both types of computations on encrypted data. Anna Rose (14:38): And when you talk about threshold FHE though, what's the fully, what does that actually stand for in this? Ravital Solomon (14:45): The fully part still kind of is attached to the homomorphic encryption part. So you can imagine there's FHE and there's like this new word that goes in front of it that says threshold. And the reason you'd want that is that for some of these use cases with people thinking about auctions, you don't want to entrust one party with all of the data. So in some sense you can ensure that if we run this auction and we have a bunch of different bids, some parties have to come together to only decrypt the first bid. Otherwise we might be trusting one party to potentially not decrypt everyone's bids. Anna Rose (15:22): Tell me a little bit more about like the exact use case then of Sunscreen. What are you guys doing? Is there some sort of use case that you're like very, very focused on? Ravital Solomon (15:34): Yeah, so right now we're exploring, I would say 3 major use cases. We really view ourselves as building privacy tools for other protocols and other people. Anna Rose (15:44): Okay. Ravital Solomon (15:44): Rather than like we are going to go out there and necessarily solve all of these problems as a company. For the 3 major applications, we're very interested in private smart contracts that we've already spoken a little bit about. For the second use case, we're interested in doing some sort of sealed bid auction using a variant of fully homomorphic encryption called threshold fully homomorphic encryption. The idea with threshold fully homomorphic encryption is that you're going to take your keys and you're essentially going to break them up into little pieces that you're going to distribute out to a number of different parties. So encryption still works the same. You take like the public key, you encrypt it with respect the key, but decryption works a little bit differently where these different parties now have to come together, have some sort of interaction in some sense to decrypt whatever the encrypted data is. So you can imagine it's useful when you don't want to entrust one party with all of your data. Anna Rose (16:44): There's two other acronyms that came to my mind as you described it. One was like a DKG and a MPC. Is either of these related to what you just said? Ravital Solomon (16:54): Yeah, I would say they're pretty similar. You are kind of breaking up the keys and sharing it. Anna Rose (16:58): Okay. Ravital Solomon (16:58): And many times this version of FHE, which is sometimes also referred to as multi-party FHE. Anna Rose (17:05): Oh, okay. There we go. Ravital Solomon (17:06): And multi-party computation. So you're correct. Anna Rose (17:10): All right. Is it of hybrid then? Is it sort of using similar ideas or is it just actually just providing the same benefits but it's completely different under the hood maybe? Ravital Solomon (17:24): It's using some of the same ideas from the other spaces. So you want to distribute trust, you want to have parties interact to do a computation, but you still want the homomorphic properties of that encryption scheme. You still want somebody else able to perform computation on some kind of encrypted data. Anna Rose (17:41): Got it. What's the third use case so far? You said private smart contracts and auctions? Ravital Solomon (17:47): Yes. So there's a closely related one to auctions and we've seen quite a bit of interest in people building dark pools. So the idea here is can we match, we'll say orders together in some sort of place that is not open to the regular market using FHE. Anna Rose (18:06): When you gave the talk at zkSummit6, this was online, you talked a lot about like the MEV use case. Like is that, does that have something to do with the auctions you just described or is that actually a different construction completely? Ravital Solomon (18:18): It is completely different. Anna Rose (18:19): Okay. Ravital Solomon (18:20): So for my previous talk at one of those zkSummits, it was really this idea that we want to protect users against front running and specifically we're interested in protecting users against sandwich attacks. So for a lot of these attacks on AMMs, it had to do with the fact that you could see the user's orders. So the idea here was could we use FHE to hide the user's orders and protect them against front running and sandwich attacks? The use case with the auctions is a little bit different. So here we're interested in essentially bidding for block space. So helping searcher bid for block space. How might they do that? Maybe they want to participate in some sealed bid auction and the winner of that auction, it will be prioritized in terms of the block. Maybe a way of doing that is using FHE for this auction. (19:11): So everybody encrypts their bid with respect to some threshold FHE scheme. We order all the bids and we only open up the revealing bid. So you can imagine then that everyone else's bids are still hidden. You really can't correlate their behavior from auction to auction. So maybe for example, we know Anna always gives really bad bids Anna Rose (19:34): Totally. Ravital Solomon (19:35): So we're not even going to bother with hers. Threshold FHE we would never reveal the losing bid. So there wouldn't be some sort of linking or tracking of your behavior across auctions. We wouldn't have like a profile of how you behave. Anna Rose (19:51): It's interesting. I actually just did an episode which I think is going to come out just before this one on auctions. So we have a whole episode where we talk all about auctions. I don't know that we talked about an FHE case though. We did have some ZK ideas around auctions that were floated, but this was kind of new to me. I want to just go like one step back to the MEV case and I know this is not a use case that Sunscreen's focused on, but you had presented this sort of FHE approach and I'm realizing this, I think that was the first time that I heard that problem space being solved with something like FHE. More recently, what I've heard more about is stuff like threshold decryption as a solution, which I is a different technique. I guess they're they're unrelated, right? Ravital Solomon (20:36): They are similar. Anna Rose (20:37): Oh, they're similar? Okay. Ravital Solomon (20:38): Yeah, so you can think of threshold encryption as like a weaker form. Anna Rose (20:42): Oh, okay. Ravital Solomon (20:43): Or you can maybe alternatively threshold FHE is an extension of threshold encryption. Anna Rose (20:48): I see. Ravital Solomon (20:49): Where, see where you can now do computation on encrypted data as well Anna Rose (20:51): Okay. Okay. So it is actually related, so this, but would you say what you had actually presented then? Was it like more of an intense, like full fledged version and now you need, you don't need such crazy privacy so you can actually like allow for a simpler construction? Ravital Solomon (21:07): No. Anna Rose (21:08): Okay. Ravital Solomon (21:08): So I would say with threshold FHE, it's for solving some very, very different problem, in the MEV space. This is more about searchers kind of bidding for block space. Whereas when I was talking about just FHE more generally in that previous zkSummit, it was for protecting users. So very, very different kind of use cases and applications meant for different people in this space. One is for searchers, one is for like end users who just want to exchange some token. Anna Rose (21:39): Okay. How developed are these tools at this point? If there was a developer out there listening and they wanted to actually use some of this FHE stuff, how in the weeds do you have to be? Is there anything that's kind of like, are there any libraries that somebody could already try using or would you say we're still ways off from that? Ravital Solomon (21:58): We're still quite a ways off, so, okay. I wouldn't say that it's easy for most developers to use FHE in any Web3 application. There are a lot of challenges with FHE performance. You need to be, I would say, some kind of cryptography expert to set up an FHE scheme correctly. Not so much for security almost entirely to get decent performance. Anna Rose (22:20): Okay. Ravital Solomon (22:20): The other issue is that for most applications in Web3, you can imagine that if you encrypt data, you're not really sure ahead of time of how many computations you might want to do on that encrypted data and that makes selecting parameters really difficult, if not impossible, in many situations. The other issue is that to really make use of encrypted data in Web3, since we're working in a trustless setting, we need to verify conditions on our FHE encrypted data. And it turns out that that is very, very difficult and generally very inefficient with the current zero knowledge proofs available. Anna Rose (23:00): What do you mean by that? Checking conditions? Ravital Solomon (23:03): Yeah, so let's imagine that you're feeding encrypted data into an application. I'm feeding encrypted data into an application. We don't trust each other and we don't trust anyone else in the space. How can anyone else verify that your encrypted data meets the conditions of that application? Let's say for example, that maybe this application requires your account balance to be above a certain value. If your account balance is encrypted and only you have the key, how can the rest of us verify if that condition is met? We can't. So zero knowledge proofs need to come into play here. That way you'd be able to prove to the rest of us that your account balance is above a certain value without revealing what exactly your account balance is. The challenge here is that FHE uses something called lattice-based cryptography, while the most efficient zero knowledge proof constructions definitely don't use lattices. So how do you combine these two and get good performance that is actually a really, really hard problem and much more difficult than making FHE usable. Anna Rose (24:08): Why are they hard to combine? Like are you trying to put a ZKP into FHE or vice versa? Like, I'm kind of trying to understand what's the interaction point between these two things. Like what it sounds like is you're creating a proof on one side and then you're just like adding it to encrypted data. Why is that hard? Ravital Solomon (24:29): Yeah, so there's a number of conditions you're likely going to want to prove about your FHE encrypted data. If we're thinking about just private transactions and we're working in the account model, maybe some conditions you want to prove is that the amount you're sending to somebody is positive. You're not trying to deduct money off of someone else's account. You might want to prove stuff like you have enough balance in your account to make this transaction. Those are pretty cheap and pretty easy to prove with general zk-SNARKs, the difficulty here is about proving that you have a well-formed cipher text so you're not just giving somebody garbage. Because we need to prove something about lattices. If we try to turn it into a circuit using many of the current zkSNARKs, you end up with things with millions and millions of gates. So the performance is really bad. You need either a lattice-based proof system which will allow you to more efficiently prove things about lattices or you need to find some sort of clever hack of how might you connect a lattice encryption scheme with some non-lattice-based proof system. Anna Rose (25:41): Hmm. In the work that you're doing, do you have to actually also think about, or even like experiment with building ZKPs differently? Or are you just like, that's how ZKPs are, we're only going to work, figure out how to work with them? Ravital Solomon (25:58): It's a little bit of both. So we had to investigate quite a bit into zero knowledge proof systems, both what's used currently in the Web3 space and then also what's being done in academia also on like the lattice-based side. So yeah, I would say that we're doing both research and we're also trying to make use of existing zero knowledge proof systems where we can. Anna Rose (26:23): Is there work being done for like, maybe this is going to sound totally insane, but like lattice-based ZKPs? Like does that, is that a possibility? Ravital Solomon (26:31): Yeah, yeah. So there's actually quite a bit of work in lattice-based ZKPs, especially on like the academic side. The challenge with lattice-based zero knowledge proofs is that while like prover time and verifier might be really fast, the proof sizes are terrible. They're definitely not acceptable for Web3. So when I say not acceptable, we're often talking for this kind of use case megabytes in size for proofs. So it doesn't seem feasible right now to use a lattice-based proof system in the Web3 space. Anna Rose (27:05): Is there any work on like then using recursion to try to like compress that down? Do you need the output to still be like lattice friendly somehow? Ravital Solomon (27:15): Yeah, I would say so. So there are some of the more modern lattice-based proof systems do make use of recursion like you're saying. But the challenge here is it's not quite clear what the prover and verifier time will be like when you start in introducing recursion into these proof systems. And the current works are super academic, there are no implementations of any kind. So it's very difficult to get a sense of performance. Anna Rose (27:40): Got it. I'm trying to also understand if, when you describe the need for like a lattice-based ZKP does using lattice cryptography under the hood, does it like fundamentally change how a verifier is working? Like or is it, I'm trying to just sort of picture what the difference would be and if you need sort of a different kind of output. So you could never use some of the techniques that have been used in existing SNARKs because it's so very different. Ravital Solomon (28:11): No. So I would just kind of like off kind of whatever we're saying you, they have made use of a lot of the techniques from snarks in lattice-based proofs. What we've kind of figured out in terms of what we're working on is that it almost certainly doesn't make sense to use a latice space proof system. There is this actually very, very strange ugly proof system that turns a lattice-based relation into something with elliptic curves and that really allows you to get better performance than working with regular zk-SNARK and better proof sizes than using something lattice-based because there's no way anyone is okay with megabyte proof sizes Anna Rose (28:49): Okay. So that's basically the direction that you've chosen then. Ravital Solomon (28:52): Yeah. Anna Rose (28:52): Is it sort of like, is it compiling or is it transforming? What, where, yeah, how does that connection happen? Ravital Solomon (29:00): Yeah, so there is a transformation. You're taking a lattice-based relation, which you can think of as some sort of matrix vector equation and then it's transforming it into a Pederson commitment and doing something that looks a lot like Bulletproofs with that commitment. Anna Rose (29:15): Okay. Ravital Solomon (29:15): And that allows you to get pretty decent performance and much better proof sizes than working with a lattice-based proof system. Anna Rose (29:24): Interesting. Is that like the kind of systems that you're then building? Ravital Solomon (29:28): Yeah, that is what we're currently looking at because we think it offers the best trade-offs with regards to proof time and proof size. But maybe in the future there would be like a better lattice-based proof system in which case we'd be happy to move to that. Anna Rose (29:44): But in that case, if you're just kind of compiling to make it ZKP friendly, would you say then like are there ZKPs that are still better to use for this? Like do you feel like there's particular proving systems that you feel like are the right choice or would you say actually any proving system could be used once you've made this transformation? Ravital Solomon (30:07): So this transformation does something that looks like Bulletproofs but it's not quite Bulletproofs and no, you would want to work with this very, very specific protocol. We haven't seen anything better come up for proving ciphertext or well-formed than this particular proof system so far. Anna Rose (30:27): Got it. How far out do you think we are then on the FHE front? Like and even with all the work around ZKPs? Yeah. How far out do you think we'd be? Ravital Solomon (30:36): It depends for which application? For like private smart contracts probably a year out. Anna Rose (30:43): Oh, okay. Ravital Solomon (30:44): I would say for some of those auction use cases, particularly for searchers that might only be a few months to 6 months out Anna Rose (30:52): Before they're usable by engineers or by like implemented and there's libraries and stuff, Ravital Solomon (30:58): I would say usable by engineers. Anna Rose (30:59): Oh wow. Okay. So are you and you're building these libraries right now? Ravital Solomon (31:03): Yeah, we are working on some of this stuff. Anna Rose (31:05): Nice. Is Sunscreen then like a tooling company? Is it almost like a company that would build something akin to like Arcworks? Ravital Solomon (31:13): Yeah, I would definitely say so. Anna Rose (31:14): Okay. Ravital Solomon (31:14): We do view ourselves as a tooling company. Anna Rose (31:16): Will you have a DSL or do you just see it as like people can build that themselves to interact with this? Ravital Solomon (31:24): There will be a DSL for some of our zero knowledge proof stuff, unfortunately. Anna Rose (31:28): I guess because it's a new system and it's going to need totally new language to interact with. Ravital Solomon (31:34): Yeah. Anna Rose (31:35): Damn. What about the FHE part though? Is there such a thing as like DSLs for FHE? Ravital Solomon (31:40): I don't really think so and for what we've done, at least with our FHE compiler, we just want a developer to write a regular Rust program. We don't want them to think about like DSLs. Anna Rose (31:51): Oh, I see. But how does one actually plug into any of this? Like, so you'd have basically a DSL that can like write the ZKP side of things, but then how are you actually using FHE? Like how would you as a developer interact and choose something to like, you know, set the parameters or make it, yeah, I'm just kind of trying to picture like how do people touch it? Ravital Solomon (32:13): Yeah. So I imagine you'd interact with both the FHE compiler and the zero knowledge proof compiler at the same time. Anna Rose (32:20): Okay. Ravital Solomon (32:20): We envision that these two need to be packaged together in terms of what the interaction would look like. I would say we're still kind of exploring what the API should look like. It is a bit challenging in terms of exposing some of the zero knowledge proof stuff to the developer. The FHE stuff is a lot easier to expose. You're really just asking the engineer like what kind of computation are you trying to run? What's going to be encrypted? What's not going to be encrypted? Anna Rose (32:46): Okay. Ravital Solomon (32:47): And that's really it. We can figure out the parameters for you. We can set up all these weird FHE circuits that that's a problem our compiler and hopefully other people's compilers as well will fix. Anna Rose (32:58): Are there some use cases that you've heard presented for FHE that are really, really compelling but you think are kind of impossible? Given that you're so deep in it and because you said you're a pessimist, what do you think is like maybe almost overhyped in the FHE world but you don't think is like really feasible? Ravital Solomon (33:21): I don't know if there's things I don't think are feasible, I would say there's things I don't think are feasible right now or for the next 1 or 2 years. The use case that lots of people will ask me about and engineers get really excited about is the intersection of fully homomorphic encryption with machine learning. Anna Rose (33:39): Yeah. Ravital Solomon (33:39): Can we do private training? Can we do private inference? And I always feel horrible when I have to break people's hearts and say that I don't think FHE in combination with machine learning is really viable at this point in time. When you think about the overhead from using FHE, it's pretty bad. So data blow up will be 10,000, 100,000x. The overhead in computation is 10,000, 100,000x. Can you explain to like Web2 companies? Yeah. We're going to blow up your database size by 100,000x. The computation will be a 100,000x slower. Oh my gosh. Is that OK with you? Anna Rose (34:23): And I guess you get privacy but I guess there you really get to see if it's worth it. Wow. That's crazy though. Are there sort of like lighter use cases where maybe it could work where like obviously I think when you look at ML, like obviously there's a huge range. You could do really, really sophisticated things. We could also do really simple things. Do you think there's like simpler examples that maybe could already be used in that? Ravital Solomon (34:46): Yeah. Yeah. I definitely think for very, very simple machine learning models, FHE could make sense but trying to combine FHE with modern day machine learning, the super deep neural networks. Yeah. I don't think that's viable right now. Anna Rose (35:01): When do you think it could be like given the current speed? Oh, 10 years, 5 years? Ravital Solomon (35:09): That's a good question. I think for this blowup in terms of size, maybe it'll be acceptable at some point in time if companies decide privacy is important enough or there needs to be like actual improvements to the theory behind FHE for the performance side. Maybe with some of the work in hardware accelerators, the performance will be good enough. I would say for that, I know some companies are working on hardware acceleration for FHE, both very large companies and startups maybe in the next 3 to 5 years. Anna Rose (35:42): Oh cool. She said it here. You're like, no I don't want to predict. Yeah. What's kind of next for you guys though? Like in turn you sort of mentioned that there's tooling that you're going to be releasing at some point people are actually going to be able to start engaging with it. Tell us a little bit about where you're at and what you see coming up in the next six months or so. Ravital Solomon (36:04): For us, we will be likely adding support for other FHE schemes in our FHE compiler. Right now we only support one particular FHE scheme that we think is well suited to a number of Web3 applications. Anna Rose (36:17): What's it called? Ravital Solomon (36:18): The BFP scheme. Anna Rose (36:19): Okay. Ravital Solomon (36:20): So the advantages of that scheme is that it supports fairly fast arithmetic on encrypted data and quite a bit of precision. So if you're looking to do 32, 64 bit computation, this is probably the scheme for you. In terms of the other pieces we're working on, the zero knowledge proof compiler is going to take a little bit longer than the FHE compiler. We need to glue together some proof systems, figure out what the API is going to look like there and combine it with our FHE compiler. And there's another part that I haven't told you about, but for FHE Ciphertext, they're actually quite large and it's not clear if developers are going to be okay storing those ciphertext directly on-chain. So we're investigating some sort of storage solution for that. Could you store the ciphertext somewhere else and some reference or hash to the ciphertext directly on-chain? Anna Rose (37:14): Can you explain that a little bit further? Ravital Solomon (37:16): Yeah, yeah. So very, very roughly speaking, instead of storing an FHE ciphertext on-chain, what if you were to hash the ciphertext store, the hash on-chain, which is very, very small. Anna Rose (37:29): Yeah. Ravital Solomon (37:29): And then when somebody needs the FHE ciphertext, they go retrieve it from another location. Maybe you would store the FHE ciphertext and something like IPFS, Arweave and you would have to figure out how the validators and users are going to go retrieve it. So I'd say this is more of an engineering problem, like how do you quickly upload, download things, that sort of stuff. Anna Rose (37:53): It's like, I guess it's taking it partly off-chain. Ravital Solomon (37:55): Yeah. Anna Rose (37:56): Would you ever imagine that being a rollup kind of situation? Like where it has its own off-chain action and there's like some, and this is the connection point on-chain, Ravital Solomon (38:06): You could do rollups in combination with FHE but it would be super, super inefficient at this point in time. I don't know like what the timeline is there. I would say I'm even less optimistic for the combination of rollups and FHE than I am for like machine learning and FHE. Anna Rose (38:27): Okay. I will say this, for me, this is a kind of a space that I haven't had that much of a chance to think about and even like all of the characteristics that FHE enables is still a little bit fuzzy for me. I guess like I'm still trying to figure out like what an application looks like in this. Would there be an application built on top of this or would it be something like, you sort of talked about like FHE smart contracts, but I'm trying to picture what like what's a user facing thing that lives on top of this that like we would use? I mean I guess, I mean I understood like the auctions idea but I'm even thinking like maybe closer to like a user sitting at the computer like dealing with an interface, not even like a developer user, you know what I mean? Ravital Solomon (39:17): Ideally they wouldn't even know they're using FHE. This is so Anna Rose (39:20): Yeah. Ravital Solomon (39:21): Far away from them. This is completely hidden behind the scenes that maybe they just know that they're getting privacy somehow be like just clicking a button Anna Rose (39:29): Yeah. Yeah. It'd be like encrypted chats or something like that. Ravital Solomon (39:33): Exactly, exactly. The user just gets privacy. They don't need to know about it. Yeah, they don't need to know the details. They don't need to know there's FHE and zero knowledge proofs hiding behind the scenes. Anna Rose (39:43): What kind of thing though, could you imagine like an end user somehow interacting with this on though? Like could it, what would they be giving? I'm just sort of, I'm trying to go even like further up the stack. Ravital Solomon (39:53): So I think for a private version of an exchange, ideally there would be very, very little from the user's end. It would just be like toggling something to execute a private order. Maybe there's a slightly higher fee but that would be it in terms of interaction. Anna Rose (40:10): But under the hood there would be like this private space where computation, it's all encrypted somehow. Ravital Solomon (40:17): Yeah, exactly. Anna Rose (40:18): Okay. That would be one example. In the smart contract example though, like how would somebody, like do you have any ideas for types of smart contracts where this would actually be used? And it's funny cause like ZKP people have definitely like had ideas around this, but I'm just wondering if the FHE use cases are different. Ravital Solomon (40:37): So I'm not sure like how well I can answer this question. Anna Rose (40:40): I know it's very vague. Ravital Solomon (40:41): Fairly, yeah, it's like fairly also early stages for us because we're still trying to figure out what like the API will look like on the ZKP side. So it's a little hard to say like what exactly will the user experience be like there yet? Anna Rose (40:55): Where would you like to see like more research? I mean you've talked about sort of that interaction between ZKPs and FHEs and maybe the lattice-based ZKPs would be a place, but yeah, is there a specific part of like the research landscape right now that you would love to see more of that would really help you guys? Ravital Solomon (41:12): Yeah, definitely that kind of interaction or intersection of zero knowledge proofs in FHE. We really need better zero knowledge proof systems for proving things about lattice-based relations and FHE. So if other people want to join us here, that would be amazing and we would love to have you. Anna Rose (41:28): Cool. So Ravital, thank you so much for coming on the show and sharing with us the story of Sunscreen as well as exploring FHEs again. Ravital Solomon (41:37): It was amazing to join you. Anna Rose (41:39): And I want to say thank you to the ZK podcast team, Henrik, Rachel and Tanya. And to our listeners, thanks for listening.