Episode 248: Revisiting FHE with Rand Hindi from Zama

Transcript

Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will 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. This week, I dive back into the topic of FHE with Rand Hindi, CEO at Zama. FHE stands for fully homomorphic encryption, a crypto system that allows for computation to occur on encrypted inputs. We talk about the FHE landscape, what specific use cases it's ideal for, where the technology is at, how FHE differs from MPC or ZK, and look into

some of the nuances of the different types of techniques that teams are using to achieve this cryptographic environment where one can do computation in a truly private manner. But before we kick off, I want to share an announcement from one of our partners on the latest ZK summit, the Web3 Foundation. They are hosting an in-person event called Sub Zero, the Polkadot Developer Conference, in Lisbon on November 28th and 29th. This year's edition will bring together the global Polkadot community and provide an open introduction to those looking to learn more about Substrate, Polkadot's framework for building custom blockchains. Learn more and apply at subzero.polkadot.network.

I also want to highlight that there's a fresh batch of jobs over on the ZK jobs board. If you are looking for a new opportunity to work with the best teams in ZK, be sure to check out their job postings. I'll add the link in the show notes. Now, Tanya will share a little bit about this week's sponsor. Today's episode is sponsored by Anoma. Anoma is a set of protocols that enable self-sovereign coordination. Their unique architecture facilitates the simplest forms of economic coordination, such as two parties transferring an asset to each other, as well as more sophisticated ones like an asset-agnostic bartering system involving multiple parties without direct coincidence of wants, or even more complex ones such as N party, collective commitments to solve multipolar traps, where any interaction can be performed with an adjustable

zero-knowledge privacy. Anoma's first fractal instance, Namada, is planned for later in 2022, and it focuses on enabling shielded transfers for any assets with a few second transaction latency and near zero fees. Visit anoma.net for more information. So, thanks again, Anoma. Now, here is Anna's interview with Rand Hindi from Zama. Today, I'm here with Rand Hindi, the CEO at Zama. And in today's episode, we're going to be revisiting the topic of FHE, or fully homomorphic encryption. Welcome to the show, Rand. Thank you, Anna.

Thank you for having me. Before we start in, why don't you tell us a little bit about yourself and maybe your background, what led you to want to work on this problem? Privacy is something I've always been interested in. Um I actually started coding when I was 10 years old, and back in the '90s, I had created a social network uh with a friend of mine. And at some point in high school, there was this uh very tall, very big guy that was bullying me, and I thought, I have to find something against him so that he actually stops. And I went into the database of the social network we had built, and I found some private messages he was sending, and I found some very crunchy stuff about, you know, him. I went to him at school and like, "Hey, if you don't leave me alone, I'm going to

tell everyone about that." And he left me alone. But it did leave me with a sentiment that I had done something really, really, really wrong because Yeah. just, you know, I mean, just Sounds pretty rough. I know. Well, I mean, it was the '90s, right? Privacy on the internet wasn't a topic yet. I mean, it was for the cypherpunks, but it wasn't like mainstream. But nonetheless, you know, as a teenager, I felt like I did the right thing for myself, but I did the wrong thing from an ethical perspective. Like, just because I was the person administering the website didn't mean that a right on people's privacy.

Mhm. And so, that was a topic that was in the back of my mind and when I got into machine learning, you know, 15 years ago, it was clear to me that we're going to need more and more data and we're going to do anything interesting with AI and therefore privacy has to be a central issue in machine learning and that's when I got interested in that. So I did a PhD in machine learning. After that, I started a company doing machine learning with privacy. We had built a private voice assistant. So that company got acquired by Sonos. So today in the US, if you're using the voice assistant on your Sonos, it's basically our technology.

And after that, I started Zama, which is working on fully homomorphic encryption as well as doing a lot of investment related stuff. Cool. Actually, interestingly, we just did an episode on machine learning and just started like this is not a show that usually covers that topic and we did also talk about sort of machine learning in ZK, like kind of under I love that topic. I love that topic. This is something I'm actively investing in, by the way. Machine learning and ZK is like such an amazing intersection. I love it. Yeah, that's kind of an interesting path that you're going, machine learning privacy.

Did you feel like it sounds like the product that you had built was actually already taking privacy into account, but as I understand it, a lot of machine learning like research or companies, projects aren't. So they're feeding in a lot of data without really thinking about the privacy. I think the assumption here is that like, oh well, if there's so much data, there's no way that any like private data would really be found, but I think as we talked about in our last episode, that's not really the case. Yeah, absolutely. There is this kind of false dichotomy between privacy and I would say data usage in general, you know, we've been fed this narrative that if you want to do something useful with data, you have to give away the data.

But the beautiful thing about homomorphic encryption and I would say secure computation in general is that it enables you to actually do something with the data without actually seeing the data, with only having an encrypted version of the data. And this is a fundamental paradigm shift in the way that we actually use the data because we're moving from a world where people were trying to monetize data itself to a world where people are using data to monetize a service on top of the data. And if the service is what you care about, you don't need to see the data to operate anymore.

