Zama: FHE - the Holy Grail of Blockchain Privacy - Rand Hindi. Ep. 614

Transcript

it was too slow to be useful. Couldn't really use it for real applications like AI or blockchain. As a developer, it was too difficult to use. So, we've solved all of that. FHE today, at least Zama's version of FHE, is 100 times faster than it was when we started a company. It's easy to use as a developer, so you don't have to learn any cryptography. And you can use it for anything from databases to AI to smart contracts. That's why we decided to build our own protocol called the Zama protocol that enables confidential smart contracts on top of any public blockchain L1, L2, Solana, EVM without having to change the actual blockchain itself. So it works exactly the same as if you integrated it

natively, but instead of having to run the FHE computation on chain, it's done by what we call a network of co-processors who act on behalf of the application that's running on Ethereum, for example. Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Fedria Ans and today I'm speaking with Rand Hindi who is the CEO of Zama. So, Zama works on fully homorphic encryption in the blockchain space. Before we dive into that, let me tell you about our sponsor this week. If you're looking to stake your crypto with confidence, look no further than Chorus 1. More than 150,000 delegators, including institutions like BitGo, Panta

Capital, and Ledger, trust Chorus 1 with their assets. They support over 50 blockchains and are leaders in governance on networks like Cosmos, ensuring your stake is responsibly managed. Thanks to their advanced ME research, you can also enjoy the highest staking rewards. You can stake directly from your preferred wallet, set up a white label node, restake your assets on IGO or Symbiotic or use their SDK for multi-chain staking in your app. Learn more at chorus.1 and start staking today. Hey guys, I want to tell you about Nosis, a collective of builders creating real tools for real people on the open internet. Nosis has been around since 2015. In fact, it started as one of Ethereum's very first projects. And today, it's grown into a whole ecosystem

designed to make open finance actually work for everyday people. At the center of it all is Nosis Chain. It's a lowcost, highly decentralized layer 1 that's compatible with Ethereum and secured by over 300,000 validators. So whether you're building a DAP, experimenting with DeFi, or working on autonomous agents, Nosis chain gives you a solid neutral foundation to build on. But Nosis is more than just infrastructure. It's also tools that people can actually use. Like Circles, for example, lets anyone issue their own digital currency through networks of trust, not banks. And then there's Metry. It's their smart contract wallet that makes it easy to access circles, manage group currencies, and even spend anywhere Visa is accepted thanks to their integration with Nosis Pay. All

this is governed by Nosis DAO where anyone can propose, vote, and help guide the network. And if you want to get involved, running a validator is super easy. All you need is one GNO and some basic hardware. To learn more and start building on the open internet, head to nosis.io. Nosis, building the open internet one block at a time. >> Rand, thank you so much for coming back on. >> Thank you for having me again. >> So, um, you joined us last in late 2023, so almost two years ago. Um, and Zama was mostly known as a um, fully homorphic encryption research and

tooling company. I hope that's that's that's a fair description. Ho how how has Zama evolved since since then over the last few years? >> Well, that's a good question. So, when we started Zama 5 years ago, uh we wanted to solve the problems with fully homorphic encryption FHE. Namely, that it was too slow to be useful, that you couldn't really use it for real applications like AI or blockchain, and that as a developer, it was too difficult to use. So, we've solved all of that. FHE today, at least Zama's version of FHE is 100 times faster than it was when we started a company. It's easy to use as a developer, so you don't have to learn any cryptography and you

can use it for anything from databases to AI to smart contracts. Our business initially was to sell the technology to other companies who wanted to use FHE in their own products. Uh in particular, companies building confidential blockchain projects. uh for example, Phoenix, Enko, Sheiba are all uh users of Zamas technology. One thing we realized though doing that is there was a number of people reached out to us wanting to build confidential applications on existing public blockchains like Ethereum Base or Salana. And for that we didn't really have a solution because our technology had to be integrated in a new chain at the protocol level. That's why we

decided to build our own protocol called the Zama protocol that enables confidential smart contracts on top of any public blockchain L1, L2, Solana, EVM without having to change the actual blockchain itself. So it works exactly the same as if you integrated it natively, but instead of having to run the FHE computation on chain, it's done by what we call a network of co-processors who act on behalf of the application that's running on Ethereum, for example. And so now effectively we've shifted our business from selling technology to other infrastructure companies to providing a protocol that

any app developer could use to build confidentiality on existing chains. >> I think there's a lot to unpack here in terms of architecture. So typically what we see is people starting up new chains kind of like if the existing chains aren't up to to their specifications. So tell us about kind of like building this FHE environment on existing chains and how that works on a technical level. So the way that FHE works is you take encrypted data and then you have to basically do FHE computation on the encrypted data. This is very expensive compute-wise. The second problem is if

