Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Guy Itzhaki & Guy Zyskind: Fhenix – FHE-powered End-to-End Encrypted Ethereum L2

Episode Date: January 12, 2024

Fully homomorphic encryption, also known as the Holy Grail of cryptography, allows for computation to be performed on encrypted data, without the need for prior decryption. Its blockchain applications would enable programmable, institutional-grade, compliant privacy. With the addition of fhEVM libraries, solidity developers don’t have to worry about the complex cryptography and only decide what layers of the UX should be private.We were joined by Guy Itzhaki & Guy Zyskind, to discuss fully homomorphic encryption and how Fhenix plans to leverage it to build an end-to-end encrypted Ethereum L2 with compliant privacy.Topics covered in this episode:Guy(s)’ backgrounds and why they chose FHEThe differences between TEE, MPC, ZK and FHEThreshold decryptionThe challenges with FHE. Hardware acceleration. Zama’s fhEVMFhenix architecturefhEVMUse cases for FHE & composabilityCompliant privacyFhenix roadmapEpisode links:Guy Zyskind on TwitterGuy Itzhaki on TwitterFhenix on TwitterEncryption Day @ ETH Denver (Feb. 28, 2024) registrationSponsors:Gnosis: Gnosis builds decentralized infrastructure for the Ethereum ecosystem, since 2015. This year marks the launch of Gnosis Pay— the world's first Decentralized Payment Network. Get started today at - gnosis.ioChorus One: Chorus One is one of the largest node operators worldwide, supporting more than 100,000 delegators, across 45 networks. The recently launched OPUS allows staking up to 8,000 ETH in a single transaction. Enjoy the highest yields and institutional grade security at - chorus.oneThis episode is hosted by Felix Lutsch. Show notes and listening options: epicenter.tv/530

This episode is brought to you by Gnosis. NOSIS builds decentralized infrastructure for the Ethereum ecosystem. With a rich history dating back to 2015 and products like Safe, CowSwap, or Nosis chain, NOSIS combines needs-driven development with deep technical expertise. This year marks the launch of NOSIS pay, the world's first decentralized payment network. With a Gnosis card, you can spend self-concernel. at any visa-accepting merchant around the world. If you're an individual looking to live more on-chain or a business looking to white-label the stack, visit nosispay.com. There are lots of

ways you can join the NOSIS journey. Drop in the NOSIS Dow governance form, become a NOSIS validator with a single GNO token and low-cost hardware, or deploy your product on the EVM-compatible and highly decentralized nosis chain. Get started today at nosus.io. Corse 1 is one of the biggest node operators globally and help you stake your tokens on 45 plus networks like Ethereum, Cosmos, Celestia, and DYDX. More than 100,000 delegates

stake with CoreS1, including institutions like BitGo and Ledger. Staking with Chorus 1 not only gets you the highest years, but also the most robust security practices and infrastructure that are usually exclusive for institutions. You can stake directly to Quarice 1 public note from your wallet, set up a white table note or use the recently launched product, Opus, to stake up to 8,000 eth in a single transaction. You can even offer high-year staking to your own customers using their API.

Your assets always remain in your custody, so you can have complete peace of mind. taking today at chorus.1. Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Felix, and today I'm speaking with Guy Yitzaki and Guy Ziskind, we're respectively the CEO and founder of Phoenix. Phoenix is in the theater focusing on enabling computation over encrypted data via fully homomorphic encryption.

We're going to get into what all this means in a second. but first of all let me welcome my guest today so welcome guy and guy thanks keelix thanks very inviting good good to be back awesome yeah exactly yeah um guy z you've been on here already you have a big background in crypto uh building like multiple of the like cutting edge projects in in sort of the privacy space at least from my perspective um so maybe we can start there and and kind of start with the usual epicenter question of how did you get into crypto and how did you end up at Phoenix now in the end?

Oh, so good to be again. I think we've had that conversation or at least I've said that I've told that story a few times before. I'm celebrating a decade in crypto which is either an achievement or something to be ashamed of.

I'm still not sure and I'm still decided. but it's been a decade. I got into crypto in around 2014, actually even 2013, really got caught up with the technology. I was starting my master's at the same time

and decided that I really wanted to focus on research and more deep diving into what we can do with blockchains. Beyond just Bitcoin, Ethereum was in like alpha stages back then. It was just starting out, and that was very inspiring

for me, and then I landed into the problem of privacy, and specifically came out with this problem, which is today it's already a well-established problem, but then it was really novel. How do you do private computation on the blockchain? How do you basically do confidential smart contracts? And that was what I focused on on my thesis using security multi-party computation technology. time. And that led to a project called Enigma, which eventually turned into a secret network. It had a few iterations. And secret network is today, like one of the largest cosmos chains that specifically focuses on private compute, but it uses, for the most part, trusted execution