True. Although if you make that private, aren't there still ways to find out things? Like if you if you're basically training a model on encrypted data, but like the outcome, could the outcome still like reveal something about the input? Yes, well, that's not a topic related to cryptography, right? It's it's it's a topic related to machine learning. And indeed this is a problem with machine learning, you know, neural networks in general tend to learn too well.

And if there aren't enough examples of something, most likely the network is going to learn that that example is the the only one that exists, and so you're you're able to infer some of the inputs from the outputs, in particular if those inputs are not very common or something which are kind of edge cases. A lot of people are working on that, you know, there are ways where you can fuzz the data a little bit in order to make that more secure. Um but yeah, I mean that that's a very very big problem in machine learning that unfortunately cryptography doesn't solve. Mhm. Now let's turn our attention to FHE though, which is the basis of I guess the work you do today. Why did you choose to work on fully homomorphic

encryption? When I was running my previous company, we were working on this private by design voice assistant. And you know, a voice assistant is a machine learning model that processes your voice and returns some kind of answer. And to do that, it needs to have a microphone that listens in to what you're doing and, you know, sends that to the cloud for some kind of processing. So, for us, you know, it was obvious we needed to find some kind of privacy solution, but we couldn't find anything that could be done server-side. And so, we ended up doing everything on the client directly. But at some point, I hired someone in my team who actually was a cryptographer.

And he told me about this new technology. So, this was like 2014, 2015. Uh so, we're talking years ago. He told me about this new technology called homomorphic encryption, where you could actually do the processing on the server on encrypted data, so that the server actually doesn't know anything about the data it's processing. And when I heard about it, I was like, wait, hold on. Does that mean that the user can ask something to the voice assistant, what the voice assistant will send back to the server is an encryption of the voice. So, instead of sending something like, hey, what's the weather in Paris, it will be sending like or like whatever, you know, however you pronounce encrypted data.

Uh but this encrypted data would still keep some mathematical properties. And so, you'd still be able to run your machine learning algorithms on it, produce a result which itself is encrypted. So, you know, the computer that does the computation, you know, it hears and it returns But the user can decrypt it. It can hear, you know, it's like, whatever, 23° in Paris. When I heard about this, I was like, oh my god. Why isn't everyone doing that? Like, why isn't this technology mainstream? Why are we still, you know, sending unencrypted data to the cloud? And the answer, quite frankly, was simple. It just didn't work. Uh you know, it was a great idea on paper, kind of like ZK 10 years ago. Great idea on paper, but if you try to do anything useful with it, it would either take

like, you know, days to get a response back, or it just wasn't powerful enough, or you couldn't use it, you know, easily. Like it just wasn't ready yet. But now it is. So, what's what's changed? Now it is. So, you see how I'm I'm leading into the next question, right? Uh yes, exactly. as an interviewer on this one. So, what happened is about 4 years ago a new generation of homomorphic schemes started appearing that enabled to do much more complex operations much faster without as much complexity as the old ones. And so, the work we've been doing at Zama specifically was to take this technology, which is called TFHE for

Torus FHE, and package it in a developer framework that enables any developer without any knowledge of cryptography to use it. And because we made it easy to use, it became easy to use for machine learning, for blockchain applications, for pretty much anything you wanted to do. So, I'd say the big breakthrough cryptographically speaking happened about 4 years ago. And what really is enabling homomorphic encryption today are the tools we built on top of it that enables applications to start using it without having to worry about the cryptography. Let's define FHE for for our audience. I'm going to do a quick throwback to an episode I did in April 2020 where we talked to Flavio Bergamaschi from IBM and we did actually

an intro to FHE, but as I told you before we started recording, I'm going to need a refresh because it's been a while and I haven't talked about it in a long time. And so, I think it would be really great for us to explore what FHE actually is. The idea of fully homomorphic encryption is that you can do processing on encrypted data without actually having the decryption key. So, imagine you're a user and you want to access some kind of service in the cloud. Traditionally, you would send your data to the server, the server would process it and send back a response. The problem is that the server doing the computation actually has your data because it has to do processing on it.

With homomorphic encryption, instead of sending your data unencrypted, you would encrypt your data with your own private key that's on your device, send your encrypted data to the cloud, but the way it was encrypted still enables you to run, you know, mathematical operations on it. You can do additions, multiplications, apply functions on it. So, the server doesn't know what it just got. It still runs its algorithm. The result it produces itself is encrypted under the same key that the user sent the inputs in, and the server sends it back to the user who can then decrypt it. So, from the user's perspective, nothing changes. You're just sending data and getting a response, but the difference is now the data is encrypted end-to-end. It's encrypted when you sent it, it's encrypted during processing,

