Introducing The Zama Confidential Blockchain Protocol, a cross-chain protocol for confidential smart contracts using FHE

Transcript

Woo. This is my seventh ECC actually. It's uh yeah, getting bigger and bigger for sure. I remember the first one I went to in 2018 in Paris. It was still very very very technical. Uh I think now it's a little bit more all over the place. By the way, how many people here are technical? Okay, I apologize. My talk is not very technical. I didn't really know if I were supposed to do something very very nerdy or something more like you know to talk about the protocol. So if you have more technical questions feel free to ask them at the end and I'll answer them. And for those interested we'll be publishing a very very very gory white

paper tomorrow. Uh and that will have everything. Uh so just making chitchat while I'm waiting to start officially. You tell me when I'm ready. Yeah. Yeah. We're good. Okay. Great. So, hello everyone. My name is Rand. Uh, I'm the founder and CEO here at Zama. I've been in crypto since 2013, so I've seen quite a lot of ups and downs. Uh, my background is actually machine learning.

I did a PhD in AI uh back in 2007 before it was actually working and then built one of the first confidential AI companies that got acquired back in 2019. So since 2020 I've been building Zama with my co-founder Pascal Pay who's one of the inventors of homorphic encryption with the idea to bring FHE and confidentiality to public blockchains. So maybe before we start, if it's okay with you guys, let's do a small experiment. Can you take out your phone? I'm not going to hack it. Don't worry.

Okay. Open your banking app. Any banking app, whatever. Revolute, any sort of like bank account you're using on a daily basis. And now give your phone open to your neighbor. Do it. Come on. Okay. So, you see this is actually what happens in a blockchain today. If you're using a blockchain for something like payments or for your actual assets, you're literally giving your open bank account to everybody so that they can see what you own. It makes exactly zero sense. We talk about blockchain and Ethereum and all of these chains as the future of finance, but not a single person in that room wanted their neighbor to see how much money they had.

Money and finance is very, very private. It's been like that forever. There's no reason to believe it's going to change today. So why is everything public on a blockchain in the first place? Well, the reason is because we need public verifiability. The whole point of a blockchain is that you can verify and not trust. And so to verify, you need to be able to recmp compute the state of the blockchain. And the way to do that is to take the data, take the transaction, and recomputee the state. So how can we actually have verifiability and confidentiality at the same time? So this is where homorphic encryption comes in. So the idea of FH is you can compute on the encrypted data

itself without having to decrypt it. So let's imagine I'm a user and I want to send money to a friend on a blockchain. Instead of actually sending the amount publicly and the balances being public, I would encrypt the amount on my side. send the encrypted amount in my transaction on chain. The validators, the node operators will have no way to know how much I sent because they don't have the decryption key. But the way the data was encrypted still allows you to compute on it and produce a result which itself is encrypted that the user can decrypt on his side. So it's basically like having end to end encryption for any kind of blockchain transaction, smart contracts. So this is a very very

big deal because you have no limitation in terms of what you can compute with FHE. This is Turing complete and you can actually have verifiability on the computation itself on the encrypted data without having to see the underlying value that was encrypted. So that's how you can actually have this public verifiability part and you know the confidentiality part. So one issue however is that if you want to have FHE you need quite a lot of computing power. I'm not going to lie about that. You know, we're talking big servers, GPUs, that kind of stuff. And that's just not going to fit on an L1 or an L2 today.

You know, you're not going to be able to run FHE on Ethereum itself. So, what we did is we found a way where we could enable FHE on top of any public L1 or L2 without actually having the L1 or L2 do the FHE computation. And the way that this works is through a network of co-processors that actually do the heavy lifting. So there's one technical slide, sorry. Um, so the way that the Zama protocol works, and this is an example for something like a token transfer, for example. On the client side, let's say the front-end app, the user would encrypt the amount they want to send. So in practice, it wouldn't be the user, it would be whatever app they're using who