environment, which is another technology, and a few others. But then in the last couple of years, as I was going back into research mode, I kind of became convinced that FHE of the future and basically decided to focus most of my time on that. And that kind of turned into Phoenix in the last like six months or so. Right. Yeah, awesome. We're going to get a lot into the different like sort of technologies that are out there and how FHE compares to them.

I think that's like kind of key to understanding, you know, what what Phoenix actually is. And maybe also like clearing up some confusion for our listeners. But yeah, first guy, Itsaki, maybe you can give us a little bit of background how you met your name, cousin and started in crypto. Yeah, for sure. So my background is a little bit different than the typical crypto native folks. I've been at Intel for many years. I think somewhere around 2017 is where I started actually working on blockchain. I was leading Intel's trusted execution environment ecosystem development and did several projects with Intel SGX.

One of them was actually to build a private blockchain network for a financial institute, a stock exchange. It was a permission network for lending securities. and it got me quite excited about the technology. And actually, I was, you know, 2017, it was a very fun year to be involved in, and I got invited to tons of conferences to represent the enterprise point of view of blockchain. And in one of the panels, I met Gyskyn. We started chatting. And I think it was very clear after a few minutes that, you know, we have a lot in common,

specifically about the desire and the need to introduce privacy into that space. In 2017, in 2018, morphic encryption was just an idea, wasn't really immature, but SGX was, was, and I worked with Guy back then about the usage of TEEs within his project, but I kept on monitoring the progress around FHE and was quite excited about that. In 2020, I decided to take a limo to that space and did a gig working on the Olympic Games. I'm a fan of sports, and when the Olympic calls, you cannot say no. Intel was the sponsor of the Olympic Games, the opportunity to work on the Tokyo Games and the Beijing games. Non-blockchain-related, but just very cool technological innovation in that space.

We can do a podcast about that for like a couple of hours as well at some point. And then, you know, 22, the itch came back and I transitioned to lead the FHE business activities at Intel. Intel is building a hardware accelerator for homomorphic encryption. It's public. It's part of a DARPA initiative. And throughout that, I basically scanned the entire market. So figure out the usage within cloud service providers, federal entities, financial institutes. And I have to say that the progress around FHE has been quite impressive.

We'll get into that later on about some of the key challenges, including performance and complexity and how they're being sold. And I also met Zama, which we'll chat about them as well. And in earlier this year, I was in Israel visiting at Gaiskyn, and he told me that he's noticing the same progression with FHE. and that was really the sign for me to leave Intel and join Phoenix. Right, awesome. That's amazing that we have both of you here, like the experts on this topic. I think, yeah, we saw a lot, probably most people are very familiar with ZK and like sort of the progress in the ZK space and in its connection to crypto and sort of the Cambrian explosion or like research in that area. But I guess FHE is sort of themes more undercover still.

and maybe you'll be able to shed some light into how it can be applied to crypto or why it is maybe a game changer. But yeah, maybe first of all, we can start off with, I guess, like, just the concepts of like mental model of these different technologies. How do they compare and how, yeah, do they work? And how is FHE, like sort of the, like, maybe end state of it? If that is even, like, correct to say, that's sort of like how, I guess, I look at it. Could you like, yeah, kind of compare maybe for me, like one of you guys, you know, what secure multi-party computation tries to achieve and maybe how, yeah, maybe let's start there.

And then we can get into like how he is to achieve it and how FHA does it. First of all, I mean, I think at some point people in crypto will have to kind of get used to the idea that it's not either all. all of these technologies will play a part in like DMB. I do agree with the assessment that FH is probably like the end game solution in the sense that it will do like most of the heavy lifting and most of the important work when it comes to like encryption and private computers or secure computation,

whatever way we decide to define it, but you will still need ZK regardless, even not just for scaling, but for some other things, you would still actually probably want like T's or some form of like hardware. If you would be mothers which are like a lightweight version of T's closer to how the Warnets are in how they work. So all of these technologies will have a part to play,

NPCs as well. But just to give like a very, very quick overview, let's start with the problem, not with the solution. So the problem that we're actually trying to solve in blockchain is essentially what's known as secure computation. And secure computation has two branches. One of them is you want the computations to be correct and trusted. That is something that blockchain already do, right?

Like you write a smart contract on Ethereum, by definition, the reason you use Ethereum is because it's a trusted platform. You know that code is law and you're going to get a correct result. So that branch is solved and has been sold for about a decade. Then there is the other branch when it defines secure computation, and that is confidentiality or privacy. Again, different people use different terms. And that is the idea that, like, you have a multi-user system, right? Like, maybe I have my data, you have your data, guides like he has his data.

We want to run some programs, some logic on top of all of our data. But for that logic, either to be, to have, even we just don't want to share. like our private data with each other, for privacy using, or for the logic to actually make sense, we aren't able to share it. Like, think about a game of poker, for example. In a game of poker, each one of us has our own deck of cards. If everyone sees each other at this deck of cards,