it's encrypted when you got it back, and at no point whatsoever the private key is sent anywhere. You sort of mentioned this kind of special encryption. When you describe this, part of me goes like, why is it hard to do? And then it's like, why do you need this special encryption? What is that exactly? So, why don't we actually why don't we start with, why is it actually hard to do? Sure. The idea is very simple. Homomorphic encryption is something people have been talking about since the '70s actually. In fact, my co-founder Pascal Paillier is one of the inventors of homomorphic encryption and one of the OGs, you know, from from back in the days. What's really hard first is you have to find a mathematical construct that can do

those homomorphic operations. And by that, what it means is if you take an encryption of X and you apply a function on the encryption of X, you want to get as a result an encryption of f of x. So, you you know, you have this kind of like transferring property from the encryption to the data itself. And this is something that's not very common. So, the first thing is you have to find those homomorphism in mathematics. The second problem is, well, now you found them, do you know that they're secure? Because, you know, cryptography is about security. You know, there there's a million cryptographic protocols that are easily broken. So, you have to make sure that what you just came up with is actually secure. And it turns out that creating something homomorphic and secure is an extremely complicated

proposition. So, the first time someone did find that for multiplications was back in the '70s. It was actually the ElGamal scheme. The first time someone found this for addition, so being able to do secure homomorphic additions was my co-founder Pascal. So, that was a Paillier scheme. And the first time someone found a way to do anything homomorphically, so fully homomorphic encryption, that was in 2009 with Craig Gentry. So, it's very, very new. So, we've only really had 10, 12 years to figure this out.

And so, that's why it's been so difficult to actually crack. But once we had that, the problem wasn't just that. The problem was, well, you have to find the right parameters. You know, cryptography is this kind of thing with like 100,000 different knobs. And if you put them in a in the wrong sequence, in the wrong order, you're breaking everything. So, either the result is wrong or it's insecure, right? So, you know, you have to find just the right parameters that things are secure and correct. Very similar to how you do it in ZK, by the way, right? Kind of like in cryptography in general. So, finding those parameters is extremely complicated. And this is something that required deep expertise in cryptography.

So, that again is something that, you know, we had to figure out a way to automate. You know, so creating compilers that can take some arbitrary program in Python or C and turn that into a homomorphic circuit. So, all of these different things kind of add up in a way that is just wasn't possible to do. Mhm. You mentioned homomorphisms. Homomorphisms, what are it like what is that even? You sort of said you're looking for certain something. So, yeah, tell me tell me a little bit more about that. It just means that the I mean, the structure is the same or the shape is the same. So, the idea of homomorphic encryption is even though the data is encrypted, the structural property of the underlying data is actually intact. So, when you

apply a function on the encrypted data, this function translates into the unencrypted realm after you've done the decryption. So, think of it like like a language. Uh if I speak to you in English, you know, I'm using syntax, using grammar, and you're using that to understand what I'm saying. Yeah. If I were to speak to you in French or in some language that you don't understand, you know, that language would still have structure, right? Uh you could still record that language, you could still do something with the sentence I just said. You wouldn't understand it, but it would still be a correct sentence just in a different language.

If I gave you the Rosetta Stone to understand it, then you could decrypt what I just said in the conversation. So, it's kind of the same thing with homomorphic encryption, you know? You're just changing the language in which you're speaking the data, but you're not changing the syntax and grammar and everything else around it. Okay. So, that's the homomorphism. I think I understand that, but like you would also talked about these like the special encryption. Is that the same thing? Is that special encryption the same? Okay. So, you know, traditionally when you encrypt data, you cannot do anything with the data, right? It's just uh random gibberish data points. When you encrypt it homomorphically with a homomorphic encryption scheme, so a special kind of

encryption in that sense, Yeah. it's still going to be a random thing you're looking at, but this random thing has mathematical properties where you can apply functions on it, right? And so, that's why we're saying this is a special kind of encryption. You're not just encrypting the data. You're encrypting it in a way that you can still manipulate it using the same mathematical functions that you would without encryption. What is actually outputted? Like I'm kind of picturing like when you're making that encryption, like cuz I I think I'm so used to talking about like circuits and things in the ZK world, but like what are you actually using to do that? Does it look more like hashing? Like what's maybe something that we might be

familiar with? Yeah. So, the program itself that's running the computation is a circuit. Like every program is just a circuit. The inputs are just like a bunch is just a vector of a bunch of different numbers. And those numbers in combination effectively represent a message. So, a certain number of bits of information that you just encrypted. So, the way that it looks actually, the ciphertext the way it looks is the first few bits are the messages. So, this is what you actually want to compute on. And the last few bits are random noise that you're adding to guarantee the security of the encryption.

And so, whenever you're doing a computation on it, you're trying to compute on the bits of message without actually having the noise overflow on it. And that's the whole complexity of homomorphic encryption is you're managing this noise reservoir at the same time as you're doing computing on the useful bits of information. And this is really what's so complicated about it. But it basically just looks like a vector of numbers, like a huge one. Okay. And when it comes out, so this is sort of like I'm sort of picturing it going into something that's doing the computation.