you want to have composibility between smart contracts, you need to use the same encryption key. So the same public key to encrypt all of the data amongst those smart contracts, which means you also need a way to do selective decryption without you know compromising the security of the whole protocol. So those two problems we solved using a network of FHE and MPC co-processors that basically monitor what the application wants to do and does it on behalf of the application. So let's say for example I want to do a confidential token transfer right so I want to send you some money on chain some stable coins but I don't want people to know how much money I sent you or how much

money you have or I have so you want to keep the balances encrypted on chain and you want to keep the amounts encrypted on chain. The way you do this with the Zama protocol is you deploy a confidential token contract. So, it's just a regular smart contract on Ethereum, for example. And you specify in your contract that the balances are encrypted and that the amounts are encrypted. And you also define the rules for who's allowed to decrypt the balances. So, for example, the user should be able to decrypt their own balances, but you could also start building some compliance features such that, you know, enabling your accountant uh to access your balances or whatever, right?

What happens though is that Ethereum itself wouldn't do the FHE computation or the decryption because it doesn't have the capabilities to do so. Instead, when the smart contract says something like add this encrypted amount to this encrypted balance, it emits an event which is picked up by the Zama co-processors that basically say, "Oh, someone is asking me to take those two inputs encrypted inputs, perform this addition, and store the data at this location." So we're effectively decoupling the application logic and the commitment to what's supposed to be done from the actual execution that is happening offchain in the Zama protocol operators.

And by doing that it means that there is virtually zero slowdown on Ethereum itself because there's no computation happening there and everything is offloaded to a network of GPU operators. te tell us about that network of co-processors and kind of like how I become um a part of this and kind of what the security implications are um for people who kind of use um uh the confidential blockchain protocol as part of the Ethereum or Solano or whatever stack.

>> There are two components to a protocol. The first component is the FHE operators. They do the FHE computation. Technically, this can be anyone because the FHE computation is done completely publicly. So there is no private information needed to be an FHE operator. You just take the operation, compute it, and post it to the ZAM protocol. Anybody can publicly verify it. So think of it like any blockchain protocol, right? It's a publicly verifiable computation. The part that's more tricky is how do you handle decryption? So the way that we do that is the smart contract can define access control logic in the contract itself. So it can say you know if this condition is

true allow this person to decrypt XYZ value in the contract. This also emits an event which is picked up by a different set of operators which actually run a threshold MPC protocol for to decrypt the data according to what the contract allows them to decrypt. So that MPC protocol, you know, has to hold by definition like a secret, right? The the the the like basically the pieces of the secret key that allows you to do the decryption. So you cannot have random people run that because otherwise, you know, well, how do you know they're not just cheating? So what we did in the Zama protocol is we basically ran uh an RFQ, right? a

request for you know for operators uh where people had to prove that one they were able to run infrastructure in a very reliable way because you know you don't want people to block the protocol and secondly that they already were securing billions in other things so the people who are going to be running the MPC protocol for Zama are validators with billions at stakes in other protocol uh wallet providers ers that are securing hundreds of billions in assets. Uh infrastructure companies who are responsible for some of the biggest blockchain projects uh custodians uh who are holding assets for institutional

customers. So the idea here is that the limited sets of people running the MPC protocol, so 13 operators in the case of Zama together bring 100 plus billion dollars of reputation security on top of whatever stake they put in designer protocol itself. And that's really important, right? Because in the case of Ethereum, you know, I mean, you have what a million validators they can be anybody and it doesn't matter because anybody can be a validator. But for NPC protocols, and that's true of all NPC protocols, you can only have a limited number of people participating. And so you have to make sure that those people are the most trusted, reputable companies in the world. So the

the logic here is that anybody can run an FH node eventually. It's just publicly verifiable computation. That's fine. But the number of MPC nodes and operators are going to be limited to very high quality uh reputable companies. And if they cheat, arguably they lose more money than they have in Zama because their whole business would fall down. Like, you know, if I don't know if if a tier one custodian cheats in the Zama protocol, they're not going to have many customers left after that, right? >> Yeah. Um, tell us about so kind of there's 13 of these uh these uh co-processes in the MPC uh round.

>> I'd like to mention by the way that 13 is more than any MPC protocol in production has today. If you look at everybody else doing NPC, they have three to five nodes. We have 13, which is already way more than anybody has has has has deployed. >> And um what's the quorum? So kind of how many people actually need to uh how many of these entities need to work together in order to kind of uh decrypt um >> uh so you need technically nine out of 13 to decrypt. uh what we are working on now is a way to combine zero knowledge proofs with the MPC protocol so that each of the MPC nodes has to provide a zero knowledge proof that they've done

the MPC computation correctly and if you do that you can actually have even better security because you can have what we call verifiable MPC uh you know one thing about MPC is that you know you trust the majority is honest but you don't have a way to verify by who individually might have cheated, right? So in the case of Zama, as long as nine out of 13 nodes have run the computation correctly, then the result is correct. But you know, if all nine of them have cheated, you don't have a way to know it. And so adding zero knowledge proof to that would be a way to identify individual cheaters in the MC protocol and slash them and do whatever appropriate thing you have to do on top of that. But this is an active