and it's not about carrying about your privacy, does just a poker game, right? Like, you can't actually do that functionality without privacy baking. So that is really the idea of secure computation. You have multiple users sharing data. They want to be able to share their data privately, such as other participants, and even the computers running the program itself can see the data, and also they want to know that the results are correct. That is the problem, right? Like the problem is how they get both correctness, which blockchain solves, and how they get privacy. And for privacy, then you have those different technologies, right, that people are getting used to at this point.

So I'm actually going to leave ZK and FHE to the end. So I'm going to talk about two techniques that are maybe easier to grasp. One of them is trust of the execution environments. T's are fairly easy to understand, right? There's like a magic black box inside of your processor, inside a computer, and basically the assumption is that no one can break it and that no one can probe into what's going on to. So basically,

if you want to do a computation privately, then all you have to do is you have to encrypt your data from the outside with some key that exists only in the black box, and then you send your code and encrypted data to the black box

that T, the data is actually being decrypted inside. The computation is done inside, and only the output maybe gets revealed to you or to someone. So that's kind of like, you know, using hardware, use hardware to simulate the effect of computing over private data, but there's obviously a big assumption here that no one can break that black box.

I have two things to say about that. I guess people have seen that black box has been broken before, and even with secret that has been an issue and even with other systems. On the other hand, I do think people overestimate the problem with this, like peas are and evolve with technology and many. of those actual problems are going to be solved over time. But it's, you know, it's always going to be a simulated solution. It's not a purely cryptographic solution, and it's always going to have its problems. The upside is that it's very fast and very, and very cheap in comparison, compared to, like, deep cryptographic solutions.

The other solution is to use something called NPC. MPC, I'm not going to get, that's actually probably the hardest one to explain in a way. because what happens with MPC is that the data is being split. It's kind of like a blockchain. The data is being split across like several validators or nodes in the system. And then they run, they take like a program, an regular program, and they basically transform it into this multi-party computation. This equivalent secure program that they can run together,

as an interactive protocol where they make sure that they never reveal data to each other every one of them always have like an encrypted piece of the data it's called a share of the data but they can somehow together magically compute any program and any smart contract and obtain the output without actually bringing the data together with each other

and decrypting it so that's kind of like how NPC works and then FHE is probably the most sophisticated technique but it's actually easier to understand it actually is most similar to T's really all that happens with FHC is that everyone encrypts their data they send it to a server or to a you know

or to a network or server but let's just say it's a single server for now and that server just computes over that encrypted data without actually knowing what the data it computes over and then it gets an encrypted output and maybe that output gets decrypted or maybe it sends to some user but the whole computation happens directly over encrypted data and that's really the magic.

Now all of those technologies they very, very directly solve the problem of secure computation. They allow multiple users to somehow encrypt their data and then they allow one or multiple servers to compute the functionality or the smart contract or whatever over the data.

And now we get to ZK. ZK actually works very differently. In ZK, you can't actually do secure computation. You can't actually combine data from multiple users and then compute over the data privately and then produce a result. you can do single user private computation. So if I have data, if I have private data,

maybe it's like my age or my date of birth, and I want to prove to you that I'm over 21. So I can compute, you know, just like a comparison comparing my date of birth with age 21 and then produce to you an output that says, look, I'm over 21 and also here's a proof that I didn't cheat on that computation. But if you think about the poker example, again, there's no way to do that with ZK alone.

It's actually not something you can do. The closest you can do with ZK, if you want to go back to that same multi-user model, is you need to have a profit party. You need to have someone that everyone trusts, right? Like maybe it's you, Felix, right? well, like maybe all of us trust you more than you trust us or that we trust each other. And so we send you our data. You run the competition in the clinic. See everyone's data.

And then you can send a proof to everyone that, you know, you ran whatever complication correctly. But at the end of the day, someone I had seen data in that case, that's you. So I think the best you can do with ZKLO. Okay. Yeah, I think that's been a lot to unpack there. I think I guess you also mentioned. that these technologies can partially work together,

will work together in a sense, is that also, like, could you, the computation from FHE, somehow create a proof? And, like, because I guess from what I understand in FHE, you still need to, like, reproduce the computation to prove its correctness, I guess. Is that, could you combine, like, FHE and ZK somehow to kind of prove and make it multi-user like that?

Or is that another thing? So, okay, so actually, current FHE, so FHE, you know, there's one thing I gloss over. FHC, there's an encryption key. But who always is the encryption key? That is like the big question. You can't, I mean, there's a technique called

multi-key FHC where you can theoretically combine multiple keys, but it's like not practical and it has other problems. So really, you need to have like one key or multiple keys, but like all the users need to, for example, encrypted their deck of cards with the same key. So again, who has the decryption key? And if someone has a decryption key, then that's like a, that's like a, you know,