When it comes out, there's there must be like a de- decryption phase. Yes. Yeah. Is it special? Or does it look kind of the same? It's the same thing as encryption, right? It's a The encryption and decryption of homomorphic encryption is very cheap and very simple. The computation you're doing on encrypted data is what's very costly and very complicated. I see. encryption and decryption is very simple, you know, you would just basically you take a message, you encrypt it into this vector of random values, you operate on that, and then you take this vector of output encrypted values, and then you decrypt that, and you end up with just one value. That's pretty much when what how it works. When you say it's costly, how is it costly? Is it costly in terms of like energy spent

doing the computation, time, like the size of it? Like what's the cost? Uh the time, yes. So, what happens is when you encrypt the data, so you've got a ciphertext. Uh let's say half of it is message bits, so actually useful stuff, half of it is random noise. In practice, what you do is you put the noise on the last few bits, and then you keep some kind of padding in order for the noise to grow. Why? Because every time you do a homomorphic computation, the noise actually grows and grows and grows and grows. And if you do too many computations, the noise ends up overflowing on the actual data that's useful, and if you try to decrypt that, you're just getting a random value.

So, this is actually doing those computations very fast, but to avoid the noise overflowing on the data, you need to apply a special operation called bootstrapping, which effectively reduces back the noise to some sort of small value as if you just encrypted the original data. And this is the costly operation. Homomorphic encryption is extremely fast until you have to bootstrap, which is very often. And so, that's why we say that it's very slow. It's like is this cleanup operation, you know, like it's easy to break things up, but it's very hard to clean them up. And it's kind of the same thing with homomorphic encryption.

You sort of mentioned this multiple computations. Is this happening on the same inputs, or is this like within a FHE system, you're kind of getting lots of inputs, doing computation, putting out some outputs, and then more is coming in. Is it on one or is it on many? I guess it depends on your application, right? You know, in the case of a for example a neural network for machine learning, you're getting, you know, sometimes a million inputs that you have to process at the same time. But if you're looking at, you know, predicting the price of something, maybe it's just like five inputs. It doesn't really matter. It is completely up to the application itself.

But the computation happening inside, would one set of inputs be going through multiple computation patterns within it or is it always like a single path? Again, I think that depends how you design your circuits. You could do whatever you want. It's just a circuit, right? Once once the data is in, you can really pretty much do anything you want. And I think this is also one of the big differences today is it used to be that with homomorphic encryption you were limited to very simple things, additions, multiplications. You couldn't do deep learning, you couldn't do very complicated flows with the actual data. This no longer the case today. The new homomorphic technologies that we have enable you to do pretty much anything you want, however complex the circuit.

So, we can do deep learning, we can do homomorphic smart contracts for blockchains. We can do homomorphic databases. The difference is going to be, of course, the cost and the run time, but all of that again is getting better and better every day. Mhm. That idea of a fully homomorphic smart contract, what does that even mean? Can you explain what that like Is that something like you have a smart contract that then deals with an FHE black box and returns something? Or are you talking about like running the computation inside FHE?

Yeah. Yeah, yeah, yeah. I'm talking about having smart contracts where some of the states can be encrypted and you can operate on encrypted states directly. Think a traditional, you know, ERC-20 token smart contract. You've got the balance. The balance right now is a map between an address and a value, right? And so, everybody can see how much tokens, how many tokens a specific address has. And the reason why people need to do that is because, well, you know, if you want consensus, people have to agree on the values. And so, that was pretty much the only way of doing it. With homomorphic encryption, you could have the exact same smart contract, but you replace your value by an encrypted value. So, you still have a map between

an address and an encrypted value, but because you can operate on those encrypted values, you can transfer tokens on chain in the same exact codes in exactly the same way. It's just that nobody can see the value unless you have the key to decrypt it. Mhm. And so, I think, you know, the beautiful thing about homomorphic smart contracts is they're just smart contracts. It's just that you're no longer operating on integers. You're operating on encrypted integers, if you want to. Mhm. Do you picture this kind of needing its own special blockchain to be able to use private keys?

modify the consensus. Okay, yeah. This isn't like it can be on a public blockchain and then have this sitting on top. Our stuff is written in Rust. So, nothing prevents you from just, you know, using that in your smart contract engine. It's just in practice, uh in order to make this efficient and to make it work in a blockchain, you can modify the consensus algorithm to take into consideration the specific homomorphic encryption requirements. Um so, I think in practice, you would want to modify the actual low-level consensus algorithms to actually fit with this homomorphic computation.

But it's not You don't have to, right? It's just, uh you know, it's just code running really. Mhm. Would you need some sort of like in the ZK case, there's often like some curves that need to be included somehow or enabled? Do you have anything like that like a smart contract blockchain would need to have in it for FHE to be used with it? Uh yeah, like every cryptographic scheme, I think, you know, you need specific parameters and you need a a setup for this to actually work. Same thing here, really. Uh but not saying that wouldn't be easily uh deployable. I think we have all the building blocks necessary to make this happen. And in fact, we are actually building an example testnet uh for homomorphic smart contracts to show that it's doable