area of research. So it's not like there is no solution to that today. >> Um just just to understand kind of like how much is at stake here. So if nine out of the 13 collude um and I mean I understand this is uh unlikely in the catastrophic failure of the protocol. But what uh what's the worst they can do then? It depends on the application, right? Uh I mean obviously if they collude, they could decrypt and see your money, right? So they could tell how much money you have, which is bad for privacy, but I guess is, you know, financial.

>> I think the question is kind of like can can they can they kind of um divulge secrets or can they steal money? I think that's kind of like the spectrum we're talking on, right? >> It depends on the application, right? So if you if your application uses a decryption of something to trigger some financial you know side effect then obviously forging a fake decryption could lead to triggering the wrong smart contract logic >> right. Uh so one example where this happens is let's say you have a confidential token and you want to you know uh bridge it to a non-confidential token. So you want to go from confidential to non-confidential.

Someone has to decrypt the amount that needs to be bridged out of the confidential token, right? If I can if I can produce an arbitrary value, technically I could just, you know, bridge out as much money as I want from the bridge contract. But this is a problem that you have with any kind of protocol where you're relying on some kind of I would say majority assumption. So that's the reason why you need to work with extremely highly reliable operators. So what we're saying here is yes sure there are 13 of them but those 13 operators are trusted

you know at the tune of 100 plus billion dollars already today. So the stake they bring is huge. I I totally understand that and I think kind of I mean we have the same thing kind of for multisix that kind of upgrade uh layer 2s and bridges and so on. So kind of like I I think kind of like I I just um I I'm I'm not critiquing the setup um per se. I'm just trying to understand what kind of the the the the risk landscape kind of looks like. Well, see the thing is that if you think if you think about cryptography, right? There's really only two ways to deal with decryption, right? Uh or let's say there's only two way to deal with composibility on a shared secret state.

One way is have a shared public key and therefore you need a way to do decryption correctly. So that's what we do at Zama. The other way is to basically have interaction. So people just basically do a bunch of of transactions to the protocol, you know, to basically commit their own result. So that's actually a good a good explanation of the difference between FHE based and ZKbased privacy protocols. ZKbased privacy protocols don't allow you to have computation and composability on the secret state because you cannot compute on a ZK proof, right? You can only prove you've done something. So if you want composability, you need the different parties involved in the shared computation to basically make a transaction and go back and forth in a

protocol. So you're basically doing a bunch of interactions, right? That's okay if the transactions are simple and everybody's online, but if people are offline, it doesn't work, right? You need everybody to be here to do that. The only way to have composability in an offline asynchronous manner is to use confidential computing FHE TMPC which by definition means you need to use threshold decryption for the decryption. There's just no other solution. It doesn't exist. Like that's a universal reality of cryptography today is either you have a bunch of interaction, everybody has to be online or you need to have effectively like a

decryption network that takes care of doing decryption for people. >> Yeah, fully granted. What's the process of replacing one of those 13 entities? So say I I have a um reputable um validator service kind of like that stakes to the tune of I don't know uh $5 billion uh and kind of I I sell it or kind of I get acquired or I just decide to quit. Um what what happens then? Can I kind of like pass pass on um my uh part of the MPC pie to someone else or do I need a new ceremony?

>> Yeah. Yeah. Yeah. We can do what's called re-sharing uh which means that you can securely uh hand over you know or change the NPC set uh NPC participant set. uh in the Zama protocol, the way that we do this is there there are two effectively reasons why you would want to change an operator. Either the operator is no longer available or maybe you know they've been too slow uh and maybe there's like a better one we can replace them in which case it's just a simple kind of handover that we do based on epics. So every x months or whatever, we haven't really decided this yet. We effectively look at who has who have been the least performant operators and

we offer people to replace them. However, in order to be an operator, you must have been running a Zama test net for some time to prove that you've got the DevOps capabilities and that you're not just rich, but you can actually run infrastructure, right? Because this is not just about stake. It's also about capacity to run critical infrastructure. Um, so that's one thing. The second thing is if an operator gets caught cheated, anybody could basically propose make a governance proposal uh asking to either penalize or slash or replace the operator providing some proof that they cheated. So, for example, if you're monitoring the NPC network and you see,

oh, you know, uh, Zama's node has been misbehaving, you just file a governance proposal on the Zama governance uh, DAO pretty much saying, I've caught this guy cheating. Here's the proof, and this is what I'm suggesting that we do about it. And then people vote on it. The reason why we go with governance-based proofs uh sorry governance-based slashing is because there's so many reasons why an operator could have made a mistake right maybe the data center went down or maybe you know like there was a software bug uh that deployed or something like that and we want to make sure that we can distinguish between malicious intent and honest mistake and I think it's not fair to slash the whole stake of someone just