like a trusted point. So what you do is you use NPC. So remember with NPC, you can split the data. So you take the decryption key and you split that across the network, the entire network. And then that network does something called the threshold decryption. Whenever you need to decryp the data, the network can come together without actually recombining the key. Like the key never lives in one place, but together they can decry an output for a result. So you actually need MPC to turn FHC motor user.

And then for what you described, yes, you also, I mean, if you want to do veryifiable as in G. If you want to do like a ZK FHE wallup, right, so which works just like a regular ZK roll-up, but everything is encrypted, then you would have to go over the FHC computations and produces ZK proof on top of that saying, hey, I ran the FHC computation correctly. That is a very active research area, but it's nowhere and impractical. This pharaoh is out there. I think we're like, you know, maybe five years plus away from that. But that's going to be the end game.

Right, right, yeah. Yeah, I think that's like the recurring theme. It seems a little bit that like a lot of these technologies are sort of developing like you also said for TEEs, right? Like currently like there's still some problems. But as there's more research going in and as they're being used more in practice, they are developing. And I think a lot of that was like when I initially read about FHG, I think for example, New Seifer I think was pretty early like looking at this in 2018, 19, 19. but then it seemed like very impractical or there wasn't like anything there so maybe can you or maybe yeah one of you go into how FAAG actually evolved

and how it now became practical to do this or yeah or is there even like still more improvements to be made more optimization so that it's even getting even better like can you maybe like kind of walk us through the history of FHG in that sense

yeah for sure So I think when I mentioned, you know, 2017, 2018, FHE, you've started to hear about it, but when we say that it wasn't mature then, I think the challenge that you typically have with FHE is twofold. One, it's considered as very complex for developers to build on top of that. And the second one is performance. And I think even today when we talk about FHE, there is this notion of FHE is still. very, very complex and very, very slow. But like everything in life, there has been progression, and this has been constant progression throughout the years. And what we see today is actually that these problems are starting to be resolved. So let's maybe start with the developer's complexity. Because the data is encrypted, you can't really operate the way you operate on a regular

program, right? There is no if and else because you don't actually see. the data itself. So you need to have the application being built in a specific way. For having developers do that, there is a very limited set of people with that skill set. So what's been built in the last couple of years is actually a set of compilers that abstracts a lot of the complication from the developers. That's where I think Zama really shines, and Zama is a partner that we're working with. And with the introduction of the FHEVM, And in that case, basically, developers can just write smart contracts without any need to understand FHE whatsoever.

They basically define or solidity base, so developers don't actually even need to understand any different new language. And they just decide which asset they want to encrypt on the blockchain and they encrypt that part. So I think in terms of complexity, that problem specifically for the blockchain is, I can say, probably kind of resolved. The second part is computation. Now here we talk about FHE as if it's one monolithic entity, but actually within the FHE world itself, there are different schemes. Some schemes, or you can look at them as like variant, are better for some applications and others are better for others.

So you have schemes like CKKKS and BGV, which are probably better when you're doing machine learning and artificial intelligence type of computation. In our case, the scheme that we are using is TFEG. And this one has something called programmable bootstrapping, which means that the noise is being cleared every operation that's being done. Not so much important for that case. But I think that the improvement that's been happening is also on the scheme level.

So the schemes are becoming more efficient, thus making the computation better. That's part A of the solution. and the second part is clearly hardware. And as we get better hardware, better CPUs, better GPUs, and the next couple of years also A6 coming into play, we definitely see the path for resolution towards that. FHE, unlike MPC, is computation bound. MPC is more of a communication bound.

But with FHE, it's more computation bound. So the more hardware you throw on FHE, the better performance you get. And we're actually seeing significant progress that's happened in the last couple of years. And I came from Intel, so I know the hardware space pretty well. And we can definitely see that in the next 12 to 18 months, there are, I say, over a dozen companies that are building dedicated hardware accelerator for FHE, which really gives us the signal that performance. performance is going to be resolved in the next couple of years.

Awesome, yeah. Maybe I guess I'll take that to the Phoenix, like sort of blockchain level in a sense. Like you already mentioned, you need this MPC to have the decryption key for FHE. So I assume there are some roles in the network of Phoenix, like I guess validators or maybe like different roles are. Yeah, maybe you can explain. Is this going to be like one role that people have to run these hardware accelerated FHE hardware and also do this MTC? Or are you splitting these things up? Like how is sort of the network architecture of Phoenix going to look like, if that's already clear? Or like, I guess how are you thinking about it?

I'd say it's pretty clear at this point. We put like the main building blocks that we've been building in, in, you know, L2 white paper, if people want to read and go into a bit more detail. But generally speaking, like, we kind of landed that the right architecture is an L2, a wallop architecture, for the same obvious reason that wallops make sense in GMVL. Like, there is no reason to replicate the computation across, like, all validators in the network. It is enough to have, like, one node or small number of nodes, like, do that. the actual computation and sequencing and all that and then let others just validate.