today. Interesting. What kind of blockchain are you building that with? Like what's what's it similar to? Is it like a geth fork or No, unfortunately, unfortunately, we're doing something much simpler. I mean, unfortunately. Uh we're going for something much simpler. I think, you know, we're we're currently prototyping with both substrates and substrate and tendermint. Okay. it's going to be a very simple, you know, delegated proof of stake type of uh consensus algorithm. Again, our goal here isn't to build an Ethereum competitor of some sort or anything like that. Our goal is just to show that it works. Interesting.

And if other blockchains wants to use it, you know, they can use it. Everything is open source. But really, the goal here is just to show that it works and to implement all the different building blocks necessary for this to actually be useful. I want to kind of compare FHE to things like MPC or zero knowledge. Have you done a lot of research into MPC and stuff? Not so much as I did in FHE, but I know enough about it, yes. So, what are the different maybe use cases? Like where are where are times where you think MPC or ZK would be more appropriate and where are times where you think FHE makes more sense? I think MPC is great whenever you need multiple parties to actually, you know, do some something together. So, I think, for

example, MPC is an exceptional exceptionally great solution for uh managing your secret keys, your cryptographic secret keys. Uh it's really good whenever you have to do some kind of like threshold decryption protocol, things like that. Voting, maybe? Maybe voting, yeah, why not? Um however, the problem with multi-party computation is that you still have to communicate with a lot of different people by doing that. So, in the case of a blockchain, people are like, "Yeah, yeah, whatever, you know, we already do that anyway. This kind of like the whole point of decentralization." But, in practice, if you want to deploy MPC, there is this extra level of complexity having to manage different nodes interacting. So, I think that's something that makes it very difficult to use in production and to understand what it means. Homomorphic

encryption and Diah Grant is a very simple client-server interaction. You know, you have an application on a server, you have a client connecting to the server and sending data. The only difference is you're now encrypting the data being processed. So, there is no difference in terms of architecting your software versus what you do in plain text. But, MPC, you have to, you know, manage this thing. The second problem is no matter how fast the MPC stuff can go, you're always going to be bounded by the network time. Mhm. And that's going to be fundamentally something that prevents you from doing super low latency applications, right? If nodes are communicating at large distance, there is nothing you can do to make that faster, however good your computation.

Because homomorphic encryption is running on a single machine potentially, there is unlimited vertical, you know, scalability potential. So, sure, today homomorphic encryption is slower than MPC, but it has more opportunity to be faster long term because the constraints are not the same. Mhm. Um so, I think both are good. And in fact, you know, in our protocols for homomorphic smart contracts, we use an MPC protocol for distributed decryption and key generation. So, we still use an MPC part, but specifically for what MPC's amazing at, which is the key stuff. All the computation is done with FHE. What about ZK? So, ZK for me is not a privacy technology. ZK is a provable correctness technology. It's a

scalability technology. It's not a privacy technology. When people talk about privacy with zero knowledge, what they really mean is I'm do I'm going to do the computation somewhere else and prove to you I've done it. Yeah. But the computation that's being done like this elsewhere place where the computation happens might not be private. Exactly. So, think about multiple users wanting to collaborate on some computation, right? If they wanted to do that with a ZK protocol, either you would need to design a specific purpose ZK protocol to do that, so it's not very generic purpose, or those people would need to do this computation on a hub somewhere and then send the proof to the blockchain. If that happens, who guarantees privacy on the hub itself?

You know what I mean? So, like you're only really displacing privacy from an on-chain privacy problem to an off-chain privacy problem. Mhm. But you're not actually guaranteeing privacy. In a blockchain context though, if you look at something like Zcash, they are using it in a blockchain context. There's no open data happening. They're using the ZKPs to prove that transfers had occurred, basically. Sure. And that's fine. And then again, you know, you can always design a a special purpose protocol for something. Uh here I'm talking about taking some arbitrary smart contract and running it privately for multiple users interacting together.

Uh there's just no way that you can do a multi-user uh ZK generic smart contract protocol because those users would need to talk to each other outside of the blockchain anyway. Mhm. I feel like there are teams trying to do that and I don't I don't know their arguments to to bring to the table, but I would be curious if they're listening, if they want to weigh in on this on Twitter, maybe after it airs. If there is any way to learn more about that, too, if that's the case because, you know, I mean, I think it's it's more of a structural thing, right? It's uh it's just not what it's meant to be used for. And in fact, I think that the holy grail of privacy and and and blockchain is actually to have homomorphic ZK rollups. Because if

you can do homomorphic smart contracts on the layer one, well, they're still going to have scalability issues, Mhm. right? That means just like any layer one thing you have scalability issues. And so what you want is to be able to do ZK rollups on an FHE smart contracts. But then that's equivalent to doing provable ZK FHE, right? And so I think that what's going to be really interesting is this intersection between ZK and FHE as a way to create private scalable blockchain solutions and smart contracts. Interesting. Are you doing any work in that department? Are you working with any of the rollup providers?