because you know their data center went down for like an hour, right? Uh and you see that in blockchain in general, by the way, Ethereum aside, which is a unique exception, most protocols have flexible, I would say, slashing policies that take into account the reality of running infrastructure in the real world. Um so again, you know, in our case, we're trying to be extremely pragmatic. What matters to us is that we offer, you know, a very highly reputable secure protocol uh doing the best that technology today allows us to do.

>> Cool. Um tell us about the incentives for the operators. So kind of I'm I'm one of those 13 companies that kind of uh kind of takes part in this MPC um pool. Uh what's in it for me? >> You get rewarded with Zama tokens. Uh so all of those operators have to stake uh and they get rewarded proportionally to their stake uh and also we're thinking about introducing performance-based rewards. So effectively we look at how quickly each of those nodes have responded on average and try to uh overcompensate those who are very good right uh again you know the idea is to have sort of a a competition for who's providing the best service

possible. uh token holders can also delegate their stake to those operators. Uh so in that sense that protocol is closer to like a delegated proof ofstake protocol uh where you have like a fixed number of validators and then as many people as you want can delegate on them. >> What's the jurisdictional and geographical um distribution of those um entities? Because kind of like in I mean >> pretty Yeah, that's a good that's a good point. Yeah, pretty balanced. Uh so we the Genesis operators are based in Asia, Europe and US.

>> Okay. But kind of there's there there's not nine kind of uh there's not a threshold of nine kind of like in any one geographic area or jurisdiction. >> No, no, def definitely not. Uh I'm just trying to think about it. No, no, there is not. Uh no, there isn't. just simply because we have yeah we have at least four in both Asia and in the US. We do have quite a few operators in Europe. Uh but even within Europe they're not within the same country. So I guess it depends if you consider Europe to be one geography like you know is a validator in Switzerland the same as a validator in France? I would argue probably not.

Uh but if you just take I would say region uh it's pretty balanced actually. >> Okay cool fantastic. Um then tell us more about the governance that kind of decides on the slashing policies. So kind of like say my my data center goes down, who do I appeal to for mercy? >> Well, technically if nobody files something against you, you don't have anything to do. You only get slashed if someone actively proposes to slash you. Uh so we do it the other way around, right? like we we we assume that you know you're honest uh in the sense that you know if you've been offline for an hour that you have a good reason to have been offline for an hour. Uh but if someone doesn't believe

that because you know let's say you've been offline three times this month which is unacceptable because you know we we expect people to offer 99.9% uptime um then you know someone can say hey you've been offline way more than you're supposed to and then it's on you to prove that this wasn't your fault. Uh again like think about it how you would do it in the real like in the real world um outside of blockchain right in cloud for example if you're working with another company as a partner and they fail to abide by whatever agreement you guys had together you're not immediately punishing them you know the first thing you do is tell them hey what's up right you know like you know can you explain to me why this happened and then most

likely there's a good reason for that I think one thing that's important to remember is uh Ethereum itself can only rely on proof of stake on chain because the validators are anonymous. You have no idea who's participating in the protocol. In the case of Zama, every single node is publicly known. So you know which company, which entity is running which of the nodes, right? So everybody's completely doxed and that's why you're able to bring in reputation and off-chain stake as part of the economic security and I think this completely changes the way that you think about proof of stake and slashing because you're no longer just dealing

with some random person on the internet. You're dealing with a multi-billion dollar entity that has way more to lose than the protocol. >> Totally granted. And then kind of once kind of I make proposal to kind of slash someone else. Is it just um token holder >> token holder or how how do how do you decide? >> Yeah, token holder voting basically. >> Okay. >> With a threshold obviously, you know, like you know, you need at least some participation. You don't want >> you don't want someone to propose to slash someone during Christmas and nobody's participating because they're off with their families or something, right? Usual governance related stuff.

But again we keep governance for critical parts of the protocol. So operator slashing changing the reward the reward emission rates uh things that materially change the security of the protocol. >> Okay. Tell us about the throughput that ZMA currently uh supports. >> Mhm. Um I mean it depends on the application again for something like confidential payments uh where the payments are pretty independent of each other usually we can scale as much as we want. Uh so I'm pretty confident that by summer next year 2026 we'll be able to do thousands of confidential transfers

per second across multiple different chains. Uh right now we're going to launch on Ethereum mainet first. So the first chain we're targeting is ET mainet. ETH mainet has limited capacity. Zama the pro Zama protocol can already support more transactions than Ethereum itself can support. So the bottleneck is not FHE. The bottleneck is blockchain. Uh and I think that this is going to be true for virtually every common use case. The only thing FHE is not capable of doing and by the way is not designed to do are things like uh high frequency perpetual trading. Uh by the way there is no cryptography that would give you