And with FHE, that makes even more sense, right? Because FHE kind of like ZK requires like very heavy to the cryptography. That's very, very expensive. Those are, you know, those are all how it's always if you need to lay the consent with on top of that and start to sync validators that's going to take to wrong. So anything that relates to execution is bad and done in the vision. or in small groups. Anything done with the value with validating,

you know, anyone can do it with a longer time window. We're taking the optimistic wall up by a pouch because like I said, ZK, ZK FHU valves are not, are not going to be practical for quite a while. So you have the same world that you have in a wallet, but then you have another additional role, which is the threshold network. The threshold network will have the shared encryption key.

It's going to be run by a wallet, validate those and whenever users request like a decryption or re-incryption operation, then that network which is going to start small, but ideally eventually it's going to become like very then your RG, like that's like our long-term goal. That level is going to actually end of those. And actually we're coming up and thinking of other like stuff that accelerates like FHing that that network can actually do like it I think

at the end of the day like most of the computations would be done via FHE but you would be able to maybe speed up some specific bottom XHC like with MPC on that network that actually goes beyond just like binary decryption

but that's like farther down the road okay cool thanks and I guess yeah maybe also getting back on the first point, like sort of the developer experience point, is it fair to say like, you know, FHEVM and sort of ZK EVM has been sort of like, is that a similar like framing, like, that like these providers do a similar job there? Or like how do you think about it?

Is it only, I guess you guys are focused on EVM with FHVM, but is there also other like VMs that could be supported with FAG or is, are you also working? on that or, you know, how do we have to think about that? Yeah, I think both of us came from a very practical standpoint here. And, you know, when we started thinking about Phoenix, it was clear to us that we want to make FHE as simple as possible to onboard developers. So we had a couple of decisions. The first one was that we want to target the Ethereum community and solidity-based.

we don't want developers to actually need to learn a new cryptographic. They don't have to be cryptographic at all to use it, and we don't want them to learn a new programming language. So the decision to go with an EVM-like FH-EVM-like solution was the first one that was made. I want to emphasize that FHE enables you to do computation on data while it's encrypted. Guy Z talked about that earlier, while ZK enables you to verify data. So I don't think there are, I mean, there are not so much similarities in what we're offering

in comparison to the ZK EVM. I think that the usage of the FHE EVM is quite simple. There is an additional library that developers can utilize when they want to encrypt data on the blockchain. And once they encrypt this data using a function for encryption, that data is encrypted on chain. And it enables to do computation on this data while it is encrypted on the blockchain. And that is, I would say, quite easy from a developer standpoint, whether it is to write a new contract or potentially to import existing smart contracts into Phoenix. The transition itself is not very complex.

I think where the complexity starts to come is actually it's a mindset that needs to happen because now you need to actually think about designing your solution with confidentiality in mind. So it's not about, okay, let's just encrypt this data and leave it there. How do I prevent others from figuring out this data through other means? So if you extract some assets from a pool, it's not enough that this asset is encrypted. You actually need to make sure that the pool itself is encrypted, because otherwise people can subtract and figure out how much you've pulled. So I think there are more of a design-related questions, but in terms of the actual building blocks, it's fairly easy.

And that's really where things become interesting. So my thinking about this as a world in the last. two months. In the beginning, I said that I view FHEVM and ZKVM is very similar, but I think the more, the more we dig into it, the more I'm nearly like they're basically incompatible. So ZKVM is really about writing the EVM interpreter in a way that's amenable to prove in that, you know, some EVM execution ran correctly. If you're a developer, if you're a developer that's running on a ZK EVM,

you just write a plain regular solidity contract. You don't actually use a ZK. But whoever needs to design the ZK EVM circuit, that is a very, very, very, very hard task to be. Whereas with, as a guy and guys is saying, like with FHE, like we are trying to externalize essentially library or a tool for like solidity developers. And to a question, there's no reason it needs just be for solidity. Like you can support everything.

But like we focus on Ethereum because that's the biggest ecosystem and we're the biggest thing. So it's in some ways it's closer to like, you know, libraries like SafeMath from like Open Zeppelin and like those like initial libraries. where you could actually just write like faster, more secure code for your smart contracts. To think about it, you use those libraries and solidities to write private computation code, but in a very, very simple way. Like, it's as easy as using something like SafeMath. So it's really not compatible. It's more comparable to maybe, like, you know, I think Aztecs,

like noir language or other DSL domain-specific languages that other companies, that other companies that are building ZK trying to build ZK private smart contracts solutions are doing but here is actually where FHC really shines I mean first of all FHC can do stuff that ZK private compute can because ZK