Uh so we started exploring what it means to actually do a, you know, ZK FHE. It's an extremely complicated problem. Uh the reason is that we looked at all the existing technologies and homomorphic encryption is such a big circuit, it's a huge computation. It just couldn't fit in any proof that would make sense, right? Uh and so I think, you know, a big problem we have right now is really just trying to just prove it in a time that is acceptable. Well, first of all, we're trying to prove it all together and then prove it in an acceptable time, but we do think that this is going to come from some kind of collaboration, you know, I don't think we're going to be able to crack every problem ourselves.

You know, we are the FHE company, there are amazing ZK teams out there and, you know, collaborating on that would be a fantastic project. Mhm. I wonder if FHE will go the path of ZK because originally, like you had said, it had sort of these unusable circuit size, it was just too too slow, too big. And with a lot of optimization and the introduction of techniques from different kind of realms, it's gotten to become more and more efficient. Now there's ZK SNARKs that don't need the trusted setup, so you have like you have seen in the last 3 years or since this show started 4 years ago, like incredible incredible progress.

is still extremely slow. There's still a bottleneck on proving. Well, doesn't it depend? I thought the prover is really fast. Wait, which one is it? Starks and Starks? I always miss it mix it up. Starks. So like those kind of like big job purpose provers are still very slow. And the reason is that the amount of computation needed to prove something is still very high, right? It's it's much bigger than just doing the computation in the first place, right? So you know, proving something with ZK just adds this extra layer of compute, which just takes time. Mhm. And and this is the same thing that we see with FHE is we cracked all the mathematical pieces, right? Just like the ZK community cracked all the mathematical pieces. But just like the

ZK community is now getting to the point where they need a hardware acceleration to make this cheap and fast enough. In FHE, we are getting to the point where the last mile is hardware acceleration. So to put it differently, we've solved every problem in FHE on the cryptography side, on the usability side. We just need this extra boost from hardware acceleration in order for this to become extremely cost-effective and fast to run. What would hardware acceleration look like for FHE? What do you need? Are you just looking for some type of ASIC that would just like make FHE fast quickly?

Yeah, absolutely. Absolutely. Not just ASICs, so we're also looking at photonics for acceleration. Any any kind of accelerator would work. But the idea is that this bootstrapping operation, which is very slow in homomorphic encryption, really boils down to doing a bunch of polynomial multiplications, right? And the good thing is that doing that requires an FFT or an NTT, which is very similar to what people need to accelerate in ZK as well. So the same accelerators which are being used to accelerate ZK with those NTTs can actually be repurposed to accelerate FHE potentially and vice versa. And so it's really interesting, but in the past 6 months, I've seen an increasing number of ZK acceleration companies start getting interested in doing FHE

acceleration. Interesting. Um so all these things are converging eventually, right? And I think that you know, we're going to see the first accelerators for homomorphic encryption available in the next couple of years. And my bet is that by 2025, homomorphic encryption is basically a done deal. Mhm. It's done. It's solved. You can use it anywhere. It's cheap. It's applicable. It's powerful. It's easy to use. It's done. Do you feel like FHE is meant to take the place of SGX in a way? For these TEEs or trusted execution environments? Is that what it's meant to replace in a way? Cuz it sounds like it has all that flexibility.

Yeah. Yeah. Because why would you need a secure enclave? I mean, what's the point in that case? There is no point. Yeah. I would even say that enclaves unfortunately have multiple attacks that have been built that have been proven on them. So it's fine if the enclave is on your phone, for example, right? Like, you know, because you you're the one with the phone. But if you're going to be offloading the computation to a server Mhm. that you don't trust, where an attacker potentially has hardware access to a server can, you know, do some kind of power consumption analysis or whatever, then there are ways you can potentially attack the enclave. So homomorphic encryption is the ultimate solution that, you know, TEEs are trying to solve short term. I see.

So again, you know, it's it's all a question of being pragmatic. Can you use, you know, trusted environments today? Can you use MPC today? Sure. Do it. It's going to be faster than FHE in many use cases. Are they going to be necessary once FHE bridge this final gap in the next couple of years? I don't think so. So I think, you know, it's going to be like machine learning. You can use a bunch of different techniques, but why bother if you have something like deep learning that can do everything? So it's going to be the same thing with FHE. What are the security risks of FHE though? Like so, you know, we just mentioned side channel attacks on TEEs.

I'm assuming for FHEs it shouldn't be the case. Although, if you do have dedicated hardware, could it be? There is no side channel attack on FHE. There are no side channel attack on FHE because there is no private key server side. You know, in a trusted environment the private key is hidden in the hardware pretty much, right? So, you know, it's there. That's why you can attack it and reveal it. In FHE, all the computation server side is done with a public key. So, there is no private key to retrieve because there is no private key sent or used in the first place on the server. The private key is always on the client side with the user.