submillisecond order book matching MPC FHE ZK just this this just not how the technology works right. Uh I think for that you need to use something else. uh where we see FHE really playing a strong part is anytime you want to do payments, anytime you want to do you know uh swaps, lending so I would say uh not high frequency trading type of applications but importantly I think that FHE is going to be used for long-term storage of confidential assets because if you look at the landscape of various confidential computing technologies you've got ZK T's MPC C FHE basically right FHE is the only one that

actually currently offers the highest level security longterm. So if you want something that is postquentum that is extremely secure FH is really the only thing you can use right now. >> So FHE had a reputation for being slow right where where does that come from? It was slow a long time ago. Uh I think you know most people have not really used FHE in practice yet. So that's why they still have this impression. But as I mentioned you know we can already go faster than Ethereum. Okay. So granted Ethereum is not the fastest chain right and I think you know before Zama can support uh 10,000 100,000 TPS. We still have a bit of work. Uh but we're going

to get there. FHE increases exponentially performance-wise and that's mainly due to a combination of better cryptography so new techniques that we invent good software engineers doing you know good job implementing cryptography and hardware acceleration so moving from CPU to GPU to FPGAs to ASIC basically that gives you a 10x every time so the difference between a CPU and an ASIC is roughly a 1000x cost performance ratio uh so you know I'll just give you one We've we've done some estimates of what we could get on a single server using A6 for FHE, right? So just one box, not multi- server, just one box you put in

data center, we could currently get to 80,000 confidential token transfer per second on a single box with an ASIC. So you could run you could run like you know visa three times on a single server in FHC if you're using A6. >> Okay. So kind of uh currently we're using CPUs and then kind of like you get a factor of 10 for going to GPUs and then another factor of 10 for >> um FPGAs, right? So and then >> and then another 10 for ASIC.

>> Okay. And then uh what's um what's the timeline for this and what are kind of the uh the bottlenecks um that you're introducing? >> No real bottlenecks. I mean hardware is hard. It's in the name. Yeah. Right. >> So I think you know you need quite a bit of time. So moving from CPU to GPU, we've already done that. Uh so the TFHRS library that we use as the back end for the Zama protocol works on both GPU and CPU. Um, we're starting with CPU on Ethereum mainet just because we don't need more than that. Uh, we're moving to GPU Q126 once we start supporting other chains than Ethereum mainet. Uh, so B, BNB, all

of these things that require more performance. Uh, and then we're going to move to FPGA. So we recently open sourced what we call the homorphic processing unit which is a completely open-source FPGA accelerator for Zama's FHE technology. Uh so that's going to be the I would say blueprint for Zama's ASIC which is going to take us probably two to three years to build uh and quite a lot of money right uh because you know the the ASIC we have in mind is is a chip as big as a GPU effectively uh so that's very difficult to build uh most likely we're going to probably have multiple failures in the process uh so I estimate that it's going to be two to

three years of work and $50 to $100 million. Um, it's not impossible. It's just like nobody has done it. So, we're the first one to attempt that. >> Maybe let's let's dig a little deeper here. So kind of I I think most listeners are familiar with CPUs and GPUs, but tell us about um what um how they how uh field programmable gate arrays. So FPGAAS um and A6 kind of uh h how they evolve from that or kind of how they behave different than a normal GPU, >> right? So CPUs and GPUs are programmed like software. Okay. So you write C code

and then that runs. The GPU runs that in parallel. Think of like matrix operations that are can be done massively parallel. CPU is more I guess like branching logic type of operations. An FPGA doesn't run software. An FPGA think of it as an array of gates. very crudely speaking, and you're programming the gates, as in you're doing literally low-level electronics, saying this is an end, this is a this is an or, and I'm going to connect them together with a wire. So, it's almost like you're doing raw electronics, but instead of actually, you know, printing the uh the circuit on a on a chip,

you're using a an array of gates to do that. So it's similar to how you would build an ASIC, but you don't actually have to build the ASIC because you have a programmable hardware in a way, right? Um so FPGA usually is good as a stepping stone towards an ASIC. So you build your FPGA accelerator and then you try to build it in a way that moving to ASIC will allow you to scale the performance that the FPGA offers you. Uh so an FPGA typically runs in, you know, a few hundreds of megahertz. Moving to ASIC could be, you know, one, two gigahertz. Uh, an FPGA typically has a limited size just because there's like a physical limit to

how many stuff you can put on it. With an ASIC, you could go much bigger and build a huge ship if you wanted to. Uh, so the way that we look at things, we look at FPGA as a stepping stone towards ASIC, uh, a blueprint if you want. >> Okay. This is this is a huge investment, right? And you just said that kind of like the the idea for how to build this FPGA, you you open source that. >> Yeah. Yeah. Yeah. I mean, everything we do at Zama, 100% of everything we put in production, the code is open source. And the reason for this is we don't want people to trust us on what's running. We want them to be able to verify what's running. And I think, you know, that's one of the things people don't talk