as we said is meant for private compute but more importantly because ZK is not meant for private compute then now you have to learn a new language you have to start thinking what computations need to happen with the client side, what computation need to happen on the smart contract, basically the backend side. Whereas with FHVN,

with Phoenix, it's just right your smart contract in serenity. Here's a liability to do like FHC computations and bam, that's all you need. You don't need to know or understand anything else. With the exception of what Guy said,

which is not a technical component, it's a philosophical component. Like, you need to think about you have encrypted data if at some point you want to decrypt information or reveal information, well, maybe that needs more than the new entity. So you need to think about that. So yeah, it's very, very different in my opinion. Okay, okay. So maybe to summarize how I understood this now, I guess, ZKVM, you're essentially as a developer just building like a normal application still, right? You're not doing any private computation with DKVM essentially, right? So Right. That's one. Then domain specific language, right? You can do like a ZK and write in another language, which obviously has the downsides of that. And then sort of Phoenix or FH, EVM allows you to write the same language plus like these new use cases. So I guess, is that correct? Like on the high level like as a summary sort of? Yes. Yes. 100%. Cool. Awesome. And so then, yeah, I guess what becomes interesting, you already mentioned like sort of the poker example.

you know, what sort of like other use cases are you interested in? Or like what should people get inspiration from for this? Or what has already been built like anything really? I'm curious to hear what you're, what's happening on Phoenix already or what you want to see actually. Yeah, I'll just start by saying that before we talk about the specific case, you know, I'm more of an outsider in this space, coming from the corporate world. And I have to say that when I look at the blockchain

from the outside, it seems to me that the fact that there is basically zero confidentiality, I know some people see it as a feature, but for me it's a significant limitation. I just feel that we're all here because we believe in blockchain and we want to see it being massively, adopted, but I feel like we're in this 10 or 20%, and we have this 70% of a gap that still needs to be resolved. And a key component of it is data confidentiality. I just don't see how

blockchain can ever become mainstream and very, very successful without any data confidentiality. For sure, there is no chance that any corporates or financial institutes or government entities will use public blockchain without data confidentiality. And that is a actually why we believe that this is not FHE versus ZK versus TE, but rather, you know, we're all here for the same goal of introducing and making the blockchain better. We have a couple of use cases that we typically talk about, but I think the belief is that data confidentiality needs to be an underlying capability. And once you make it easy to use, it will become very, very common, similarly to the way that you operate today in the traditional world where, you know,

everything out there is assumed to be protected. It may not be, but you know, it's assumed to be protected. So just putting it out there, the goal here is not so much to introduce confidentiality for the, you know, it's important to protect users' confidentiality, but what we actually believe is that by enabling this new capability, it understands. locks new applications that you couldn't do before. And the game of on-chain poker is a good one because, yeah, people are figuring out some kind of solutions for on-chain gaming, but they're not really ideal.

And once we introduce FHG or whatever type of solutions that are out there, you can start using it the right way. So on-chain gaming is one, I would say voting is another really kind of. clear example of how do you do voting or Dow voting without encryption. It's quite complex. Now we can actually do that with FHAG. Sealbit options. Guy, I let you talk about a few of the use cases as well. Yes, I mean, but just to drive your first point home, like, look, I mean, we're not there yet and we're quite fallout. But at the end of the day, if people are dreaming about the convergence of like AI and, like, yeah.

crypto? Well, how are you going to have like something like a distributed and chat GPT if everyone can see like if I can see your prompts and you can see my prompts and we can actually have like models with like private data like like that's not going to happen. So like we have to solve that core problem and then we can start thinking about like these really, really cool like AI slash crypto revolution and many things like that. But you know, if we want to be more grounded to what the technology can be today and what people are looking for today. Then, yes, on-chain gaming voting are a couple, but I think, you know, we can't ignore the fact that there's still a lot of interest

and not around defile and those ecosystems. Most like infrastructure and protocols ecosystem have started by bringing a large inflow of users that come for the initial defense. application. And so the question is, what are the interesting DFI-related applications that can be done or feelings that cannot be done any within, at least not as efficiency? So, one of them relates to obviously NUV, so, you know, you mentioned that.

It would have been like behind the scene tons and obviously the talk of the day and Justin Drake talks a lot about it. Like FHG has really a lot of potential to like introduce solutions and the proposal, builder separation and block building like a flow in different places of the pipeline. Probably the lowest sending fruit is around the Silbid auction. So auctions don't have to be done like on every block. So then like you know, FHE is efficiency, the rest of an issue.

Like you can you can run an auction and choose like a sequence sale for an epoch for like you know a specified number of blocks and that can run efficiently enough and you can do that much more efficiently with FHE than with the other technology and without FHE then obviously you don't you don't get sealed reductions which will far far superior than public auctions like that is a way and on game theory fact so that is like real money on the table like very plainly right that is a use case that uh shared sequences the central our sequences and pretty much all of the ecosystems are looking into right now. And that is something that's really complete as Phoenix can solve pretty much out of the box