does the encryption. And then they would generate a zero knowledge proof that they actually know the value that was encrypted and that they use the public key of the network they want this amount to be used on. This is very important because you want to avoid people just copy pasting data from the blockchain and then writing a contract to decrypt it. So you need to make sure the user knows what they're doing. Then they're sending that to what we call the Zama gateway which you can think of as kind of orchestrator for the protocol. The Zama gateway will verify the zero knowledge proof of the encryption from the user and send back an attestation basically saying yes this value is correct. You can now use it as an input

to a confidential transaction. Then the next step is the actual transaction you're making to Ethereum for example. So here you're making a regular transaction to a confidential token contract including the encrypted amount and the attestation that you can use this. This is then picked up by the confidential token contract, which is just a smart contract. We'll get to that in a second. But here's a trick. That smart contract needs to be able to subtract the amount from the sender and add it to the receiver. You cannot do that on chain because it would be just I don't even think it fits on 40 million gas to be honest. So instead what we do is the contract emits an event that says I want someone to compute uh FHE

addition taking those two values as input and putting the output at this location. Then a network of FHE nodes which are offchain pick up on those events. They're just listening to events from Ethereum in this case do the actual computation and store the result back on the gateway. And there's a bit of like a small consensus so that you can have multiple FHE nodes have to agree on the same value. So you see by doing that something we call symbolic execution what's happening on the L1 isn't a computation is the commitment to the circuit of FH operation that's supposed to be computed but the actual heavy computation and the storage of the data is done in the Zama protocol gateway

effectively. The second thing you want to store as well is the access control. So you want the contract to be able to determine who is allowed to decrypt the result of the computation. So in this case here you're allowing the user to decrypt their own balance kind of like you know makes sense and this is done again just by emitting an event which is picked up by a relayer that stores it on the gateway. So you can see this gateway as this sort of back-end service that just aggregates all their request and computation and also acts as a kind of DA for the system. Now the computation is done. The user wants to decrypt their balance. They make a request to the Zama gateway saying I'd like to see my balance. That actually first verifies

the user has permission according to what the smart contract said the user could decrypt. and then it triggers an MPC threshold protocol to decrypt a value and send it back to the user. The reason why we use an NPC thresher protocol is because there is one public key for the network which means there is one decryption key and you don't really want one person to have the decryption key. So instead we split it into a bunch of small pieces and send that to in this case 13 different operators each of which have a piece of the secret key and have to agree with a twoth3 majority in order to get the actual result. So none of that is visible to the user by the way. The user clicks on a button that

send says you know send $10 on his wallet and the wallet shows the actual balance. There is none of this is visible to the user. everything is happening transparently. So this is kind of how you know the magic works. And with this kind of protocol, we don't we don't actually have to worry too much about you know which L1 rail 2 we deploy on. We can actually deploy it pretty much anywhere that can run uh smart contracts. So there's going to be a token super vanilla token. We use it for protocol fees, proof of stake and governance. So we don't charge for the FHE computation itself. The FHE computation done by your smart contract is free. I know that kind of sounds weird because we're saying

that FHE computation is very heavy, but they're actually cheap. And so we figured we might as well just not charge for it. It's easier. What we charge for, however, is every time you want to verify an encryption and every time you want to decrypt something, we're going to charge a small fee. Those fees are going to be burnt. So it's 100% burn. And on the other side, you've got operators which have to stake and are getting rewarded through an emission schedule. As a developer, it's very easy to use this. Everything is in solidity. So, if you want to write a smart contract, we give you a solidity library that has encrypted data types. Those encrypted data types allow you to express which part of your contract is encrypted and also allows you to express who's allowed

to decrypt what in your smart contract. This is kind of a big deal because having this kind of programmable confidentiality means that you can build any kind of rule you want for access control to the data that your contract created. So if you want to build compliance, you're doing it at the application level. You don't have to worry about the user doing it. Uh we're also making things very very fast. So people say FH is slow. Actually that's not true. Blockchain is slow. FH is very fast in comparison. So since we started working on this uh FHE protocol for blockchain, we've been able to increase throughput by about 100x and we can now max out Ethereum when we launch