And you don't think like certain kinds of computation would not be traceable because of like energy or there's no like signals or anything that would come through? There's absolutely nothing. If you can break homomorphic encryption, you're breaking post-quantum cryptography. Oh, wow. Okay. That'll be bad. That'll be bad. For other reasons. For many reasons. so it is post-quantum FHE? Yes, it's based on lattice It's based on lattices. So, pretty much the same hardness assumptions as, you know, the NIST post-quantum standards that we have now.

Interesting. Let's then talk about where the ecosystem and kind of community is at. So, I know that, you know, the ZK community's been growing, booming, still amazing. The MPC community, I know there was like efforts to build that up. I believe that is a rolling ecosystem. Where's FHE at as an ecosystem? It's growing. Uh it's growing. So, we started a community uh a year and a half ago called fhc.org, Mhm. Uh which pretty much is the community now for homomorphic encryption. So, we have monthly meetups where we talk about homomorphic encryption. So, it's very technical. It's not uh it's not like a entrepreneurs community. It's a cryptographers community. It's really

about cryptography. So, we do meetups every month. Uh we've got a bunch of amazing researcher that came to speak. Uh Intel came to speak, Google came to speak. And we also do a yearly conference. Usually around one of the existing conferences, Eurocrypt or Asia Crypt or Real World Crypto dedicated to homomorphic encryption. And there's also a Discord server which is very active where people talk about homomorphic encryption and also where library providers give support to users. Um so I think you know it's it's getting there, right? I think we are formalizing this community. And when I say we I don't mean Zama, I mean fhe.org which is independent from Zama. And it's growing is great and more and more

people getting interested in it. It's probably where ZK was two years ago. Cool. Tell me about Zama then like now let's revisit, you know, the beginning of your story definitely led to this but what is Zama? How big is it? You you sort of mentioned this earlier what you're actually selling is this sort of black box, the ability for people to like use use these tools but not need to necessarily like, you know, develop the cryptography underneath them. So yeah, tell me a little bit more about Zama. Sure. So we are a homomorphic encryption startup. We build and design cryptographic protocols that we then put into open source developer frameworks that makes it easy for developers to use

homomorphic encryption. So everything we do is open source. Everything we do is published. So we do a lot of research on cryptography. We do a lot of work on packaging that into frameworks. And on top of those frameworks of course you know we're starting to build higher level protocols like the blockchain smart contract protocol or some machine learning specific stuff. Um so we try really to provide toolbox for application developers to use homomorphic encryption. So the company is a couple of years old. We were founded late 2019, early 2020. My co-founder Pascal Paillier and I were friends for years and we have wanted to do that. So when I sold my previous company, you know, a week later we started Zama. It was like a back-to-back thing, which I don't recommend anyone

doing. It was You need some time off, maybe. Yes. Yes. Take 6 months, travel the world. I should have done that, but you know, I was just too excited to get started on this. We have about 50 people in the company right now, half of which are PhDs, researchers in cryptography. So, we are the largest team of research working on homomorphic encryption. We're fortunate enough that we've raised the significant fundings. We've raised over 50 million euros already, uh which gives us plenty of runway to actually build, you know, this technology. The company is French, but we're not really based in Paris. People are pretty much all over Europe mostly. Uh you know, it was only four of us when COVID happened. So, you know, we had no choice but to be a remote-first company.

Remote. Um you sort of mentioned Python. Are you building tools for people to build applications in Python to then run through this? Is that one of the kind of toolkits that you're doing? Yes, absolutely. The framework itself is built in Rust. So, all the cryptography is implemented in Rust. All the library stuff is implemented in Rust. And on top of that, we built a compiler that can convert from some Python program down into a homomorphic circuit that this Rust library will then execute. So, the reason we did this is because we wanted to make sure that data scientists working on machine learning had a very convenient way of plugging their existing Python code into our

homomorphic compiler. Uh so, it's really just it's a product decision. You know, we we don't implement anything in Python. Python is just a surface language that's being used for developers' purposes. But, you can use Rust as well if you want to. So, this isn't yet There's like no blockchain native languages that you imagine compiling down into this yet. Like you don't have any sort of Solidity Well, we thought about it. That's a good question. I think I mean a lot of the a lot of the blockchain world is moving to Rust anyway. So, I think you know, like we're probably going to stick with Rust for the time being.

You know, doing a compiler for solidity, I don't think is necessary. Plus, I'm pretty sure that at some point someone will do a Rust compiler that goes to the EVM directly. And so, we'll do Rust on Ethereum as well, even if it's not already done. So, I think we're going to stick to Rust for the blockchain part. You also mentioned something this is kind of going back to the FHE part. You had mentioned sort of the term TFHE. You had this other thing that's maybe specific to Zama. Tell me what that actually is. In homomorphic encryption, you've got three main technologies. Three main like schemes that people are using. You know, just like in ZK, you've got Stark, Snark, Plonk for example. In FHE, you've got BGV, CKKS, and TFHE. These are the three dominant technologies people are