enough about in blockchain. People talk a lot about consensus. to talk a lot about you know economic security. For me I think the most important part of a blockchain is public verifiability. If you cannot verify yourself what has been done then it's no better than running a web two cloud service effectively. Totally granted. I I I was getting at the at the um economic viability of this. So kind of when you say it's open source, I mean I I can I can view it and I can review it. Um but can I also repurpose it? So can I use is it does it have a permissive license >> for non-commercial use? Uh if you want to use it commercially, you need to get

a license from Zama >> or you need to use the Zama protocol or any kind of Zama services, right? So the reason we open source it is not to make it free, right? We're a commercial company, you know, we're not we're not a nonprofit. The reason we open source it is so that people can see what's running and not have to trust us when we tell them that this is secure. >> Cool. We we touched on this a little bit. Tell us about uh the Zama token um and uh what it does. So, can you you already said that kind of like the the the entities that are involved in the uh MPC protocol kind of need to stake them. Uh but but give us a bit more context here.

>> Right. Um so there are two type of operators in the Zama protocol. You have FHE operators that run the FHE computation and you have MPC operators that do their threshold decryption. So both of them need to be rewarded in some way. So the way that we do that is that they have to stake Zama tokens and they then receive Zama tokens as a reward. Those Zama tokens they get as a reward are based on an emission rate. So we basically mint Zama tokens to distribute to them pratta of their stake patha of the performance parata of the kind of work they did and so on so forth. So very vanilla kind of emission reward type of uh of of mechanism. So that's the one first utility of the token. It's

just literally just people participating and rewarded. The second utility is paying fees uh on the user side. So every time I want to encrypt or decrypt data in the Zama protocol, I need to pay some Zama tokens. So those Zama tokens are burnt. Uh so this is like a burn and mint kind of model here. So we burn 100% of the protocol fees and then we mint the rewards uh for the operators. Uh so the way that we charge for the Zarma protocol is based on volume. So the more someone encrypts and decrypts the the cheaper the fees actually get for that person. Kind of like you would expect it in a web to SAS product in a way right

like the more you use it the cheaper it gets. We're using the same kind of logic here for effectively the onchain fees. So it's payment of the protocol fees. It's uh rewarding the operators and the third is voting on governance proposals. uh so slashing operators, changing the emission rates and other things which would be material to the protocol. >> I mean don't hope this happens but kind of say Zama for some reason kind of goes downhill, right? Um there's a lot kind of hanging on these tokens and the token governance. So as someone kind of like who's used um a Zama based application on say Ethereum mainet um what's the

worst that could happen to me after the fact um if kind of say Zama market cap goes way down and someone buys up you know 50% of the Zama tokens to kind of do weird governance stuff or kind of I mean what what how exposed am I after after the fact? That's a good question. I think this is a generic question about governance attacks on protocols in blockchain, right? I mean, there there's nothing really that we're doing on the ZAM side that's different. If anything, actually, governance has less of a potential impact than in many protocols where governance could literally drain the treasury of the DAO or something like that. In the case of Zama, you cannot vote to drain the treasury uh simply

because the treasury is just not something that governance manages in our protocol. Um, so what you could do is you could slash operators effectively, right? So you could say, "Hey, I want to slash this person. I'm going to slash everyone." So it's more of a denial of service attack that could happen more than it would be like an active draining attack. So there is no financial gain for you to do that unless you're like a Zama competitor who just wants to take down the Zama protocol. >> But could could I um decrypt um things after the fact?

>> No. No, you couldn't. You wouldn't be able to because even if you slash all operators, someone would need to basically vote to get those operators back in. Right? So, as I mentioned, in order to be an operator, you have to go through uh like a a proving process. You have to prove that you're able to run the protocol and that you know you've been uh that you're capable of doing it, right? So for you to do an attack like that first of all you would need to have introduced publicly enough operators to control the protocol right. So like somehow you would need to have promoted at least nine operators

uh that are trustworthy without the community basically saying oh this is an attack and then you have to vote without people being like this is an attack. Don't forget people can always fork if they want to, right? Like if the whole community says this is completely wrong technically, you know, they could also decide to just take the protocol and then move to like a different set of operators. Uh this would be the worst worst case scenario. >> Yeah. But going forward, right, but kind of like backward looking. So kind of like if I have confidential things that are already committed to blockchain kind of like they hang on the identities of the 13 entities that were the operators at the time. So kind of like if I manage to kind of replace nine of them by cronies by kind of and I mean a tax

could be fairly cheap if kind of like the the the market cap tax, right? So if if I manage to kind of subvert um the thing it's the security is also compromised backwards looking not just forward looking right >> yeah but I mean think about it logically though right uh if the market cap is so low that you can just buy up you know 51% of the supply or whatever right then it means by definition that there is no activity on the Zama protocol like there would be no meaningful amount of money in the protocol at such a low market cap. Like I don't think we've ever seen a protocol with billions in TVL that has