on it. Uh so effectively today FHE scales better than Ethereum which is a good starting point. Uh we're not yet a level where we can do a,000 TPS. That's going to come through hardware acceleration. So FPGAs at first and then eventually dedicated accelerators A6 for FHE. We've made some estimates. We think that on a single ASIC chip, we can get about 10,000 TPS for confidential transfers. So, put eight of them in a server and you've got almost 100,000 TPS in FHE. So, you know, you want to run Visa at scale, you want to run uh Swift on chain, no problem. Done. That's really important to keep in mind because effectively it means that FHE is no

longer a math problem. It's no longer a usability problem. is purely a hardware acceleration problem. Throw more money, throw more compute, it will go faster. That's it. It's that simple. And there, if there's one thing we know from engineering is that more compute is easy to get by. I mean, just look at how much comput LMs are using. This is tiny in comparison. And we're talking about one server doing this kind of stuff and not like a whole data center of GPUs. We've also made Zama very very cheap. Um, so we've made an estimate a confidential token transfer would cost about 1 cent for the encryption, about2 cents for the decryption and only about 400,000 gas on the L1 or L2 that you're

using. So on on Ethereum today, good thing is Ethereum gas fees are cheap at the moment. It would be about 10 cents of gas fee on Ethereum and about a third of a cent on something like Bass or other L2s. So the cost of a confidential token transfer with FHE with all the security, all the computation, all of these things is only about 11 cents on Ethereum today and about 1.5 cents on something like Bass. So it's effectively free, right? Like you know if you're not willing to pay 1 cent for a transaction, just don't use a bank because I can guarantee you they're taking way more fees than that. Uh so you know this is really how we have to think about this.

FHE is no longer at a stage where it's you know research is at a stage where we can now start putting it in production and so talking about that uh so we've already got some teams building some incredible apps for example there's a team called Zepher that's building an entire framework to convert ERC20 token into confidential tokens so think of it as a way to take any stable coin any token and turn that into a confidential token that have confidential balances confidential amounts whatever you want to protect. And they're building also a whole stack on top which allows you to use those confidential tokens and DeFi protocols. And this is something that's really important as well about FHE is you get composability on those

confidential assets. So you can use them just like you use a token by mix and matching them with all kinds of other smart contracts. Another example is a company called a token IGBP which is a UK based FCA regulated company that's building a natively confidential stable coin for the British pound. Uh so the issuance will be confidential, the transfers will be confidential, the amounts will be confidential, which again if you think about you know a financial institution wanting to use stable coins for settlements for global payments.

It's kind of important that people don't really know how much money they're sending to whom and for what right I mean it's sort of uh finance 101 that you want to hide your positions. Uh another great project actually Valer is in the team in the room here is called fellow. So fellow is a bank that cannot rug you. And the way they do that is they actually run completely on chain using FHE to hide your assets so that you can use it just like you would use a Revolute account. You can get your salary paid. Nobody would know how much you're getting paid. You can use a credit card and iband to spend your onchain stable coins which are again confidential. So think about it really like Revolute onchain where everything is that token that's encrypted with FHE.

And so if fellow goes down, it doesn't matter because those assets are on chain and you can just effectively take them out into whatever other wallet you want to use. So try to think about how amazing it is you want to onboard a billion people to tell them that they can actually use a bank account where the bank cannot rug them. I mean I come from Lebanon by the way. Lebanon got rugged massively by the central bank there. Just overnight said to people all your dollars in your bank account gone. So lots of people have a lot of trauma there. Um so this is going into test net live tomorrow on July 1st. Uh initially on Cipolia uh then we're going to mainet on Ethereum in Q4 probably around

October. Uh and from Q4 until the end of the year we're going to be adding more and more networks. So we're going to add you know other EVM networks L1's L2s and also have a TGE towards the end of November. And then finally in 2026, support for Solana. Uh I know this an Ethereum conference, but there's a lot of people in Solana, so we want to make sure everybody's happy. All right, thank you guys. And um if you have any questions, let me know. Any questions? Yeah. Uh thank you. Um question. Sure.