using. BGV and CKKS are very fast, but they can only do a certain number of operations. Beyond that, there's just too much noise and you can't do much about it. TFHE can do fewer operations, but it can bootstrap extremely rapidly, meaning that you don't have to care about how many operations you're doing. You just keep on going forever. So, we took TFHE and we've extended the capabilities of TFHE to be able to do much more than the original scheme that was published a few years ago by a woman called Ilaria Chillotti, who works at Zama today.

And we've made TFHE able to do large integer arithmetics, able to do complicated deep learning stuff, pretty much anything you want it to do. So, are the other schemes useful? Yes, there are use cases where these can be useful, but we think that TFHE will be the dominant technology because of the versatility and how powerful the primitives are in it. I want to sort of crack open some of these acronyms. So, what is the T in TFHE stand for? Oh, TF The T stands for torus FHE. Torus, like Torus. Like like a donut. Okay.

not like the animal, like like like the like a mathematical torus. Okay. like a donut, right? Okay. Uh they could have called it donut FHE, I guess. It would have been the same thing. The idea behind TFHE was to use a torus as a way to represent uh the FHE computations, things like that. So, it was just like it was a vision of the mind, if you want to how the mathematics kind of worked. Mhm. What other projects would you say are in your industry? Like other teams that you maybe collaborate with or are also sort of working on this FHE.org initiative? Well, we work with many many many companies. I mean, we've got over 20 different partners, ranging everything from hardware acceleration to cryptographic libraries to, you know,

machine learning stuff. There are more and more companies working on FHE specifically. You know, 6 months ago, there were maybe like three, four of us. In the last 6 months, for some reason, it just blew up and now there's like 10 new companies doing FHE, which is Cool. I don't know what happened, you know, maybe we showed too much stuff recently and everybody was like got excited about it. But, it's great, right? Because it's going to make things move faster. Uh and also they're also good for us, you know, it's kind of nice to have a little bit competition finally, right? It it felt kind of lonely for a while. There are some very good teams working on FHE. And I think, you know, it's it's a big enough pie that, you know, a few companies can share it as long as we are the number one in it,

of course, you know. I see. I see. Entrepreneurial. Um what are the other projects though, in case just for us to know? So, there is a company called Duality that a bunch of very good cryptographers started. Uh they're more focused on BGV, CKKS, not so much on TFHE. So, you know, we're very similar in many ways. We just have a very different strategy and a very different technology stack. Mhm. But you know, they're they're they're pretty established. There is a small company that just did their seed round to do homomorphic smart contracts as well called Sunscreen. Oh, yeah. Wait, I know them. This is uh Ravitel. This is ex-NuCipher folks, right?

yeah. That's them. Intel is working on acceleration. Uh then all the big guys are starting to look into that, of course, as well. But I would say generally it's a trend, right? There are more and more companies uh in that space. But you know, some of them are just using FHE. Some of them are inventing new FHE stuff. Ravitel, her team are using existing schemes. They're just packaging it in a way that is convenient for smart contract developers, pretty much. And they're doing very interesting work, you know, we're looking at what they do, of course, you know, taking inspiration in some cases, too. We are much lower down the stack as well, you know, we build new FHE primitives as well as build those tools on top of it.

Mhm. I want to bring it back to machine learning. So, you said you have sort of partners who are doing machine learning type stuff. How far away are we really from having private model creation under the hood of an FHE, do you think? Well, it works. It's just very slow right now. so it's doable already, but okay. It's doable, it's just slow. Okay. When is it practical to use? Yeah. Um you need the accelerators, so a couple of years, I would say. is your 2025 kind of idea. yes. 2025, that's my vision. That's where Okay.

That's where we're That's where we're going. Nice. So, yeah, so you can do it today if you don't care about waiting for a while. What is a while, by the way? Like when you say that, like what are you talking about? Like do you mean like hours days months? for training it would take a very long time. Okay. For inference, if you're trying to make a prediction with a machine learning model, you know, you you can do it in a few hundreds of milliseconds or a few seconds. Mhm. Uh it could be a few minutes if you're trying to do some super complicated stuff. So, it's still acceptable, right? But, it's not real-time as people are used to, you know, like super snappy. I do something in 1 millisecond later I get the response kind of thing. We'll get there with the accelerators though. The

accelerators are going to provide a 1,000 x acceleration for FHE. Uh so, something, you know, that takes like a minute will take a few milliseconds. Very cool. Rand, thank you so much for coming on the show, sharing with us sort of the journey that you took to Zama, but also letting me ask all those questions I had about FHE and haven't had a chance to ask in a long time. So, thanks a lot for that. Thank you, Anna, for the conversation. Looking forward to it. I want to say a big thank you to the ZK podcast team, Henrik, Tanya, and Rachel, and to our listeners. Thanks for listening.