a 10 million market cap. Uh so I think there is a bit of like a if the protocol is successful and worth attacking then it's going to be very expensive and the operators are probably not going to you know want to give their stake to some crony. If the protocol is cheap to attack it's probably useless anyway. >> Yeah. No. So kind of my maybe I'm misunderstanding here but kind of because the attack can also look backwards. So kind of the current TVL is not a good indicator of how much really is at stake right because I can also um I can also um kind of uh make an attack on value that's already been processed in the past that's no

longer kind of in your TVI measurements. Uh well the way that we measure TVL in the Z protocol is how many how much money is in confidential tokens right uh so that you know I mean it's it's not TVL in the sense of defi it's not like swapping or something like that uh it's TVL in the sense that you have let's say a stable coin and then you have a confidential stable coin how much is in confidential stable coins uh the second thing also to remember is operators have a lot of stake in the protocol Right? So their incentive is not to get kicked out. If operators are not making any money, they're not going to be

running the Zama protocol and the protocol is going to shut down. Like at some point, you know, the whole economic thing is such that either it's economically viable and the operators are going to basically prevent governance attacks just by virtue of having a lot of stake that it could use against it or the protocol is not worth anything and there's no operators who are going to be running it because the cost for an operator is pretty high. We're talking, you know, 50 to 100k a year for an NPC node minimum. Uh for an FHE node is more than that even like so you wouldn't really invest this much in infrastructure unless you know there was profitability in the protocol. Uh and even then you can only slash operators

uh in your governance proposals. It doesn't mean that you can replace them with whoever you want. >> Yeah. Um, okay. Maybe let's move on just a little bit. Um, so, um, you're currently live, um, on testn net, right? So, um, who's building on that public test net at at this point? >> Um, a bunch of people. Uh, Zama itself actually has multiple uh, I would say apps that we're building internally. Uh, kind of like you know when when you buy an iPhone, it comes with Apple apps, right? Apple has a calendar app. Apple has like a browser.

Uh and then you can replace and use other apps if you want to. But the iPhone doesn't come empty. Same thing here. When the Zama protocol goes to mainet, it's not going to come empty. It's going to come with a suite of Zama uh apps. Uh so for example, we have a an app uh that allows you to run token auctions on chain. Uh we have an app that we're working on uh that enables you to do confidential token distribution. Uh but if we look at external people building things, there is a company who's building a self-custodial bank on chain using confidential stable coins as the assets in your bank account. Uh there's another company who's currently uh building a confidential uh stable coin where the

onchain balances amounts but also the mint and burn so the on-ramp and off-ramp to the stable coin is confidential. So it allows you for example as a company to use the stable coin just like you would use like any kind of currency without disclosing anything to everyone. Um most of the applications are payments or finance related clearly. Uh because to be honest I think this is where we see most traction and most need for confidentiality right now. >> Yeah with um the current ecosystem. That's for sure. I know you've also talked about private v voting and things like sealed bid auctions before. Um when do you see these coming to fruition?

>> Whenever someone wants to build it and thinks that this is relevant. I guess >> I think seal bit seal bit auctions we're going to do for sure because I think this is a cool use case. Uh confidential governance voting. So we are not a governance like we don't build governance apps right like this is a whole company you know you need like you know there are literally companies doing just that. uh so the goal for us would be to convince them to integrate confidentiality into their governance systems. Uh it's going to happen like I think when people realize that the cost of doing things confidentially is not that much higher than non-confidentially and that performances is not a bottleneck. There's really no reason not to do things with confidentiality. Think of it think of

like how the internet evolved, right? Um, HTTPS in the beginning was expensive to do encryption. It was difficult to set up. So, nobody used it. You know, I think it was 13% or 14% of internet traffic was encrypted with HTPS when Snowden revealed, you know, the whole thing. Uh, today it's over 95%. Because it became so cheap and so easy to do that people just do it by default. I think the same thing is going to happen to blockchain. We're going to good we're going to get to a point where the vast vast majority of blockchain transactions are going to be encrypted because why not? Like you have to remember that the reason why data on chain is public is not a feature. It was needed for public

verifiability. But if you now have a way to compute unencrypted data in a publicly verifiable manner, that's what FHE does. then you could actually have public verifiability without having the data publicly disclosed to everyone either. And I think this is a very very important thing that just wasn't possible at the time when Ethereum launched. >> Yeah, I 100% agree that the the um transparency is uh not um not a feature for most um applications. you recently um closed a pretty big series B round.

So you raised um 57 millions. How does this change your trajectory or does it kind of make um a lot of the things that we already talked about um initially possible? So things like um doing uh multi-year research for um building an ASIC and so on. So where where do you plan to spend that money? >> Exactly what you said. multi-year research projects. Uh so so Zama has consistently been keeping a multi-year runway. Uh I'm very paranoid like you know I've been in crypto since 2013.