immediately. So that's something I'm looking into. And there's a lot of variations about that. Another use case that I'm actually very, really interested in, it's a two building blocks use case. But the underlying use case is actually doing something like Thorchain, like Thorchain, like Thorpe, and their lending. there's a lot of demand for doing

cross-chain, defy in a decentralized manner like we've seen that with Torchane but imagine that you can do it with solidity and then have all of the building blocks that people have done today like all of the defy applications that people have built on the Ethereum ecosystem

imagine you can take them, copy, paste them and use them on an ecosystem like Phoenix but the underlying assets are not just ERC20s and they're not just robbed Bitcoin and they're actually native Bitcoin and native Solama

and all that completely cross-chain more like how Thor chain does that and the way you can do that is because with Phoenix like a very simple use case is you can create these micro bridges we call the micro bridges because you can actually have a vault inside of a contract

We can have like a private key of a Bitcoin vault encrypted inside of a smart contract and then people can deposit and withdraw like native Bitcoin and use that in a decentralized fashion inside of like Uniswap and another DIPI application. So that is something that we really, really want to focus on because or hopefully encourage each other

and we develop a focus on because we think there's a huge market there. Right. Yeah, that seems super interesting. I guess it's like Torchane is using some like threshold signature scheme where the validators share this key.

Can you explain how this is different again maybe? Yes. So in Phoenix, like instead of having like a threshold key, what you will do, you will take like just a key or generate it a key, but it's in, you generate it with in FHU, so then the key is always encrypted. And you just store it. in a contract state. Like you have a Bitcoin private key, you don't have to split it. You just take it as he is encrypted.

You put it on a solidity smart contract in the state. And you literally have an operation say, like sign. And in the contract, you do an encrypted sign. And then you only decrypt the signature. You never decrypt the key. So the key is always encrypted. And now you have a smart contract that is actually can act as a wallet. The reason NFC assumption, again as well, in the sense that the ultimate FHE decryption key is split across the network. And so if you ever are able to reconstruct that key, then you can decry the pilot key in the contract. So it's not as much as it is about the better security model, although we can argue

specific it is more secure, but that's too many details. I think the point in programmability. Like, in Toche, like, the teammate to spend a lot of time that built an NPC protocol to split the key, and then build, you know, a uniswap kind of like a variant on top of it that uses it, and then, like, build a landing protocol, and each one of those takes to kill. But with Felix, one serve that building block, where you can keep an encrypted key inside of a contract, like a Bitcoin encrypted P, and people can send to that

address the money deposit, and then that contract can sign transactions, can basically sign Bitcoin transactions. Then that's all you need for me, like that's all the different logic that you really need. Then someone else can come in and just take like, Uniswap, Falkit, maybe TullySwap themselves, full kick and then combine, like, take those, like, like those contracts that I told you, though, like microbegidious contracts and put them as assets into their uniswap clone, into their later, other clone into whatever. So the programmability of using our cross-chain assets becomes, like, completely easy and solved, and all the DFI developers don't actually have to deal with it once that building block is still. as opposed to something like that would change. Right, right, right. Yeah, super interesting.

And these, so these micro bridges, someone would have to build like some, something there, like some sort of, how do I have to imagine it? I guess because in this MPC world, you have to build like some sort of light, have to have the light client and the nodes, the MPC nodes have to run it.

Is this similar here? Or you just need like some sort of codes, more or less? So we could take care of the threshold network, that's like a big piece of the thing's protocol, that's always going to be there. But beyond that, FHC is much simpler. It's not simple, like, the math is harder, actually, than MPC, but running it. And by the way, that's one of the reasons I became bullish. I'm an MPC person.

Like, most of my research is an MPC, but, like, I'm more bullish about FHC because FHC simplifies from an engineering perspective and a developer perspective, a lot of the stuff that MPC doesn't. So from a developer perspective, like, once we have FHVM, like the library and you have a traditional network, and we're building those, right? It's like some of it uses like Zama's underlying libraries, but like we're building like everything on the sides and on top and improving data and all that. And once you add those, then all the developer has to do is literally take a solidity contract that will have an API to generate a key and encrypted key in the contract, right? like through the liability, they would be able to sign transactions

within the contract, within the solidity contract, from the library, without ever, ever decrypting the underlined private key, and they won't have to worry about pretty much anything else. So I'm not sure if that answers the question,

but it's like really, once you have the building blocks, it's all then simplified. Yeah, and I would say this is really the goal, which is stability, a very strong set of capabilities that then enables

developers to take and build the likes of Torchain and other solutions without having the need to spend a year or a year and a half to build your own protocol with a lot of cryptographic complexities because it's all pretty much big in the