Yeah. Uh this is a simplified slide. Yeah. I wonder uh is the Sama gateway and F nodes would plan like currently is it decentralized or do you have a plans to decentralize them because I think like from what I understand or from what you describe it seems to be uh centralized things like run by No, no, no. So the Zama gateway is actually behind the scene an optimistic rollup. So we're using arbitrum uh Nitro rollup as a as a kind of gateway chain. So this will be as publicly verifiable as any rollup today effectively. Uh we just don't call it a rollup because you cannot use it to launch apps. We're just using the rollup

because we need something that is publicly verifiable for the orchestration. So the gateway is a rollup. Uh Ethereum is decentralized obviously. the FHE nodes we have multiple of them. Uh so initially we're only going to have three just because they cost around $30,000 per month to run. So I mean if we have 100 people who want to run that I'd be happy to talk to them but you know three to five initially is the goal but we can have as many as we want. That's not a problem. On the MPC side is more tricky. So MPC doesn't scale very well with the number of parties. So we used 13 MPC nodes which might not sound like a lot but actually it's more than most NPC protocols use and 13 is the number of

servers used by DNS for resolving internet addresses globally. So I think good enough as a starting point eventually we want to enable you know hundreds of MPC nodes and hundreds of FH nodes. Uh that's kind of what we have on the road map going forward. Okay. Uh, and by the way, all the operators are doxed, so people know who they're going to be. And all of them have billions of stake by running stuff for other protocols as well. So the goal here is that if someone cheats, you can identify them and then hopefully they get slashed not just on the Zama protocol, but it also gets slashed in their other protocols because who's going to trust an operator that cheats

anywhere? And and my second question is probably is not directly related to FH but is on the confidential like EC20 uh confidential token. So currently we are encrypting the amount that's being trans right is it possible some way to also encrypt even the recipient or even the sender. Yeah. Yeah. I mean you can build like a mixer in FHE that's effectively what this would do right. I think in practice if you want to build compliant stable coins is probably not such a good idea.

Uh like I was actually interviewed uh by the French Senate a few weeks ago and there was like the head of the European police there and I was telling them about oh look you know we're going to encrypt the transactions on chain and he looked at me he was like h I don't think we're going to like that. And when I explained to him that transactions were not anonymous, as in they're traceable, it's just the data inside was encrypted, kind of like a messaging app. When I send a message to you on a encrypted messaging app, your telecom operator sees that we sent each other a message, they don't they just don't see the content. It's the same thing we're doing here. And that's actually okay because if you can trace back the sender and the receiver, you can always trace it back

to a KYC wallet at some point. an on-ramp, off-ramp kind of stuff. That's all people need. They just need to know who the people are. They don't care about the amounts and balances as much as we do as individuals. I'm just being very realistic and I could I could just like, you know, you about all of these things, but literally I spoke to the guy and he told me, "Don't make it anonymous." Uh yeah. Yeah. I I have a question. Yeah. It's um so the checking the the ERC the the ERC20 that confidential ERC20 doesn't check if the transfer is possible. It doesn't check if you have enough balance to make this transfer. It just asks the Zama gateway if uh actually no it does

it does okay in that case I I have a follow-up question. If the contract can check if you have enough balance that means um it is possible to check if the encrypted value is less or more than another value. In that case, could it be possible to just make sure that you just do is it less than this? No. Is it less than this? No. Until you get the actual. No. So the reason you cannot actually if you look at the example here, that's what this does, right? So in FHE, there is no branching. Why? Because the value is encrypted. So by definition, you actually don't know if that condition was true or false. So if you look at here, you can see that there is e-win 64 transfer value, right? And in this select operator you have this FHE dot

less or equal. So what this is doing is is checking in FHE that the amount is less or equal to the balance of the sender. And that is is effectively returning an encrypted boolean yes or no. And the select operator is a multiplexer that basically says if the encrypted amount is zero then set the amount to transfer to zero. If the uh if the encrypted you know check is one then send the actual amount and so you're the transaction is actually going through you're not reverting the transaction it's just that the amount being sent will be zero the user doesn't have the balance right uh and so this is really again powerful because you can write the kind of logic in just a line of code

effectively right so it's pretty simple okay thank you very much for thank you everyone [Applause] [Music]