I know how quickly things can change and typically like a bare market will last two to three years, right? So I always want to make sure that my company has enough cash so that we don't have to worry about any kind of short or medium-term market conditions. Our goal is that in four years the majority of blockchain transactions are encrypted using Zamas technology through the Zama protocol. >> Sorry, how much percent? What percentage? >> The majority I would say. So >> even 10% I'd be happy as a starting point, but let's say you know the majority um whether it's through Zamas protocol or through one of our partners who are licensing our technology, I'm

happy in both cases obviously. Uh and so to do that, we need to be able to guarantee that we're going to continue pushing on research, on development, on performance improvements, on security, on all these things. Uh and so this funding really goes towards that. Uh so even if Zama makes no revenue, which is not the case, even if our token goes to zero and we make zero out of the token itself, right? So imagine like everything stops. There is a global war. Nobody cares about privacy and blockchain anymore. The whole world stops, right? We would still have enough cash to get to 2029 and above. So, so we don't have to worry about any kind of

world condition right now. And that's really, really important because if you're going to be betting the future of, you know, your application on some third party technology, you want to make sure they're going to stick around for a while. How worried are you about regulatory capture? So I mean I know kind of like in this space we're all for privacy. Um but kind of from the regulatory side kind of transparency um has been pushed more and more and kind of uh won't regulators kind of bark at financial apps that are inherently private and cannot cannot be

forced into disclosure. I think when you think about compliance, uh this is actually one thing I think the Zama protocol is very strong at is the Zama protocol doesn't force you to do anything specific, right? What it does is it gives you tools to build confidentiality into your application and define whatever rules you want for how you deal with this confidentiality. So for example, let's say you're a token issuer and you want to offer confidentiality for your users. You could, for example, give yourself as the issuer the ability to decrypt the balances of your users. So users would see their balances. The token issuer

would see all the balances, but nobody else on chain would see anything. So this would be exactly the same as like an existing traditional bank where the bank sees the bank accounts of all their users. You see your bank account, but you don't see other people's bank accounts. So you can recreate TRFI compliance models on chain using Zama because it gives you this expressivity in the access control logic of who can decrypt what. And this is a very important distinction because again if you look at ZK ZK imposes that uh uh confidentiality sorry the compliance is on the end user.

So every user has to basically provide their own proof that you know they're a legitimate user and so on so forth. Zama enables the application to deal with compliance on behalf of their users directly just like any application in finance does today. Uh and so we we as a company don't technically offer any privacy features like Zama itself doesn't offer privacy out of the box. It gives you a way to build confidentiality into your application. the way you want it to be.

>> Okay, that's a good um answer. So, kind of we've we've talked about kind of like the difficulties that kind of like doing this on blockchain um kind of uh introduces. Um you you said multiple times kind of Zama can do more transactions per second than than Ethereum currently can. Um, is is this just kind of the first com commercial commercialization step for you guys or kind of are you looking at FHE kind of like for broader internet use cases beyond blockchain?

We do uh I think you know the long-term vision for the company is that at some point you know the same way we went from encrypting nothing to encrypting data in transit with HTTPS we will have encryption of data during computation with FHE something we call HTTPZ right so like you'll have a a general protocol for any kind of online application cloud blockchain AI whatever that guarantees that the data is encrypted end to end uh but that's going to take a obviously to do, right? And so we think that blockchain is a great segue towards this long-term vision because blockchain needs confidentiality like most blockchain applications have not been built because of a lack of

confidentiality on chain. >> Yeah, 100%. Going from past experience, so we last talked two years ago, so we talk we talk again in 2027. Um what do you hope Zama will have achieved by then? >> In 2027 um so in 2027 our goal is to be running on multiple chains. Uh so to bring confidentiality to every major L1 and L2 so that users can start building things anywhere they want. Uh we want of course Zama to have reached multiple percentage points of uh blockchain transactions encrypted with Zama. I don't know 5% 10% you know some some step until we get to this 50% plus.

Uh but importantly I'm hoping that by 2027 people realize that FHE can do whatever blockchain can do and that there's no reason not to use it. I think the next couple of years for us is going to be mostly about proving that blockchain with FHE is much better than blockchain without. >> Cool. for people who are interested in following you guys or possibly building on the test net or soon the main net. Um where do we send them?

>> You can follow us on on Twitter x uh zama fh uh and then we have all the traditional social channels. You can also reach out to me directly randi r nd hindi. My DMs are open. Uh I really like talking to builders in particular. uh you know like I'm I'm a developer myself initially and one of my regrets is that when you become CEO you don't have much time for coding so I uh I I try to uh to keep my my nerdy hat on as much as possible by literally talking to people who are building so if you're building something and want to talk about it just reach out directly.

>> Cool. Thank you so much for coming on Rand. Thank you for having me again.