underlying Phoenix infrastructure. Mishad, thanks so much for expanding there. I think we talked a lot about I think one question that I wanted to address, and we also talked behind the scenes already before, a little bit about it, but I guess, you know, privacy and blockchain,

we have like this sort of relationship where on one hand, you want it, obviously, like, so institutions can use it. But then you have this other side, essentially where, like having private transactions and private things can also mean that, you know, not even the government or someone can, look into it and maybe you have like compliance issues right so like one big example there was like tornado cash and sort of how how that impacted the Ethereum like landscape through for example also flashbots but but in many in many ways um yeah I guess the way I understand it you can

build like these applications on on FHG so I was wondering you know how what's your approach like sort of compliance and confidentiality is there any any thoughts you guys have or how are you building towards, I guess, making it possible for also governments to be involved in this sort of technology. Yeah, that question came a lot, you know, in our early days. And, you know, people, you know, they heard about tornado cache. And in tornado cache, what happened was that the identity of the users was actually masked, which is different than what we are offering with Phoenix.

At Phoenix, it is the content of the transaction that is encrypted, but actually we're not masking the identity of the users who are doing the transaction. And this is a significant difference. So if the government has an issue, they would be able to identify who the person is, similar to other blockchains. That's no different. But the content of the transaction itself is encrypted. Now, there is definitely interest.

We've heard it from multiple entities about applications such as dark pools, et cetera. And we believe that they can be resolved in a compliant matter. So have identity, which is decentralized identity encrypted on chain, that goes through a compliance process and then being used in a comparison with a pool. So that's really, it's a significant difference. There is no plan here to offer capabilities similar to tornado cache on top of Phoenix. I'm going to give a slightly different version if I made. This is not the use case I were focused on. And this is not something that we're focused on out of the box.

But like you can, even as it currently sends, you can use FHA to build anonymity as well. like they're the ways to do it and if PayPal and developers want to do it they can do it even if we're not going to be the one who's focusing on but it is possible to build it on top of Phoenix if people choose and the other angle is

that I do think that like even if people choose to build an anonymity using FHI which is more like keen to tornado cache but it works differently Rensel gives similar results the benefit compared to tornado cache is that

FHE, like MPC, like trusted execution environments, they are completely programmable. So if we go back to this idea that ZK has a lot of limitations at the end of the day when trying to do like private computations, especially in a multi-user environment, FHC doesn't suffer from that robot. So you could detect it when developers can come in and programming like a completely privacy preserving, USDC variant that also has like selected disclosures like on an unbringate level like maybe like there's like a fraud and encrypted fault detection algorithm running inside a smart contract that only if there's like a really really suspicious alert with a more than 90% probability then it sends that to some authorized third party so like you can actually do all of those things with phoenix. I

I don't know that we will be focusing around it. And definitely I think, but I am kind of curious what's going to happen when developers come in and actually try to do the defense because I think then the crypto ecosystem will have to face a very difficult question. Like, are we willing as an ecosystem to have a system like that or does that completely go against the crypto ephas? I don't think I want to be the one to answer to that. I hope other people will put themselves in the position to answer that.

But it's absolutely technically possible to do with FHE. Right. I think, yeah, that makes perfect sense. I do think that question is being like sort of shifted around because I guess in the end no one really wants to deal with that or can even maybe because it's like pretty hard to be in touch with all governments and like sort of focus on that because at the end you're trying to build technology. So I think that makes a lot of sense. Yeah, I think we covered a lot of ground running close, close an hour.

I wanted to kind of end it by talking a bit about the sort of roadmap of Phoenix and, you know, where you guys are at in terms of the launch of the L2 or, you know, test that. Yeah, please let me know. Like we're recording this year in January 8. So, yeah, what's the plan for the next few months? Yeah, so we have our DevNet already up and running the last, it's a limited access DevNet, it's been up and running in the last couple of months. TestNet is coming in Q1, and then goal for Mainet is early 2025. I will say that, you know, people are definitely encouraged to come and sign for the TestNet

once it's available. We're going to be in East Denver looking forward to seeing everybody. We're doing an encryption date during that period. So it's going to be a very interesting event. We have a great light of speakers all over. And it's going to focus not just about FHE. So MPC, ZK, trusted execution environment. So again, encouraging people to join to that.

But test net Q1 and then goal for Mainet is early 2025. Awesome. Sounds like a realistic timeline maybe for two. change. It's not like super close. So so I wish you the best to to like be able to hit those milestones. And yeah, yeah, definitely if you guys go into Denver that are listening, try to check out the encryption day. I think yeah, that's it from mine. Thanks so much, Guy and Guy for coming on. The really insightful episode. I hope people picked up something on Fag and we'll link to the yeah, website and then some other material in the show notes.

Thank you very much. Thanks a lot, Felix. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast.

Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter. so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show,

and we're always happy to read them. So thanks so much, and we look forward to being back next week.