Trustless Gaming: Not All Is Fair Play

Date: 21-12-23


Trustless Gaming: Not All Is Fair Play

Introduction

Blockchain’s transparency, while promoting trust, presents challenges for data that require privacy. This is especially crucial in trustless gaming, where multiplayer games risk exposing sensitive data, leading to issues like cheating and system manipulation. While zero-knowledge proofs (ZKPs) games such as Snarky Monsters are currently being explored, they only generate proofs for each completed game, with all else remaining off-chain. 

Fhenix introduces Fully Homomorphic Encryption (FHE) to address this, whereby proofs are produced for individual game moves. FHE as a whole allows developers to integrate confidential computing into workflows using familiar EVM languages like Solidity. With FHE, data can be encrypted for privacy while still updating the network’s shared state transaction-by-transaction, enhancing data security and trust in trustless gaming.

 

This article explores FHE’s implementation in the trustless gaming sector, specifically for PVP games:

 

  1. An overview of trustless gaming.

  2. ZKP limitations.

  3. FHE’s ability to incorporate privacy and security.

  4. Utilizing FHE Rollups as low-level gaming infrastructure.

 

Worth noting is that our confidential computing technology is not a replacement to games, but rather infrastructure to support higher levels of the gaming stack. FHE’s encryption capabilities can be easily implemented into any workflow and holds the key to enhancing decentralization, security, and privacy for all users—a vital component for Web3’s successful adoption at scale.

On-Chain Gaming

 

Trustless gaming is an umbrella term that refers to the various gaming environments taking place on the blockchain, such as player-vs-player games, casino games (poker, blackjack, etc), prediction markets, e-sports, AR/VR-related games, and more. The trustless aspect refers to the fundamental blockchain design principle of eliminating trust between participants, in stark contrast to traditional gaming or gambling platforms that require the trust of a central authority or intermediary.

 

This sector holds immense potential, especially when considering that Web2 gaming has 2.7 billion annual users and is projected to generate $490 billion in revenue by 2023. And these figures exclude other sectors, such as the $87 billion online gambling market and the rapidly emerging AR/VR sector. However, the public nature of blockchain is currently ill-suited for trustless gaming from both a privacy and security perspective.

 

Let’s consider on-chain casino gaming.

 

Various limitations make them ill-suited for the blockchain at present:

  • Real-Time Positions:  Player actions are openly visible, enabling bots to exploit them in real-time, compromising fairness.

  • Historical Strategies: Blockchain records enable opponents to analyze past strategies, potentially predicting and manipulating future moves.

  • Identity Correlation: High-value players’ identities can be linked to on-chain addresses, risking phishing attacks and real-world threats.

  • Game Manipulation: Public blockchain allows exhaustive study of game mechanics, leading to potential exploitation and unfair outcomes.

 

 

Existing Approaches

 

A common existing approach used by projects such as Dark Forest and zkHoldEm is to rely upon zero-knowledge proofs (ZKPs) to bring privacy to gaming. ZKPs are great for compression as they can bundle many transactions into a single update, making them quite scalable while maintaining data privacy. This is useful in gaming, and zkHoldEm is one such example that works by having their zkShuffle smart contract provide encryption for each poker hand. Before each hand, players each shuffle the deck once and encrypt the result. When their hand is dealt, they decrypt their cards for all of the players to see. This, and details for other aspects of each poker hand, are verified through ZKPs.

 

However, this approach requires the game state to be updated on-demand each hand, with players each shuffling the deck and passing it on. We’d also argue that this approach is not very transparent. As mentioned with Snarky Monsters, ZKPs tend to be used for each game, rather than for each action. Even if a game claims to be fully honest and use ZKPs, it can be hard to verify this and reliance is placed on their off-chain integrity and systems. In the context of a Player-vs-Player (PvP) game like rock-paper-scissors, imagine a player losing 8 times in a row. It would be hard to prove the randomization occurred honestly, and the player may refuse to continue playing.

 

It’s also more complex this way – consider again the rock-paper-scissors game. On the blockchain (without FHE) a commit-reveal scheme is likely to be used, whereby a player’s choice is cryptographically committed, creating a “sealed envelope” of sorts. After all players have committed their choices, they reveal their actual choices, and the game’s outcome is declared. This provides a poor interface as multiple rounds of interaction are required which increases complexity.

 

FHE enables an improved approach with built-in transparency as each in-game move is on-chain and updates the blockchain’s state, verifiable via decryption. Async updates, rather than requiring players to shuffle cards each hand, are also possible as the card decks can be set up async.

 

With rock-paper-scissors where responses are encrypted on the blockchain using FHE, blockchain state updates can be made in real-time. The data is then decryptable once privacy is no longer required. This eliminates reliance on a single ZKP, as all data and computations can be verified.

 

This is possible with FHE technology.

 

FHE on the Blockchain

 

FHE is a game-changer for blockchain-based gaming. It ensures data remains encrypted from start to finish, enhancing decentralization and safety. User actions are encrypted on the blockchain, computed upon with FHE, and then decrypted to provide transparency and trust. It is fully on-chain with the blockchain’s state synchronously updated for all, ensuring privacy and security, and enabling new blockchain use cases.

 

It’s important to note that we are not competing with games themselves, as we wish to see them succeed and advance the industry together. Rather, we are a low-level infrastructure for confidential and secure computing that supports higher levels of the gaming stack. For example, FHE can be a base from which gaming ecosystems develop with privacy and security built-in through incorporating FHE technology at their core.

 

One promising avenue for achieving this is through Fhenix’s FHE Rollups, which empower developers to create custom app chains with FHE seamlessly integrated, all while using familiar Ethereum Virtual Machine (EVM) languages. For instance, one FHE rollup could be dedicated entirely to casino games, ensuring the complete privacy and security of these games. Meanwhile, another rollup, fully interoperable with the first, could focus on large-scale player-versus-player (PvP) games.

Is this already possible?

 

Yes, but given FHE’s complexity, there is a latency period that makes FHE best for games where actions are not time-sensitive, such as strategy games or casino games. This is to be expected of a nascent, cutting-edge technology, but we expect speed to rapidly improve throughout 2024 and into 2025, as FHE adoption increases as well.

 

Conclusion

 

Blockchain-based gaming, often referred to as trustless gaming, faces privacy and security challenges due to blockchain’s inherent transparency. While Zero-Knowledge Proofs (ZKPs) are a solution, they may not be ideal for gaming since they hide all actions behind a single ZKP. Fhenix’s FHE technology, on the other hand, allows encrypted data to synchronously update the blockchain’s state and be decrypted as needed, offering privacy, security, transparency, and trust.

 

Developers can easily integrate FHE into their workflow using familiar Ethereum Virtual Machine (EVM) languages, promoting fairness and equality in blockchain-based gaming. While FHE may not be as scalable as ZKPs currently, it’s advancing rapidly, making now an opportune time for developers to get involved.

 

Fhenix’s mission is to usher in a new era of computing, prioritizing privacy and security, and ultimately eliminating data breaches while maintaining confidentiality and data integrity for all.

 

We also recommend visiting our website at fhenix.io to learn more.

Space Recap: FHE Rollups, Scalable Confidentiality for Ethereum & Beyond

Date: 07-12-23


Space Recap: FHE Rollups, Scalable Confidentiality for Ethereum & Beyond

This transcript captions a Space we hosted a few weeks ago, with Kyle Samani, Tarun Chitra, Guy Zyskind and Guy Itzhaki. Click here to tune in the Space recording.

Kyle Samani:
Guy Itzhaki, this one’s for you. Can you introduce yourself, please? You’ve been working on the Web3 side of things for a while at Intel. What was the most interesting thing for you from those days? And what motivated you to switch over to Web3?

Guy Itzhaki:
Perfect, thanks. Yeah, a little bit of background about myself. I’ve been working for Intel for many years with various projects. I think somewhere around 2017 was when I first got introduced into the blockchain space. Back then I led Intel’s confidential compute ecosystem development, building, and leading projects through an evolving trusted execution environment. One of the first projects I did back then was actually to develop a permission blockchain network for a stock exchange for lending securities. And that’s how I got connected into the entire blockchain space. Back then, I was invited to join many conferences. I was participating there. In one of them I actually met Guy Zyskind, my partner in crime here. And we started chatting about some of the problems that we see in blockchain and the lack of data confidentiality, which eventually led to me joining Fhenix now. And then, last year, I decided that I want to transition from confidential computing and explore further the domain of homomorphic encryption, and let Intel’s homomorphic encryption business development. And we’ll talk more about FHE. And why we think it’s now the right time for homomorphic encryption, and just recently left Intel and joined Fhenix as the CEO.

Kyle Samani:
Awesome. And now Guy Zyskind. We will turn it over to you. Could you please introduce yourself? You’ve been researching and working on Web3 and privacy and confidentiality technologies for the last decade. Can you share some of your OG insights?

Guy Zyskind:
Yeah, of course. Thanks, Kyle. Yeah, I’ve been in this space longer than many people I guess. I have been here for a decade, some consider this as a badge of achievement or the other way to say that I’ve seen too many battles and barely survived to the middle. So either way, you want to look into this fine. I’ve mostly been on the, let’s say, privacy encryption side of things on blockchain, like I’ve been basically the guy with the sign ever since like 2014 saying, “Look, unless we solve privacy. And unless we solve like encryption, then, this whole Web3 thing can actually go so far.” So I still think that message is surprisingly valid a decade later. We’ll probably get a little bit more about it like what were the twists and turns. For those who don’t know, like I actually wrote, like, probably the first two papers to actually describe this whole problem of confidential smart contracts. This was back in like 2015. And then I went ahead and kind of spun that out into a project that became secret network, which kind of spearheaded in production, this idea of private smart contracts. And obviously now continuing data, mostly on research and product side with Fhenix, and FHE. And clearly kind of like, I’d say, at least for me, in my own personal journey is because I think we were waiting for FHE all along, it just wasn’t there yet. But it much like [ZK] wasn’t there yet until like 2015 in the beginning, and so I kind of feel that, like we’re having the same transition right now with FHE. Maybe just like a couple of like, “[Unclear 00:16:53] sites, at least, like in retrospect, two things that I find a bit surprising is that, if I’m thinking about like the early, like, 2014, 13, 14 15 cohorts, like, we all thought that like a decade later, it’s either going to be the case that crypto is like bust, like it’s dead, like, no one’s going to care about it, it’s not going to be useful, or there’s going to be these like explosion and widespread mainstream adoption, it’s going to be everywhere. And I think that we are somewhere in between. Everyone knows about crypto, but it’s still the case that it’s like not mainstream adopted, which is I don’t think any one of us from the early days actually expected that to be the case or a possible outcome. And I think the other interesting part is, if you think about those days, and you extrapolate it today, you see that most of the, let’s say, things that caught on in crypto, they had like the fairest versions or thoughts or ideas, even as far as a decade ago. So no one knew that DeFi would ever be a thing. No one thought about DeFi, the term didn’t exist. But even in 2013-14, people were trying to build decentralized exchanges, which was like one of the first projects I tried to do. No one knew how to solve scalability yet, but everyone knew that’s a problem. And everyone knew that it’s probably going to take one or two directions, either gonna be like off chain layer-2 scalability. And again, layer-2 wasn’t the thing, but people call it like off-chain computing. And that obviously turned into a big thing with rollups. But that was not known back then. Or the other version is that people knew that you’re going to have to find a more scalable layer-1, which I’d say is like another direction that other projects have successfully taken like Solana and others. So to me that’s also a surprising insight, like even 10 years back, people kind of identify the problem and a first approximation of the solution. And then, today, we’re actually seeing how that has manifested sense.

Kyle Samani:
Already, and now next up, Tarun, could you please introduce yourself? Could you share your initial impressions and understanding about the chief technology and how it relates to blockchain?

Tarun Chitra:
Yeah. Hey, So I am Tarun, Founder of Gauntlet and also an investor in Ever Above ventures. I think my experience sort of, actually goes back more to 2011 or 2010. I was like about to graduate college and I was like, “Oh, should I really do this PhD in physics that I got accepted to or not?” And around the time I started reading Craig Gentry, his PhD thesis, which came out around then. And Craig Gentry is sort of this kind of crazy guy who was the first to figure out how to make FHE actually work in his PhD thesis. And at that time, it just felt like this kind of very magical thing. But it also seemed a little bit crazy, because the objects, the mathematical objects you needed to deal with were just very unruly, I couldn’t imagine someone actually figuring out how they implemented it. But it just had this very nice, elegant feel of, “Hey, I can do all these operations completely privately, and separate sort of the execution of something from the privacy of the inputs and the privacy of the entire execution trace.” So I’ve always kind of, in the back of my head, had that as the thing that inspired me way before, the outside sort of blockchains and DeFi stuff. But I think what has kind of over the last couple years, been, the reason for that this captivated me, is that there’s a lot of mechanisms within Defi, that, basically can’t be made private, alone with ZK, you can get some forms of privacy for those applications, but you can’t sort of completely make them private. So the simplest example is an AMM. AMM always has to have a public price. But from the public prices, you can kind of reverse engineer what trades cause those price changes because you know exactly the sort of deterministic way the AMM function has to change. And so, no matter what you do, even if I ZK the reserves of the AMM or I ZK certain states that users have, I’m still not really actually preventing people from figuring out what the trade sizes and front running are doing different types of actions with that form. The second thing is things like MEV, you could view them as sort of, really arising from this tradeoff between utility and privacy, where the more information you reveal, the potentially better execution you get. But at the same time, it also, you have kind of some of these adverse effects. And when you start thinking about how to design MEV auctions, things like suave, things of that form, where you have the split between private state and public state, you inevitably come to run into some of the limitations of just ZK alone. And so that sort of the lens, I view this from.

Kyle Samani:
All right. Now next, we’re gonna get back to Guy Itzhaki for a handful questions. Guy Itzhaki, could you please explain what is FHE? Someone who knows very little about FHE?

Guy Itzhaki:
Yeah, for sure. So I think in the most simple way to describe FHE, which I will say is a very novel encryption technology that’s existed for several years, is an ability to run computation and data while the data is encrypted. And if we take a step back and actually think about it, prior to FHE, when we encrypted data, we couldn’t really do anything with this data, if we wanted to do anything. We basically had to decrypt it, whether we decrypt it in a trusted executed issue environment or outside of it, and then we ran the computation on top of that. The normal thing about FHE is that now we don’t necessarily need to encrypt the data in order to run whatever computation we run on top of it. But rather, we can actually do the computation on the data while it’s encrypted. And that opens a whole new set of applications around that specifically in the blockchain space. We’re all familiar with the challenge that we’re facing today in the blockchain world that the data is transparent for everybody to see. And that’s actually one of the reasons that we’ve decided to start Fhenix is the ability to finally provide a way to do operations on data while it’s encrypted, and in that way, meaning that we can have data on chain, still encrypted, but still do us use cases that I’m gonna talk about later on.

Kyle Samani:
Okay, awesome. And then the next question is what is going to make FHE implementation and Web3 so exciting.

Guy Itzhaki:
Okay, maybe Guy Zyskind can take this one and I’ll answer in a minute.

Guy Zyskind:
I don’t know, this is like an open-end question. But I guess, there are several ways to look at this. If I’m putting the research ahead, then like, until Bitcoin people were trying in cryptography and distributed systems to kind of build this one machine or distributed system that solves eCash, like the ability to cryptographically send transactions from one to another without double spend and all that. And that was like a huge thing, when Bitcoin came because it kind of solved what cryptographers have been talking about since like the 80s and the 90s. And I feel that, cryptographers have been talking about this world, where there’s like, these trusted, if you really like a world computer on the cloud, like this trusted computer on the cloud, that allows everyone to basically, run whatever logic or functions or code or application that they want, but they can trust it to hold their data securely, not leak it. And then, run those computations faithfully. This is basically called Secure Computation, literally, it describes what it is, and blockchains, with smart contracts kind of got us halfway there. We trust the blockchain not to cheat because it can’t, unless it’s broken in some really bad way. But we don’t trust it to keep our data private or encrypted or secure. And that is basically what kind of like FHE complements. And I think having that kind of system having that kind of power outside in the world, if we can make it happen, that very smart people have been trying to conceptualize for, like 40 years now, is very exciting.

Guy Itzhaki:
And maybe just adding to that, I think one of the biggest promises of blockchain was that it enabled users to own their data, but not really to control who they share their data with. And I think the addition of FHE into that space is that now for the first time, we’re actually enabling users to control who can see their data, who they share their data with, and potentially even monetize that, which I think is one of the more exciting parts of that.

Kyle Samani:
Okay, and then next question for I guess, Guy Itzhaki or Guy Zyskind, whoever can take it, but why is now the right moment for Fhenix to launch?

Guy Itzhaki:
I think everybody mentioned it already. But FHE has been discussed for many years. But up until now, it was quite hard to implement. It’s computation bound. It’s very complex. But there’s been several advancements in that space, both in terms of computation. And in terms of simplifying the complexity. If you ask people who are involved in the FHE space for many years, they’ll say, “Yeah, in theory, we can do FHE. But trying to run it on a large amount of data, it would just not be feasible.” But what we’ve noticed then, was that by actually running FHE computation on right hardware plus improvements that’s happened in the FHE algorithms themselves, made it quite feasible for deployment today. And a lot of the complexities that we’re considering in the past or obstructed by the right usage of compilers and libraries, that absorbs the complexity. And when we decided to start Fhenix, one of the key goals for us was to make it as easy as possible for developers to develop, they don’t need to learn a new language, or they don’t need to become experts in FHE. And once that was able to be done, it was quite obvious that is a great time to start Fhenix, since we have a known problem in that space, right? The lack of data confidentiality, plus we have the right cryptographic solution here that can bring the solution. So I think it’s quite exciting because we’re literally seeing the hockey stick coming up in the next, I would say 12 to 18 months, with the introduction of dedicated hardware for FHE which would speed up performance even further standardization bodies that are working on FHE will be released in 2025. As well as a shift in how the blockchain community starts treating data confidentiality.

Guy Zyskind:
Also, this is like a great place to mention Zama. We’re working with Zama very closely on these Zama has been at the forefront of FHE from the last few years. They have like some of the most brilliant minds, and engineers working on making FHE much faster. And, just working with them to get on the journey. It’s pretty clear, at least to me, and hopefully to others that like this is like Guy Itzhaki was saying, we’re experiencing this hockey stick moment, in the sense like, I feel this is very similar to what we saw with ZK technologies, like 2015, people were like, “Yeah, maybe it’s okay for payments, but it’s not gonna scale for anything else.” Then 2017, people started to pay attention. And then it just like hit critical mass, and the rest of the story. So it does seem that there’s a lot of similarities, at least when it comes to how fast like FHE is going to scale now similar to what we saw with the ZK.

Guy Itzhaki:
And it’s probably worth mentioning that one of the more exciting things about FHE is that, yeah, we’re starting the journey, and the blockchain space. But the potential of FHE goes way beyond the blockchain world. We see the interest in Cloud service providers, financial institute’s which will eventually drive significant investment and resources, education and hardware. And definitely, since we’ve announced Fhenix and the work that we’ve done with Zama, we saw a spike in the interest and FHE, that’s a good sign. And we definitely believe that the next two years are going to be quite phenomenal in terms of the market education and market need for data confidentiality.

Kyle Samani:
All right. Next up, guys, I think we have FHE different from zero-knowledge cryptography such as STARKs?

Guy Zyskind:
Yeah, that’s a very good question. Because, I feel that’s like a pretty big misconception. Although people are starting to kind of pick up and understand the differences. I think the best way is to just give maybe a couple of examples and kind of like frame FHE and ZK in each of those. So, FHE, first of all, FHE is, people said before, basically allows you to compute over encrypted data without decrypting it. So again, like given maybe an example or to imagine like, Kyle, Tarun, myself and Itzhaki, we want, for example, compute, which one of us earns the most money, like, who gets the highest salary, but we don’t want to share our own salaries with each other, we just want to get a result, like, who is that person, this is basically computing the max function between the four of us. So I mean, with FHE, it’s conceptually, trivially forever FHE, like each one of us can encrypt the data using the same key, then each one of us, we can sell it to some Cloud server out there that understand, that can run FHE computations, can basically take all of our encrypted inputs, and basically compute the max function of them and just send them the result. And if you try to do that with ZK, for example, this is impossible. ZK doesn’t work that way. In ZK, there’s a prover and there’s a verifier. The prover, basically, is the one doing the computation. So, basically the prover has some data, it can run some computation of the data. And then it can send someone else that someone could be like, anyone, the result and say, “Here’s the pool that I actually computed over the data that I have, but I’m not going to show you the correct result. And here is the result. And here is the proof that it was done correctly.” So if we take the same example, where we want to compare all of our salaries, now we have this single point of trust that we just can’t avoid. So maybe we trust or maybe we settle Kyle on trusting you, meaning each one of us is sending you our salary. And then you compute the max, like, who earns the most money. And then you send a proof, a ZK proof to everyone. You don’t reveal the underlying salaries, although you solve them. But you do tell everyone else with the proof who is earning the most money. Another similar example of this, maybe, let’s say, for example, is using something like an encrypted ChatGPT. So I think I speak for everyone, when I say that sometimes, you ask ChatGPT some questions that you might not actually feel that comfortable sharing, especially if there’s some business secrets, or some very private information about yourself. Now, imagine that all of this was done in FHE. So you could theoretically have a solution where you encrypt your prompts to ChatGPT. And then ChatGPT basically runs the same thing it does today, but over the encrypted data, and then sends you back the result without actually ever decrypting or seeing your own query. Again, that is possible with FHE. But that’s not something you could do with ZK, like, the best you can do with ZK, for example, is you can send a ChatGPT your query, your prompt in the clear, and it will see a query. So, [no better than], but it can at least maybe verify to you like to prove to you that it actually ran the latest model, and it didn’t run ChatGPT 3 instead of 4, for example. So the bottom line is like the two actually solve different problems. They’re useful in different contexts. But if you really want to combine data from different people, that’s private, if you really want to be able to just get a level of privacy, like ZK only gets you so far, and FHE actually gets you all the way.

Kyle Samani:
All right. Next up, we are gonna get to Guy Zyskind, what is your vision for Fhenix and FHE and Web3?

Guy Zyskind:
Yeah, so this can be much shorter, we kind of touched on that. Like I said, I’ve been the guy with the sign for 10 years saying that, like we have to solve problems like on-chain, like lack of confidentiality, lack of privacy, not just because people care about the data, that is obviously a very important thing. But because of how Web3 works. In Web3, everything is published, which means that there’s just a lot of use cases that you simply cannot do without FHE. So you want to do private voting, you need something like FHE. Again, there are other solutions, but that’s probably like the Daisy Swan, you want to do MEV Auctions, as Tarun mentioned, you need something like FHE. You want to do an on-chain game. You want to do a simple game of [on-chain] poker, you can’t actually do that with ZK, you can do it on a blockchain because everyone is going to see your cards, and then there’s no game. So you need to FHE. So there’s clearly a world of applications that you just cannot do unless you have on-chain FHE. And to me, that’s like what’s exciting and that’s really the vision. The vision is that five years from now, using Fhenix, using FHE like people will realize in retrospect that there were so many applications that they could not have done today without FHE being available to them.

Guy Itzhaki:
And maybe just adding on top of that clearly Guy Zyskind gives examples of where a Fhenix and if he can bring value to existing Web3 applications today. My background is, I’ve been in the corporate space for many years. I have no doubt that if we want to make blockchain a success and actually have it widely used, and have corporations and financial Institute’s start seeing Web3 as the future. You have to have data confidentiality. There is no way that financial institute’s will put anything financial if they know that others can see it. So yeah, it’s a longer term and it will take time, but for me, transparency is a feature in some applications, but it’s definitely a blocker to many of the use cases that Zyskind described. But the ones that we’re actually haven’t even started thinking about.

Kyle Samani:
All right, next up. Guy Zyskind, can you tell us about your recent research and findings in FHE, and the rollups and the white paper you all just published for Fhenix?

Guy Zyskind:
Of course, and obviously, we can go as deep or shallow as we want. But just at a very high level. I think first of all, the white paper basically makes two observations. One observation is that, although the technologies are very similar, ZK and FHE, they share a similarity where both ZK and FHE, they require very heavy to do cryptography, which means that there’s no going around it, like whoever runs computations with FHE, is probably gonna have to run like either very expensive servers, or gonna have to utilize like, specialized hardware. Again, we’re seeing the same thing with ZK provers so that’s the similarity there. And that kind of bottleneck, let’s say, is a much better fit for a rollup architecture, where not all validators basically replicate the computation on the first layer, and duplicate it, and then you have like an x50, x100, x1000 depends on the number of nodes, cost factor for each computation. Plus, you have to wait until kind of like, the weakest link, the slowest node in that. So FHE, if you feel that you need rollups, when you’re not using FHE, where you are using it on plaintext, you definitely want FHE to be running in the world of architecture. That’s observation number one. Observation number two, and that’s a bit more nuanced. So hopefully, at least some of it will be clear to others. But it’s not that bad. The fact that FHE is, unlike other privacy technologies, like secure multi-party computation, when you’re doing FHE, you’re basically just working with encrypted beats, with like cipher texts. And everyone can see the cipher text, like you can publish them on-chain, is the whole on, like, you can publish the actual encrypted transactions on-chain, you can send it around, you don’t need to be selective in what you share with other parties. So again, it’s very, very amenable, it’s very constructive for a rollup architecture. Compare that with, again, sometimes secure multi-party computation, where you kind of have different validators and each validator, you have to share some different version of the encrypted data. And you can’t actually make the public because then you actually repeat the data. So those were the two observations why it’s needed and why it can work. The biggest open question that we had was, how do we do it? So you can actually do a ZK on top of FHE all up? But that is very expensive. Like the latest research says, this is three folders of magnitude slower. There’s a lot of people working on advancing it, including Zama, including [Unclear 00:43:45], we’re talking to, but it’s not there yet. That’s gonna take a while. So then the other question was, okay, on the optimistic avenue, the optimistic FHE rollup avenue, can that be done? And there the problem was, we want to build this on top of Ethereum. But then how do you actually do settlement of transactions or smart contract executions that are under the hood not running, like playing solidity. Well, solidity, but they’re not running, playing EVM under the hood, they’re actually running some pretty sophisticated technology. And we solve that, like we actually had to work for a few months to actually make sure that we solved that and we worked very closely with the [Unclear 00:44:35] team, who wrote the general purpose Web Assembly prover that works on the Ethereum L-1, which plugged beautifully into what we’re doing. But I think that’s the biggest breakthrough, like the fact that you can actually build an FHE rollup on top of Ethereum L-1 today, and you don’t actually have to make any changes, or any hacks to get it to work on Ethereum. You don’t need some special EIP, an opcode to actually make them for Ethereum that it seems.

Kyle Samani:
Alright, and then just kind of following up on that. How did the FHE rollups actually work? What are the key components here? What are the other kinds of major pieces here?

Guy Zyskind:
Yeah, all of the pieces are the same for the most part, they work differently to an extent, but they are generally the same, we have a sequence cell, who orders the transactions, again, transactions can be encrypted, then you have like an execution node that is actually executing those transactions, those are smart contract executions. And that has to be a pretty beefy computer, like ZK prover, this has to be something beefy that runs FHE computations. And then you have a settlement layer, which can be the Ethereum L-1. But it can obviously be other blockchains as well. And you have a data availability layer, which again, can be the Ethereum L-1, or it could be some other solution, like IDTA or Celestial, or maybe something that we cook up, there is there is a caveat here, cipher text ever blow up, they’re bigger, it takes more storage and we’ll actively working on improving that. But that is something to consider. And then the one piece that is definitely unique and different, and doesn’t actually exist in other places, is a threshold network. So without getting into too many details, whenever you read encryption, you should imagine there is a secret key somewhere. And where does that end? Who holds that secret key? In this case, we want all users to be able to encrypt via the same key or maybe there’s different keys, but at least more than one user should be able to [Unclear 00:47:06] using a single public key. So where does the secret key live? Well, that secret key lives in some treasure network. Ideally, over time, that can be something that we scale out, but probably we’ll start with something that’s fairly small. And that network is needed. Because just to give you an example, imagine you have a contract that is like a [Unclear 00:47:26] voting contract, where people basically vote on whatever outcome, we want the votes themselves to be encrypted. You can use FHE to tally the votes without decrypting or revealing anything. But at the end, do you want to be able to publicly decrypt? Like who won? Which option one or who won the election? So you need to be selected with that. And for that, you need to use the secret key in some form. So that network actually does threshold decryption, to publish the result.

Guy Itzhaki:
And, just listening to that, people should understand that even though it was a core underlying infrastructure is FHE based, the long term solution will require us to build a platform that uses ZK, for proving on the user side. FHE, for encryption, and MPC for the threshold network. So it’s not one versus the other in terms of encryption capabilities, but rather, it’s actually a combination of all three to really fulfill what’s needed here.

Kyle Samani:
All right. Next question. What makes FHE rollup such a big deal for our space? And especially for Ethereum?

Guy Itzhaki:
Tarun, do you want to take this one?

Tarun Chitra:
Yeah, for sure. So I think, if you look at the Ethereum roadmap, a lot of it is definitely focused on increasing proving capacity and increasing points where there’s aggregations of information. And that can be verified by anyone kind of relatively cheaply. I think a fundamental tenet of the Ethereum community is that nodes are relatively easy for people to run that kind of inherent belief and kind of in a lot of ways, the only ways to do that are via advanced cryptography. So that’s sort of like the highest level philosophical view of this. I think, a place that one should think of, FHE at least in my mind, when I think of threshold FHE is, you have on one hand, something like MPC where you can really– That’s used in a lot of places. It’s used in wallets, used in fire blocks, and used in Coinbase. But MPC has this problem of tons of rounds of communication, as Itzhaki mentioned earlier. On the other hand, you have ZK, which, via a lot of tricks and a lot of things that kind of people invented from 2012 to 2016, you kind of have this distinctiveness aspect. And you can kind of do things in a single step non-interactively. I think FHE sort of is in the middle in a lot of ways, there’s more communication, in some ways than the ZK. But for that extra communication, you get a lot of units of better mechanism design. So, when you think about a lot of mechanisms, say MEV auctions, people submit their transactions, the MEV searchers kind of aggregate transactions and try to figure out how to add in, either front running transactions or arbitrage transactions, then they submit that to block builders, who then kind of give the right to the proposer who wins a block in current Ethereum. In that entire sequence of that chain of events. At every step, once the user discloses their transaction, that’s completely public to everyone in that entire chain of third parties. And in a lot of ways, that’s where most of this extracted value that is not necessarily good for the end user gets lost. Now, there’s obviously efficiency that comes from people being able to see order flow, and figure out where to send it. But FHE provides, in my mind, one of, the most foolproof way of trying to make the vision of not having that value, as high as it is now, be able to reach its full potential. So if you think about the direction people are going with MEV options on Ethereum, a lot of things are looking at things like STX and that’s purely from the perspective of it being practical. But from a sort of threat model standpoint, STX is sort of one of these sorts of things where, A, it has historically had an insane number of attacks against it. B, at the end of the day, you’re still trusting Intel with the key, which is different from trusting this network of [structural] designers. And I think what we’re going to end up seeing is that STX does provide this kind of lower net value extraction for the network while keeping throughput up and keeping usability up. But people at some point, will realize  the kind of end state that is a lot more, is kind of at the level of security that the room desires is going to end up having to look more like FHE and less like ZK. So maybe that was kind of a long winded answer to this. But I think within a lot of places within how transactions are processed, Ethereum improved privacy with better user outcomes for non-validator users.

Kyle Samani:
Alright, next question we’ve got here. What are one of the most interesting use cases that FHE rollups can support? Anyone can jump in here.

Guy Zyskind:
I actually agree that MEV auctions are a big thing. I’m kind of curious what other interesting mechanisms like that we can do. Like, I think we’re only scratching the surface and I completely agree with Tarun. One thing and it’s not that flashed out. But one thing that I’m pretty excited about is and I think that’s a combination of what FHE can do and simplicity and the fact that it’s, at the end of the day, developers just write like solidity contracts, is like you can build something like native BTC like native Bitcoin, native Solana, native other assets, [Unclear 00:54:58] of a smart contract Ethereum, and then you can build something like, like cross chains swap between assets without actually wrapping them first and all that, you can do something like a fully on Ethereum, very simple kind of like version like uniswap. But they actually operate cross-chain like THORChain or THORSwap. So that’s something exciting. I actually think there’s a place– That’s not necessarily a very popular thing. Or at least that creates like a lot of– There’s a lot of, let’s say disagreement in our space between like, what you can approach. But I think that you can do things like private and compliant devices or both private, but you can actually add a lot more safety features and compliance related features, just because of the level of programmability that something like FHE gives you compared to something like, private transactions using ZK. And finally, I mentioned that I think on-chain games are also very interesting. I don’t know if the market is ready for it yet or not. Maybe it is, maybe it’s not. But generally speaking, I think that on-chain game is basically dead on arrival, without FHE.

Tarun Chitra:
One thing I would add, at least just from the perspective of like, trying to write programs, is, while I think there’s a lot of, obviously, given the increase in ZK proven capacity, and the improvement in tools, I think SERCOM looks 100 times better than it did even a year and a half ago. There’s kind of this inherent overhead on developers when writing with ZK code where you have to keep track of a lot of the state that you’re using. And it’s not as clear to the end user, like which pieces of state in their program need to actually be completely private, which pieces need to be put into STARK, which parts of the circuit have to read, there’s a lot of sort of design decisions that one has to make in ZK, that I think, add a lot of overhead and complexity to the developer experience. One thing that I think I’m personally most hopeful for FHE is it actually makes it so that I might be a junior developer, who probably doesn’t know anything about how cryptography works. But I could write an application without having to have this insane overhead of like, really understanding every piece of the circuit to know where the privacy guarantees are, and, this is not necessarily a flaw in decay, and then FHE will have some of this overhead too. But it’s just that I think, if you want to have this kind of dream future where I can write F of X, and F of X does all the encryption without me having to be like, “Okay, X needs to be partitioned into secret state and public state, I need to map X to this particular representation of F,” which is the circuit, I have to take the output, and then I have to mangle it back into whatever the output of F is supposed to be. Like, all of that stuff should be a lot easier if FHE just works. And I think that to me, that’s sort of like a mega application. But it makes it much easier development wise.

Guy Itzhaki:
I think people that have heard me speak in the past, I like to give the example of a limited access hackathon that we’ve done in July, together with Zama. And that was really, in the early days, a definite that we had. And I think we were really overwhelmed with developers ability to achieve their goals in, I would say probably less than 24 hours, we had a team to try to build private voting. And they’ve tried doing that using ZK for several months. And in less than 24 hours, they were actually able to achieve 80% of their goals. And the reason for that is just FHE is the right tool for the job. It’s very easy to use. In terms of the actual development, you’re using solidity, as well as an FHE library that enables you to just decrypt and encrypt the data that you want to encrypt and decrypt. And that’s pretty much it. So of course, there are design considerations that need to be taken into account. But actually, it’s very user friendly. The developers don’t really need to understand FHE in order to use it.

Kyle Samani:
All right. Next up, we are gonna get into, I guess a kind of a community question here and maybe Tarun you take this one. Since we can’t eliminate MEV on Ethereum, I was wondering if we can create an application that’s going to be similar to Flashbots that could run on Ethereum, I’m using FHE to minimize MEV?

Tarun Chitra:
Yeah, I mean, if you look at the roadmap, Suave is something that right now is planning on using STX for giving partial privacy to users. So users can encrypt their set of transactions and then reveal some metadata about it, say, “This transaction has a trade whose price needs to be at least X,” but doesn’t tell you exactly the quantity or it doesn’t tell you exactly the price. And then it runs an enclave that is used to determine how to sequence the block and how to charge for it. But I think the and, if you talk to Flash about themselves, I think they also agree that like in a world where FHE is efficient, and a world where they could do it fast enough. They would rather use that than STX. I think it’s really a question of, how do we get to the point that FHE latency wise is competitive with things like the [Unclear 01:01:32], and I think by trying to actually build real applications, like rollups trying to build real applications, like DeFi protocols that are able to give you better guarantees on how interest rates are calculated without revealing a lot about, say, the interest rates that are revealing a lot about the users who are have loans out? I think there’s a lot of stuff in that part of the world that will naturally lead to people figuring out how to make these optimizations, to make things more MEV resistant at the application level. And then as FHE, the latency for execution goes down, being able to use it in more real time systems.

Kyle Samani:
All right. Ah, got it. I guess I think there are just all community questions from here on out. We’ve already kind of touched on this one, but maybe it should recap. What are the biggest differences between ZK and FHE rollups?

Guy Itzhaki:
I can take this one. I think even though it sounds like we’re using the same term. It’s actually not though. The FHE rollups that were discussed in the white paper are really based on using optimistic rollup while introducing data confidentiality through FHE. ZK rollups, they’re mostly for scalability. So I would say, there’s not really a comparison here. And it’s not as if we’ve created the third type of rollup, which is now FHE rollups. But rather, we can say that we’ve taken the optimistic rollups and now for the first time introduced data confidentiality, we’re definitely planning to do the same with ZK once this becomes available, but this is more of a matter of a couple of years, down the line.

Kyle Samani:
All right, and then we are going to keep rolling with these community questions. FHE is advanced, but requires a lot of computation. How can Fhenix offer relative performance? What is the block time?

Guy Zyskind:
Yeah, I’ll take this. I mean, just in general, I’d say that, a big part of why we’re doing like FHE rollups and not like FHE, a side chain over the one is because, like, we feel though, we can scale it much better and much faster using the rollup architecture, that’s obviously true for non-FHE and true for FHE. We’ll still like optimizing and doing a lot of stuff. So I expect people will see things get much better and much faster all the time, the next like one to three years. Right now for the first version, again, it depends on transactions. It depends on stuff, but like we’re trying to aim at something like, comparable to Ethereum level on the layer-1. So not quite as a non-encrypted rollout phase that’s going to take a bit longer, but like between the Ethereum level scalability, maybe actually even slightly less for the first version. So maybe block times will be like, 30 seconds, instead of 15 seconds, maybe you can feed about like half of the transactions, you would in a blog, or you would feed the same amount of transactions, but the blocks are like two weeks longer, something along those lines.

Guy Itzhaki:
And it’s probably worth mentioning that I think there are over a dozen companies that are actually now either building or looking into building dedicated hardware for homomorphic encryption. And once this comes into the market, which I would say timeline is like 12 to 18 months, this will definitely make a transformation in FHE computation.

Kyle Samani:
Oh, all right. Next up, are there any competitors to Fhenix? And if yes, how is Fhenix different from them?

Guy Itzhaki:
Yeah, I have to take this one. I think the right term to look at the landscape in general is not so much in terms of competition, but rather, I’d say maybe even coalition. And the reason is that, no, there’s a lot of market education that needs to happen. Now. I think we all need to make sure that people understand the value of data confidentiality, the value of FHE. So from our standpoint, if there are others, and yes, there are a few that we can mention, whether they’re doing a through ZK, or through Trusted Execution Environment or through FHE. That’s really in the benefit of everyone, we believe that this market is going to exponentially grow. And there is going to be a place for multiple entities, we have the ones that are leading the market with the FHE infrastructure. So we’ve mentioned Zama, you know, earlier along the way, and they’re definitely one that are in the most advanced place and providing the FHE core capabilities. Sunscreen is another one that’s out there. But these are, you know, I’d say providing the FHE components needed for the blockchain world in terms of others that are actually building IoT infrastructure. So on the Trusted Execution domain, we have the likes of secret networks that we’ve mentioned, that are offering great capabilities using ties. And then we have ATO and Aztec that are doing the same. Same with zero knowledge. I think our unique value here is twofold. A were the first one to actually do the FHE rollups with a FHE. And second is that I would also add the amount of people that really understand FHE is not very high. And we have a really great team here with tons of experience, and both the developer and the business development part. So I would say to summarize it, yeah, we’re doing the rollups, we’re probably the only ones doing FHE roll up at this point, even though we suspect that there will be others. And that’s pretty much it.

Kyle Samani:
Okay, I know, we’re basically over on time. Got two more questions, guys. Let’s go through this quickly. I want to make sure I answer, are we happy to answer all of the community questions? Next one is FHG seems to deal with tons of data, where’s that data stored?

Guy Zyskind:
All so very quickly, there were the usual suspects that you can do it on day one, you can do it on dedicated, like L twos, like data availability layers. We’re still considering which one to choose, or maybe we allow, like both options. FHE I mean, although FHE, uncompress Kali, is there’s quite a big blow up in terms of storage. I mean, that’s right, there’s a technique called Trans ciphering, which, I believe, will be greatly improved, like in the next like, year or so. And trans ciphering is, you know, in very simple terms, a way to compress the cipher text. And you can do that before you store and then you can decompress after you load them. So, generally speaking, the overhead might not actually be as big as is, people might think. But it’s a tradeoff. And, that’s something that we’re kind of gonna have to play with and experiment with. And also see like, you know, what people feel comfortable with in terms of like, cost of storage and all that.

Kyle Samani:
Okay, and the last question here, guys, what does it gonna take to implement Fhenix on top of Ethereum? Is that possible, or does Fhenix only work on its own blockchain?

Guy Zyskind:
Yeah, that’s literally the white paper. The white paper is a car that proves that like, you know, you can build it on top of your favorite, and we’re doing it right now.

Kyle Samani:
Awesome. Well, hey, everyone, I know we ran a few minutes over. Thank you all for tuning in this morning or afternoon or maybe middle of the night, depending on where you maybe appreciate all of the community questions coming in and all of the excitement around Fhenix. I’m very honored to be an investor along with some of the other folks here. And thank you, Guy and guy and team for committing your life to building Fhenix.

Fhenix: Pioneering A Blockchain Renaissance With FHE

Date: 05-12-23


Fhenix: Pioneering A Blockchain Renaissance With FHE

Blockchain technology is currently poised to be the next major disruptor in various industries, promising widespread impact. However, it faces a critical limitation: all on-chain data is public. To foster widespread adoption, there is an urgent necessity to implement robust data encryption and enable its practical utilization.

Enter Fully Homomorphic Encryption (FHE): an advanced encryption technique that allows for computations on encrypted data without the need for prior decryption. Fhenix is at the forefront of bringing FHE to the blockchain, establishing on-chain confidentiality as the new standard of excellence.

Our mission is to lead a new era in computing, where data privacy and security aren’t mere promises but are ingrained guarantees. We’re committed to simplifying the integration of FHE into the workflows of Ethereum Virtual Machine (EVM) developers, making this transformation accessible to all.

A New Era of Encryption

Vast amounts of sensitive data now exist online due to the digital nature of the new world. At best, this requires businesses to adhere to strict data laws, and at worst leads to massive data exploits. Even the most advanced encryption techniques are insufficient, with exploits having impacted 422M users in 2022 alone.

This isn’t at any fault of encryption researchers – these techniques are extremely complex and advancements take years, if not decades. And a major weakness is that data must first be decrypted in order to be computed upon, before being reencrypted. This exposes the data to more attack vectors, contributing to exploits.

The superior method would be to keep data encrypted its entire journey. That is why it’s incredibly exciting and aspirational that Fully Homomorphic Encryption (FHE) has now arrived. Research into FHE began in the 1970s, and recent advancements have finally made it possible.

This has major implications for nearly every industry in existence. FHE can now be integrated into the blockchain, making that privacy and security is the status quo. It’s a naturally superior technology that benefits society as a whole, and the best part is that it’s easy for any EVM-based developer to implement through our fhEVM programing language.

The Three Phases of Progression

Bringing FHE to the blockchain means that all on-chain can have FHE built into it from the ground up. As the amount of on-chain data grows exponentially in the coming years and impacts every industry, it’s hard to understate the significance of this.

We are undergoing a true renaissance of how computing is done. This technology will have far-reaching societal implications on three levels:

  • Phase 1: Security & Privacy

  • Phase 2: New Applications

  • Phase 3: The New Web

 

Phase 1

This can be considered the low-hanging fruit, but already this has major implications for nearly every industry. By enabling computations on encrypted data, privacy is preserved while attack vectors are significantly reduced.

In the context of consumers, this means data privacy and security. For businesses, it means a reduced likelihood for data corruption and easier compliance with relevant laws. It also means reduced data security costs, and the ability to engage in private transactions on-chain. This is relevant for every Web2 or Web3 business.

Phase 2

The next area of impact will be focused on the development of new applications. Some of these are already known and possible today, such as:

  • Private voting

  • Trustless gaming

  • Payments

  • Healthcare

  • Anything else involving sensitive data

There are already 200,000 developers using Solidity. We believe this will rapidly increase, alongside other EVM languages, and our fhEVM enables any EVM-based developer to incorporate FHE technology into their work.

For example, it took a Web3 developer less than 24 hours to build out a fully private voting application on the Fhenix Devnet – something previously unimaginable.

Phase 3

The final tier is where things get really interesting, and we don’t quite have all the answers yet as to what may happen. Think of it like A.I. – yes, we know it will have an unimaginable global impact, but we don’t quite know exactly how as of yet. We do know that it will impact every industry and all other
cutting-edge technologies.

Consider the following: blockchain is a naturally superior technology that suffers from inherent transparency. Regular encryption techniques are critical for data privacy and security but continue to suffer from exploits and may soon be cracked by quantum computing. Cloud computing requires data to be decrypted before being processed, leading to delays, increased costs, and security flaws. Fully Homomorphic Encryption is the end game for all of these.

It builds privacy into blockchain, is secure against quantum computing, and will improve data processing and data integrity for every industry that operates to some extent digital (which is all of them).

 

The best part is that it’s also extremely accessible While other cutting-edge spaces like A.I. and quantum computing
require years of extensive research experience to work in, any EVM
developer can implement FHE into their blockchain workflow
through the easy use of the fhEVM.No technology this powerful has ever been available to so many people at once, which is also why we believe that true innovation will occur.

It’s a true renaissance of how we compute data, which will ultimately increase security and privacy in every industry. We believe this will reduce security costs, but it may also make data flow much more efficient due to not requiring decryption before computation. However, the true extent of where this takes us depends on how innovators decide to implement the technology.

Conclusion

In summary, encryption is important to nearly every industry in existence and yet significant advancements in the space are hard to come by. At long last, FHE has not only arrived, but arrived on the blockchain. This means that data can remain encrypted during its entire journey.

We see this moving society forward in three phases:

  1. Direct benefits to consumers and institutions

  2. The development of new confidential applications

  3. True innovation and new use-cases that we cannot predict as of yet, given how cutting-edge this
    space is.

Our mission is to help usher in this new era of computing, making privacy and security the default for all. We hope to make data breaches a thing of the past, and to maintain confidentiality and data integrity for all.

We also recommend visiting our website at fhenix.io to learn more.

FHE-Rollups: Scaling Confidential Smart Contracts on Ethereum and Beyond – whitepaper

Date: 16-11-23


FHE-Rollups: Scaling Confidential Smart Contracts on Ethereum and Beyond - whitepaper

Abstract

We introduce the concept of Fully Homomorphic Encryption (FHE) Rollups: a more scalable technique for executing arbitrary confidential smart contracts. Recent works [1, 16, 39] have shown that FHE is a viable solution for adding confidentiality to smart contracts. However, these works limit scalability as they require all nodes in the network to execute FHE computations and reach consensus over the encrypted state.

Inspired by the recent movement towards layer-2 solutions in the Ethereum ecosystem, we present the first rollup based FHE architecture. We argue that while for plaintext computation rollups are a needed solution, in the context of FHE, where the computational overhead is orders of magnitude higher, they are a necessity.

In our design, we take an optimistic rollup approach, allowing us to avoid the orders of magnitude penalty incurred by state-of-the-art verifiable FHE techniques [43]. In fact, our framework can be seen as a cryptoeconomic solution to solve the same problem.

Focusing on the Ethereum ecosystem, we present and overcome the challenge of the base-layer arbitrating nonEVM native fraud proofs. We achieve this without requiring any changes to Ethereum, showing that native FHE rollups on Ethereum are indeed possible. We build a partial proofof-concept that demonstrates this using Arbitrum’s Nitro prover and Zama’s tfhe-rs libraries.

Download Whitepaper PDF 

1 Introduction 

Preface: This is the first release (v0.1) of Fhenix’s ’Rolling Whitepaper’ on FHE Rollups. It is meant to be a breathing document we update and expand on on a rolling basis, including incorporating feedback from our growing community, as well as external researchers.

Blockchains ensure correct execution and censorship resistance in a trust-minimized way (i.e., without trusting any centralized operator), at the expense of data confidentiality. Inherently, all data on-chain is public, because all nodes need to see the data to reach consensus. Despite popular belief, this extreme level of transparency is a by-product and not a goal of the system, and it greatly.limits the type of use-cases we can build, since we cannot build any application that needs to utilize sensitive data.

In recent years, researchers and practitioners have employed several privacy-preserving technologies to solve the problem of confidentiality on the blockchain, in a body of work that became to be known as confidential smart contracts (e.g., [2, 13, 38, 39, 48, 49]). Of all these techniques, Fully Homomorphic Encryption (FHE) is perhaps the most ambitious, as it allows to directly compute over encrypted data without decrypting it. FHE has improved by leaps and bounds since Gentry presented the first construct almost a decade and a half ago [19]. Still, FHE requires significant computational overhead compared to computing in plaintext, making it impractical for execution at the Layer 1 (L1) level where every node is required to replicate the entire computation, which is the approach that state-of-the-art FHE-based confidential smart contracts frameworks are taking [1, 39]. Inspired by the recent movement towards layer-2 solutions in the Ethereum ecosystem [26, 35, 36], we present the first architecture of an FHE-based rollup. We argue that while for plaintext computation rollups are a needed solution, in the context of FHE, where the computational overhead is orders of magnitude higher, they are a necessity. In a rollup architecture, smart contract execution (the heavy-duty part of validating blocks) is separated from verifying the execution and reaching consensus. This ensures that only a single node (or a small number of nodes) are actually doing the computational heavy lifting, without reducing security. Furthermore, this node can be vertically (and horizontally) scaled as needed, including utilizing more expensive specialized hardware (GPUs, ASICs). The latter is common with zero-knowledge (zk) based rollups 1 , which like FHE also leverages computationally-intensive cryptography, and can be leveraged in much the same way for FHE computations. However, in our design, we take an optimistic rollup approach as opposed to a zk-rollup approach, allowing us to avoid the orders of magnitude penalty incurred by state-ofthe-art verifiable FHE techniques [43]. In fact, our framework can be seen as a cryptoeconomic solution to solve the same problem.

____________________________________________ 

1 e.g., https://www.ingonyama.com, https://www.risczero.com

1.1 Our contributions In this paper, we make the following main contributions:

• We introduce Fhenix, the first layer-2 confidential smart contracts platform, enabling greater efficiency and scalability.

• We demonstrate through a proof-of-concept implementation, that an optimistic FHE rollup can be built on top of Ethereum, without making any changes to the base layer. While our work extends beyond Ethereum and EVM chains, showing that this is possible on Ethereum today implies that the most used smart-contract ecosystem can be augmented with confidential smart contracts.

• Outside the context of blockchains, our solution can be seen as a more efficient (cryptoeconomic) solution to the problem of verifiable FHE.

1.2 Related Work

Our work builds upon the existing body of research and development of confidential smart contract platforms. Unlike all other works, to the best of our knowledge we are the first to describe a solution that operates fully and natively as a L2. More specifically, other confidential smart contract platforms usually differ by the kinds of privacy-preserving technologies they use:

• Trusted Execution Environment (TEEs) Based. Currently, the only confidential smart contracts networks in production are using TEEs (or secure enclaves) [13, 29, 38, 47]. These networks simulate secure computation by allowing users to encrypt their transactions with keys held inside of a secure enclave. Transactions then get decrypted and executed inside of the enclave, which ensures confidentiality as long as we can trust the security of the TEE. While TEEs are by far the most efficient solution, they are susceptible to side-channel attacks and other vulnerabilities (e.g., [7, 12, 42]).

• Secure Multiparty Computation (MPC) Based. Since our work relies on Threshold FHE, we share a similar threat model with these works (e.g., [2–4, 20, 48, 49]). However, for the purpose of presentation, we separate these from FHE-based solutions, as they often rely on linear secret-sharing [5, 21] and garbled circuits techniques [46]. The main drawback in these techniques compared to our work is that MPC protocols need to communicate data proportional to the circuit size in order to evaluate it. In the case of secret-sharing-based MPC, all parties also need to sequentially communicate with all other parties any time they evaluate a multiplication gate. In the context of public blockchains, this is impractical, as the latency is quite high and the bandwidth is limited. Furthermore, as these systems require multiple interacting nodes for every contract execution, they are not amenable to a rollup architecture such as the one we are proposing.

• ZK-based. Different works have considered confidential smart contracts using different ZK schemes. However, since ZK techniques are more suitable for verifiable computation (e.g., [34]), their utility for confidential smart contracts is limited. To overcome this, Hawk [28] suggested having a data-manager – an off-chain party that is tasked with collecting inputs from different clients and is trusted with seeing everyone’s data. Alternatively, other platforms impose limitations on developers [8, 9, 24, 45].

• FHE-based. In the last couple of years, as a result of significant FHE performance improvements, HE and FHE based solutions have started to emerge [1, 16, 39–41]. These platforms are closest to our work, but none of them adopt a rollup architecture, which limits their scalability in practice. Some of these works adopt a Threshold FHE structure as we do (e.g., [1]), whereas others such as [40] allow limited functionality, but without a shared global encryption key-pair.

2 Preliminaries

2.1 Rollups Rollups are a scaling solution designed to alleviate the congestion on the primary L1 chain, in particularly Ethereum. With Ethereum’s growing user base, the need for scaling solutions has become paramount. The primary goal of scalability is to enhance transaction speed and throughput without compromising on decentralization or security. Rollups execute transactions outside the base layer, posting back state-updates alongside proofs of correct execution. Ultimately, the L1 (Ethereum in our case) reaches consensus on these state updates, but it does so without re-executing the transactions on the base layer. In other words, transactions on the L2 rollup are secured by Ethereum’s inherent security. There are two main types of Rollups, which differ by how proofs are created and verified:

• Optimistic Rollups. These assume transactions are valid unless challenged. They move computation offchain but post transaction data to Ethereum, allowing anyone to re-run the transactions off-chain and verify for themselves that the execution is correct. If any verifier detects malicious behavior, they can submit a fraud-proof on-chain, in which case the L1 acts as the final arbiter. For this reason, Optimistic Rollups require a dispute period (often of a few days).

• ZK Rollups. These rollups similarly execute contracts off-chain and submit validity proofs back when sending a state-update. Validity proofs are constructed using advanced cryptographic techniques known as (succinct) ZK Proofs. They can be efficiently verified on-chain directly, without posting the full transaction data or having a dispute period.

Optimistic and ZK Rollups have inherently different trade-offs. Optimistic rollups suffer from a dispute-period delay, making finality longer. They also require posting the transactions themselves on-chain, which negates some of the scalability benefits 2.

On the other hand, ZK Rollups require significant computation power (and time) to produce a proof, especially the closer you try to get to native EVM [10]. A related downside is that these rollups are much more complicated to build, resulting in large amounts of code. The likelihood of critical vulnerabilities with zkEVMs is therefore much higher, at least until they have been battle tested enough over time.

2.1.1 Optimistic Rollups in More Detail.
Optimistic rollups bundle multiple off-chain transactions and submit them to the L1 chain, reducing costs for users. They are termed “optimistic” because they assume transactions are valid unless proven otherwise. If a transaction is challenged, a fraud proof is computed. If proven fraudulent, penalties are applied. Today, optimistic rollups operate atop Ethereum, managed by Ethereum-based smart contracts. They process transactions off-chain but post data batches to an on-chain rollup contract. Ethereum ensures the correctness of rollup computations and handles data availability, making rollups more secure than standalone off-chain solutions or sidechains. They also create an inherent economic-security alignment between the two layers, as the L2 receives security while paying for incurred fees at the L1 level.

From an architectural perspective, optimistic rollups consist of the following:

• Transaction Execution. Users send transactions to operators or validators, who aggregate and compress them for the L1.

• Submitting to the L1. Operators bundle transactions and send them to the L1 using calldata.

• State Commitments. The rollup’s state is represented as a Merkle tree. Operators submit old and new state roots, ensuring the chain’s integrity.

• Fraud Proofs and Disputes. These allow anyone to challenge a transaction’s validity. If a challenge is valid (arbitrated by the L1), the fraudulent party is penalized.
Fraud Proofs play a vital role in optimistic rollups, and they are at the root of how we ensure that a rollup publishes a correct state update. Even in the face of malicious nodes trying to delay or tamper with transactions, the chain’s integrity is preserved as long as there’s a single honest node that observes state updates and checks that they are correct. In the context of rollups built on Ethereum, because the

actual data is posted onto Ethereum, anyone in the world canact as a verifier. Once an honest verifier detects an incorrect state update (e.g., by including a tampered-with transaction), it can submit a dispute, which initiates the fraud proof game: a multi-round interactive protocol. Here, the asserter (the node that produced the state update) and challenger (the verifier who issued a dispute) follow a protocol overseen by an L1 verifier contract to ascertain the honest party. The protocol proceeds recursively, each time dividing the computation into two equal parts. The challenger chooses one part to challenge each time. This process, termed the bisection protocol, persists until only one computational step is in question. Once the interactive protocol narrows down to a single instruction, it is the L1 contract’s turn to resolve the dispute by evaluating the instruction result as well as both the asserter’s and the challenger’s claims and their respective results to determine which one is correct.

2.2 Fully Homomorphic Encryption (FHE).
Fully Homomorphic Encryption (FHE) enables computations on ciphertexts that, when decrypted, match the results of those operations as if they were performed on the plaintext directly.

In practice, ever since the original scheme by Gentry [19], several FHE schemes have been developed, which are based on the original Learning With Errors (LWE) hardness problem, or related algebraic constructs such as its ring variant [37]. Our implementation utilizes a scheme called TFHE [14], but as the scheme itself does not really matter for the purpose of constructing an FHE-rollup, we describe FHE more generally below, in a black-box manner.
A generic FHE scheme can be denoted by the tuple of algorithms FHE = (Gen, Enc, Dec, Eval), as follows:

• Gen(1 𝜅 ). Given a security parameter 1 𝜅 , the algorithm outputs a pair of keys (𝑝𝑘, 𝑠𝑘) where 𝑝𝑘 is the public encryption key and 𝑠𝑘 is the secret decryption key. Define domains P for plaintexts, R for randomness, and C for ciphertexts, as well as the set of permissible functions F.

• Enc(𝑝𝑘,𝑚;𝑟). Given the public key 𝑝𝑘, a message 𝑚 ∈ P and randomness 𝑟 ∈ R, the encryption algorithm produces a ciphertext 𝑐 ∈ C such that

𝑐 = Enc𝑝𝑘 (𝑚;𝑟).

• Dec(𝑠𝑘, 𝑐). With the secret key 𝑠𝑘 and a ciphertext 𝑐, the decryption algorithm retrieves the original plaintext message 𝑚:

𝑚 = Dec𝑠𝑘 (𝑐).

• Eval(𝑝𝑘, 𝑓 , {𝑐𝑖 } 𝑛 𝑖=1 ). Given the public key 𝑝𝑘, a function 𝑓 ∈ F, and a set of ciphertexts {𝑐𝑖 } 𝑛 𝑖=1 , this algorithm produces a ciphertext 𝑐 ′ ∈ C such that:

Dec𝑠𝑘 (𝑐 ′ ) = 𝑓 ({Dec𝑠𝑘 (𝑐𝑖)}𝑛 𝑖=1 ).

_____________________________________ 

 2This is meant to be mitigated to an extent with EIP-4844 and Danksharding.

This implies the function 𝑓 is executed over encrypted data, and its result is
encrypted as 𝑐 ′.

3 Architecture

3.1 FHE Rollups: Optimistic or ZK-based?

As mentioned, ZK Rollups are inherently slower on the proving-side, but this provides benefits on the verification side. This problem compounds when considering ZK in the context of FHE, as we are now essentially combining two heavy-duty cryptographic techniques together. While an increasing body of work looks to address this research gap, current proposed solutions are orders of magnitude slower [11, 43]. For this reason, using an optimistic-based approach becomes a more natural choice for the encrypted domain.

3.2 Design Overview and Implementation Details

Our platform is built with modularity in mind. It includes the quintessential components of a rollup, encompassing a sequencer, prover, and a DA layer, whilst simultaneously interweaving new and specific components needed to support an FHE Rollup. Figure 4 illustrates the overall design. We detail the new FHE rollup-specific components below.

3.3 fheOS

The core FHE logic sits in our fheOS library. It is an encrypted computation library of pre-compiles for common encrypted opcodes, such as comparing two numbers and doing arithmetic operations like addition and multiplication. It gives Smart Contracts running on the network the ability to use FHE primitives within the contract. That means that dApps running on (or using) Fhenix will be able to integrate encrypted data in their smart contract logic. Developers will have the choice to decide what will be encrypted and what will remain plaintext. fheOS is another EVM-friendly wrapper around Zama’s tfhe-rs 3 FHE libraries, similar to fhEVM [1]. For implementation purposes and modularity, we opted to design our own version.

The fheOS library is the core engine of the Fhenix node; smart contracts utilizing encryption features will call fheOS precompiles for common FHE operations, and fheOS itself will be responsible for communication and authentication between the rollup and the Threshold Services Network (TSN, see Section 4) for decryption and re-encryption requests while proving that the decryption request is legitimate.

The fheOS library is designed to be injected as an extension into any existing flavor of EVM, meaning that it is fully EVM-compatible, thus keeping all the existing EVM functionality in place while boosting developers’ ability to explore new use cases.

 

Figure 1. Overview of an FHE Rollup architecture 

 3.4 go-tfhe

As we sought to extend the capabilities of Ethereum’s goethereum (geth), their predominant client written in Go, we encountered a challenge: the core FHE mathematical operations library, tfhe-rs, is written in Rust, necessitating communication via a foreign function interface (FFI). To address this, we developed go-fhe, which encompasses:

1. Go-based API. This component provides all essential interfaces for executing FHE mathematical operations using Go. It serves as the primary point of interaction for blockchain developers familiar
with Go.

2. Rust Wrapper for TFHE.rs. We created a specialized wrapper that adapts the TFHE.rs library functions for blockchain applications.

3. FFI Integration between Go API and the Rust Wrapper. To bridge the two languages, our interface employs cgo and extern “C” mechanisms. This facilitates bindings between Golang and Rust, aligning function calls, types, and naming conventions.

_________________________________________

3https://github.com/zama-ai/tfhe-rs

In general, go-tfhe acts as a modular extensionable lightweight bridge between tfhe-rs and the blockchain application.

4 Threshold Services Network (TSN) 

A key component in our design is the Threshold Services Network (TSN). This network is separate from the L1 or other rollup components and plays several key roles. In particular, this network is collectively entrusted with the secret-shared network key [𝑠𝑘], which can be used for threshold decryption. Our current implementation utilizes [15], which uses Shamir secret-sharing to split 𝑠𝑘 into 𝑛 shares, out of which 𝑡 + 1 shares are needed to reconstruct. In practice, each bit is separately shared, but we will ignore that distinction for the purpose of this paper.

4.1 Threshold Decryption and Re-encryption Occasionally, the network will need to decrypt certain results, or re-encrypt them to a designated user. The TSN is incharge of any such request coming from the rollup, and can accommodate it using the threshold decryption protocol of [15].

To illustrate why this is needed, consider the following two examples. First, imagine a private voting contract deployed on the rollup. When users vote for a certain candidate, they encrypt their votes, and the contract tallies these votes (all encrypted). At a certain point in time, a functionality in the contract should be able to decrypt the tally and announce the winner. This request is routed to the TSN, which decrypts it and returns the result to be stored in the contract’s state. This flow is illustrated in Figure 2, and a snippet from the Solidity contract code appears in Figure 3.

A similar example is that of a user who owns a NFT with private metadata only they can see. Such metadata is stored in the contract’s state under the network’s key. When a user tries to access that information, the contract should threshold re-encrypt it so only the designated user would be able to decrypt and get access to the underlying data.

4.2 Proofs on Secret Shared Data In certain cases, we might be able to leverage the TSN to assist in proving important statements about the data being encrypted [6]. For example, it is a well-established fact that ciphertexts need to be well-formed, otherwise trying to decrypt malformed ciphertexts could leak information about the secret key [27]. Similarly, in a multi-user system such as this, we need to ensure that a user is not (for example) sending a ciphertext they did not encrypt, and are asking the TSN to decrypt it for them. For these reasons, whenever a user submits an encrypted input, we need to ensure it has been properly encrypted and that the user knows the underlying plaintext.

Figure 2. Smart contract request to decrypt FHE-encrypted data on Fhenix

Currently, state of the art zero-knowledge proofs of knowledge (ZKPoK) over FHE ciphertexts [30] are still relatively expensive, and would add a non-trivial amount of overhead to each transaction. One alternative would be to have clients start by secret-sharing their secret inputs to the TSN using a verifiable secret-sharing protocol (VSS) [18]. After confirming that the inputs have been properly secret-shared, the network can jointly encrypt the inputs, for example, by the following simplified protocol sketch.

• Protocol ThresholdEncryption. Given a shared user message [𝑚], and a pre-processed randomness tuple ( [𝑟], 𝐸𝑛𝑐𝑝𝑘 (𝑟)) the parties output the FHE ciphertext 𝑐𝑡 := 𝐸𝑛𝑐𝑝𝑘 (𝑚).

• The servers run a VSS protocol with the client, receiving and validating the sharing of [𝑚].

• The servers jointly reconstruct 𝑐 := 𝑂𝑝𝑒𝑛( [𝑚] − [𝑟]) using an actively secure MPC protocol

• Output 𝑐𝑡 := 𝐸𝑛𝑐𝑝𝑘 (𝑟) + 𝐸𝑛𝑐𝑝𝑘 (𝑐).

* Note that since 𝑐𝑡 is a public value that is a result of secure sequential protocols, the parties can reach consensus over it to ensure correctness.

4.3 Random Beacon

A uniquely necessary functionality for smart contracts is that of producing randomness. Smart contracts are inherently deterministic, so they need an external source of randomness

Figure 3. Example FHE Voting Contract in Solidity

to enable non-deterministic functionalities. Examples of usecases that require such functionality are on-chain gaming (e.g., Poker, Casinos), NFT mints, and others.

Many distributed coin-tossing protocols exist. One such example that is well-fitted to our case is the one based on Verifiable Random Functions (VRF) [32] in [33].

4.4 Secure Shuffle

In many cases, we need a functionality dedicated to shuffling a vector of inputs. Many privacy-preserving computation techniques, including those that leverage FHE, can benefit from an efficient secure shuffle primitive. There are countless of examples where shuffling comes into play. One simple example is a game of poker – where securely and privately shuffling the deck is crucial.

More importantly, secure shuffles are a critical building block for Oblivious RAM (ORAM) [22], which are schemes that ensure that the memory is not just encrypted, but also that all accesses to it are kept private. Using an ORAM could be a building block into constructing a more efficient fhEVM that allows running FHE computations over programs directly, without first unrolling them into circuits [17, 44]. Other applications such as building private search engines [23], or building truly anonymous tokens in the account based model require a form of ORAM [25].

4.5 Security

It is important to note that the underlying confidentiality guarantees of the entire system are closely related to the trust assumptions of the TSN. Anything that relates to keeping the threshold decryption key safe, correctly decrypting/reencrypting ciphertexts, etc., is under the responsibility of the TSN.

Currently, the state-of-the-art protocols by [15] require the TSN to have at most 𝑡 < 𝑛 3 malicious corruptions for a fast and robust protocol, or 𝑡 < 𝑛 2 if we are willing to settle for security with abort.

4.5.1 Proposed Improvements (and Open Future Research). We put forward several open research areas we plan to explore regarding the TSN and its current threshold decryption protocol. We invite the community to join us in advancing these topics of interest:

• An actively secure threshold decryption protocol supporting a dishonest majority

• Cheater identification – for the protocol supporting up to 𝑡 < 𝑛 2 corruptions (or any dishonest majority protocol) we should be able to identify a cheating party (whether one that subverts the protocol, or one that aborts). Without it, there is no way to prevent Denialof-Service attacks on the TSN.

• Many validators (>1000) through sampling – currently the schemes do not scale well enough to many validators. This is especially true for the one limited to 𝑡 < 𝑛 3 , which has a computational complexity that increases exponentially with (𝑡, 𝑛). One solution to this problem is to focus on sampling a small committee for each epoch [20, 49].

• Share rotation and recovery. Many such schemes are already present in the literature (e.g., [31]).

5 Fraud Proofs 

The key to Optimistic Rollups lies in their fraud proofs mechanism. But how do we fit that mechanism, in particular Ethereum’s EVM, to work with smart contracts that execute FHE circuits over encrypted data?

First, observe that FHE, unlike other encrypted computation techniques such as MPC, natively allows anyone to verify that a computation was done correctly, without breaking the privacy guarantees. This is because an adversary holding the encrypted inputs and outputs learns nothing about the underlying encrypted data (if this were not the case, then the encryption scheme would not be semantically secure).

 

This makes verifying FHE computations compatible with the idea of Optimistic Rollups, at least in theory. As mentioned earlier, Optimistic Rollups are based on posting the full transaction data on the L1 (or some other data availability service), alongside the output. In this case, both are encrypted. Just like with plaintext data, any off-chain verifier could take the encrypted transaction data, re-execute the transactions, and make sure that they receive the same encrypted output. If this is not the case, then an honest verifier could submit a dispute and start the arbitration process with the L1.

However, the whole fraud proving mechanism is rooted on the L1’s ability to determine unequivocally whether the L2 node that posted the state update or the disputing verifier (i.e., the challenger) is cheating. To do this, the L1 needs to be able to run a single computational step of the underlying computation. Since we are interested in Ethereum being the L1, this poses a question: How can Ethereum, or any traditional EVM chain, validate execution on FHE primitives without inherent support for FHE operations?

The answer resides in Arbitrum’s Nitro fraud prover 4 , which we repurpose to our needs, allowing us to compile all our FHE logic to WebAssembly and execute the entire proving round in a WASM runtime (WAVM), on-chain on Ethereum, instead on native EVM. Since the underlying FHE code can be compiled to WASM as well, no changes are needed to the L1 itself.

Addressing performance concerns, it is rational to assume that if FHE computations are inherently intensive, simulating them in a WASM runtime atop EVM might incur significant performance penalties. While this is a valid concern, it is important to remember that initiating these computations is only mandatory in a dispute scenario, and real-time speed is not an absolute necessity given a sufficient dispute window. Considering that the standard practice allocates approximately seven days for it, we estimate that this is more than sufficient time to settle any such disputes. However, we did not empirically validate this hypothesis, and we note that doing so in the future is important.

5.1 Implementation details

During the course of developing the proof-of-concept FHE fraud prover, we had to overcome several hurdles, which we note here for completeness.

First, To run go-tfhe as a part of the fraud proof mechanism, it was necessary to adapt the code for execution in WebAssembly (WASM). Given our reliance on FHE code written in Rust, while much of blockchain code is traditionally in Golang, we faced challenges in native compilation to a unified WASM module – the default bindings between Rust and Golang use cgo, which is not compatible with WASM. To address this, we crafted bindings in WASM

Figure 4. Fraud proof engine for FHE instructions 

to bridge between Golang, using the mainline Golang compiler’s external function directives, and Rust, creating a dedicated Rust file as the primary WASM build target, eventually linking both using wasm-merge for a cohesive .wasm output.

Furthermore, we had to modify tfhe-rs as well. At the time of this writing, tfhe-rs supports compilation and execution of WASM in browsers only. In our case – smart contracts running atop of a blockchain – the interfaces available differ from those of browser contexts. Notably, some API calls, such as accessing operating-system capabilities or multithreading, are not accessible. For TFHE.rs to be compatible with a smart contract context, two primary modifications were made:

1. Disabling Multithreading. Given that most smart contracts do not accommodate multithreading or concurrency, the code was adjusted to operate in a single-threaded and deterministic manner.

2. Custom Random Number Provider Integration. The initial version of tfhe.rs depended on predefined random number providers or seeders. The only available seeders were contingent on the operating system’s ability to generate random numbers. We introduced a custom seeder managed by the library user. This seeder receives an input seed and passes it into a ChaCha20-based seeded Pseudorandom Number Generator (PRNG) provider. This modification negates the need for non-deterministic random numbers in the FHE implementation, facilitating external validation by replicating computations using consistent inputs from blockchain data and state.

 

We note that based on our benchmarks of tfhe-rs running in this context show an order of magntitude performance degradation when using wasmer/cranelift and 8x when using wasmer/llvm for add operations (tested on i9-13900K, 128 GB RAM, wasmer 4.0). We note that the Arbitrum fraud proof engine makes use of software floating points which should impact performance further, but we did not complete benchmark tests as of writing this paper.

6 Conclusion 

In this paper, we presented the first proposed construct of an FHE Rollup, a novel solution that adds confidentiality to Ethereum and other EVM chains. Our approach leverages the power of FHE to enable encrypted EVM computations, revolutionizing the way transactions are executed and confidential data is handled on-chain. Unlike recent works [1, 16, 39], our approach uses a L2 Rollup structure to avoid replicating the cost of FHE computations across all nodes, which leads to a much more efficient and practical solution.

Our approach focuses on Ethereum and the EVM, but is also of independent value as a system that enables verifiable FHE [43]. Additionally, we also laid out the architecture of our proposed FHE rollup system, including its components and layers, and have proposed and implemented a proof-ofconcept of a fraud-proof solution that requires no changes whatsoever to Ethereum. Our work contributes to the development of a new wave of privacy-centric decentralized applications, enhancing user confidence, expanding potential use-cases, and increasing the overall security and utility of the Ethereum network.

References 

[1] Zama AI. 2023. FHEVM Whitepaper. https://github.com/zama-ai/ fhevm/blob/main/fhevm-whitepaper.pdf. Accessed: 27-10-2023.

[2] Aritra Banerjee, Michael Clear, and Hitesh Tewari. 2021. zkhawk: Practical private smart contracts from mpc-based hawk. In 2021 3rd Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS). IEEE, 245–248.

[3] Carsten Baum, James Hsin-yu Chiang, Bernardo David, and Tore Kasper Frederiksen. 2022. Eagle: Efficient Privacy Preserving Smart Contracts. Cryptology ePrint Archive (2022).

[4] Carsten Baum, Bernardo David, and Rafael Dowsley. 2020. Insured MPC: Efficient secure computation with financial penalties. In Financial Cryptography and Data Security: 24th International Conference, FC 2020, Kota Kinabalu, Malaysia, February 10–14, 2020 Revised Selected Papers 24. Springer, 404–420.

[5] Michael Ben-Or, Shafi Goldwasser, and Avi Wigderson. 1988. Completeness theorems for non-cryptographic fault-tolerant distributed computation. In Proceedings of the twentieth annual ACM symposium on Theory of computing. ACM, 1–10.

[6] Dan Boneh, Elette Boyle, Henry Corrigan-Gibbs, Niv Gilboa, and Yuval Ishai. 2019. Zero-knowledge proofs on secret-shared data via fully linear PCPs. In Annual International Cryptology Conference. Springer, 67–97.

[7] Pietro Borrello, Andreas Kogler, Martin Schwarzl, Moritz Lipp, Daniel Gruss, and Michael Schwarz. 2022. {ÆPIC} Leak: Architecturally Leaking Uninitialized Data from the Microarchitecture. In 31st USENIX Security Symposium (USENIX Security 22). 3917–3934.

[8] Sean Bowe, Alessandro Chiesa, Matthew Green, Ian Miers, Pratyush Mishra, and Howard Wu. 2020. Zexe: Enabling decentralized private computation. In 2020 IEEE Symposium on Security and Privacy (SP). IEEE, 947–964.

[9] Benedikt Bünz, Shashank Agrawal, Mahdi Zamani, and Dan Boneh. 2020. Zether: Towards privacy in a smart contract world. In Financial Cryptography and Data Security: 24th International Conference, FC 2020, Kota Kinabalu, Malaysia, February 10–14, 2020 Revised Selected Papers. Springer, 423–443.

[10] Vitalik Buterin. 2022. zkEVM and zkRollup. https://vitalik.ca/general/ 2022/08/04/zkevm.html. Accessed: dd-mm-yyyy.

[11] Sylvain Chatel, Christian Mouchet, Ali Utkan Sahin, Apostolos Pyrgelis, Carmela Troncoso, and Jean-Pierre Hubaux. 2023. PELTA– Shielding Multiparty-FHE against Malicious Adversaries. Cryptology ePrint Archive (2023).

[12] Guoxing Chen, Sanchuan Chen, Yuan Xiao, Yinqian Zhang, Zhiqiang Lin, and Ten H Lai. 2019. Sgxpectre: Stealing intel secrets from sgx enclaves via speculative execution. In 2019 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 142–157.

[13] Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah Johnson, Ari Juels, Andrew Miller, and Dawn Song. 2019. Ekiden: A platform for confidentiality-preserving, trustworthy, and performant smart contracts. In 2019 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 185–200.

[14] Ilaria Chillotti, Nicolas Gama, Mariya Georgieva, and Malika Izabachène. 2020. TFHE: fast fully homomorphic encryption over the torus. Journal of Cryptology 33, 1 (2020), 34–91.

[15] Morten Dahl, Daniel Demmler, Sarah El Kazdadi, Arthur Meyre, JeanBaptiste Orfila, Dragos Rotaru, Nigel P Smart, Samuel Tap, and Michael Walter. 2023. Noah’s Ark: Efficient Threshold-FHE Using Noise Flooding. Cryptology ePrint Archive (2023).

[16] Wei Dai. 2022. Pesca: A privacy-enhancing smart-contract architecture. Cryptology ePrint Archive (2022).

[17] Jack Doerner and Abhi Shelat. 2017. Scaling ORAM for secure computation. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. 523–535.

[18] Paul Feldman. 1987. A practical scheme for non-interactive verifiable secret sharing. In 28th Annual Symposium on Foundations of Computer Science (sfcs 1987). IEEE, 427–438.

[19] Craig Gentry. 2009. Fully homomorphic encryption using ideal lattices. In Proceedings of the forty-first annual ACM symposium on Theory of computing. 169–178.

[20] Craig Gentry, Shai Halevi, Hugo Krawczyk, Bernardo Magri, Jesper Buus Nielsen, Tal Rabin, and Sophia Yakoubov. 2021. YOSO: You Only Speak Once: Secure MPC with Stateless Ephemeral Roles. In Advances in Cryptology–CRYPTO 2021: 41st Annual International Cryptology Conference, CRYPTO 2021, Virtual Event, August 16–20, 2021, Proceedings, Part II. Springer, 64–93.

[21] Oded Goldreich, Silvio Micali, and Avi Wigderson. 1987. How to play any mental game. Proceedings of the nineteenth annual ACM symposium on Theory of computing (1987), 218–229.

[22] Oded Goldreich and Rafail Ostrovsky. 1996. Software protection and simulation on oblivious RAMs. Journal of the ACM (JACM) 43, 3 (1996), 431–473.

[23] Alexandra Henzinger, Emma Dauterman, Henry Corrigan-Gibbs, and Nickolai Zeldovich. 2023. Private web search with Tiptoe. Cryptology ePrint Archive (2023).

[24] Aleo Systems Inc. 2022. Aleo: A Zero-Knowledge Operating System. https://aleo.org/. Accessed: dd-mm-yyyy.

[25] Nerla Jean-Louis, Yunqi Li, Yan Ji, Harjasleen Malvai, Thomas Yurek, Sylvain Bellemare, and Andrew Miller. 2023. SGXonerated: Finding (and Partially Fixing) Privacy Flaws in TEE-based Smart Contract Platforms Without Breaking the TEE. Cryptology ePrint Archive (2023).

[26] Harry Kalodner, Steven Goldfeder, Xiaoqi Chen, S Matthew Weinberg, and Edward W Felten. 2018. Arbitrum: Scalable, private smart contracts. In 27th USENIX Security Symposium (USENIX Security 18). USENIX Association, 1353–1370. https://www.usenix.org/conference/ usenixsecurity18/presentation/kalodner Accessed: dd-mm-yyyy.

[27] Mehmet Kiraz and Berry Schoenmakers. 2006. A protocol issue for the malicious case of Yaoâs garbled circuit construction. In 27th Symposium on Information Theory in the Benelux, Vol. 29. 283–290.

[28] Ahmed Kosba, Andrew Miller, Elaine Shi, Zikai Wen, and Charalampos Papamanthou. 2016. Hawk: The blockchain model of cryptography and privacy-preserving smart contracts. In 2016 IEEE symposium on security and privacy (SP). IEEE, 839–858.

[29] Rujia Li, Qin Wang, Qi Wang, David Galindo, and Mark Ryan. 2022. SoK: TEE-assisted confidential smart contract. arXiv preprint arXiv:2203.08548 (2022).

[30] Benoit Libert. 2023. Vector Commitments With Short Proofs of Smallness. Cryptology ePrint Archive (2023).

[31] Sai Krishna Deepak Maram, Fan Zhang, Lun Wang, Andrew Low, Yupeng Zhang, Ari Juels, and Dawn Song. 2019. CHURP: dynamiccommittee proactive secret sharing. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security. 2369– 2386.

[32] Silvio Micali, Michael Rabin, and Salil Vadhan. 1999. Verifiable random functions. In 40th annual symposium on foundations of computer science (cat. No. 99CB37039). IEEE, 120–130.

[33] League of Entropy. 2022. drand: Distributed Randomness Beacon. https://drand.love/. Accessed: 27-10-2023.

[34] Bryan Parno, Jon Howell, Craig Gentry, and Mariana Raykova. 2013. Pinocchio: Nearly practical verifiable computation. In 2013 IEEE Symposium on Security and Privacy. IEEE, 238–252.

[35] Optimism PBC. 2022. Optimism: Optimistic Ethereum. https:// optimism.io/. Accessed: 27-10-2023.

[36] Joseph Poon and Vitalik Buterin. 2017. Plasma: Scalable Autonomous Smart Contracts. https://plasma.io/plasma.pdf. Accessed: dd-mmyyyy.

[37] Oded Regev. 2009. On lattices, learning with errors, random linear codes, and cryptography. Journal of the ACM (JACM) 56, 6 (2009), 1–40.

[38] SCRT. 2021. The Secret Network Graypaper. https://scrt.network/ graypaper.

[39] Ravital Solomon and Ghada Almashaqbeh. 2021. smartfhe: Privacypreserving smart contracts from fully homomorphic encryption. Cryptology ePrint Archive (2021).

[40] Samuel Steffen, Benjamin Bichsel, Roger Baumgartner, and Martin Vechev. 2022. Zeestar: Private smart contracts by homomorphic encryption and zero-knowledge proofs. In 2022 IEEE Symposium on Security and Privacy (SP). IEEE, 179–197.

[41] Samuel Steffen, Benjamin Bichsel, Mario Gersbach, Noa Melchior, Petar Tsankov, and Martin Vechev. 2019. zkay: Specifying and enforcing data privacy in smart contracts. In Proceedings of the 2019 ACM SIGSAC conference on computer and communications security. 1759–1776.

[42] Stephan Van Schaik, Andrew Kwong, Daniel Genkin, and Yuval Yarom. 2020. SGAxe: How SGX fails in practice. https://sgaxe.com/files/ SGAxe.pdf

[43] Alexander Viand, Christian Knabenhans, and Anwar Hithnawi. 2023. Verifiable fully homomorphic encryption. arXiv preprint arXiv:2301.07041 (2023).

[44] Xiao Wang, Hubert Chan, and Elaine Shi. 2015. Circuit oram: On tightness of the goldreich-ostrovsky lower bound. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. 850–861.

[45] Zachary J Williamson. 2018. The aztec protocol. URL: https://github. com/AztecProtocol/AZTEC (2018).

[46] Andrew C Yao. 1986. How to generate and exchange secrets. In 27th Annual Symposium on Foundations of Computer Science (sfcs 1986). IEEE, 162–167.

[47] Hang Yin, Shunfan Zhou, and Jun Jiang. 2019. Phala network: A confidential smart contract network based on polkadot.

[48] Guy Zyskind, Oz Nathan, et al. 2015. Decentralizing privacy: Using blockchain to protect personal data. In 2015 IEEE Security and Privacy Workshops. IEEE, 180–184.

[49] Guy Zyskind, Oz Nathan, and Alex Pentland. 2015. Enigma: Decentralized computation platform with guaranteed privacy. arXiv preprint arXiv:1506.03471 (2015).

Introducing FHE-Rollups: Scaling Confidential Smart Contracts on Ethereum and Beyond

Date: 16-11-23


Introducing FHE-Rollups: Scaling Confidential Smart Contracts on Ethereum and Beyond

This article will provide a simplified overview of our technical whitepaper’s first iteration. Given that our work concerns cutting-edge technical research, we will be continuously updating it to incorporate our latest breakthroughs and technological advancements. This makes it a rolling whitepaper of sorts.

The technical white-paper can be viewed here.

 

One of the central challenges for Ethereum and other EVM (Ethereum Virtual Machine) networks is their inherent public transparency, which limits widespread adoption by hindering use cases that require privacy. Our whitepaper—and this accompanying article—introduces Fully Homomorphic Encryption (FHE) Rollups, an innovative approach to infusing EVM-based networks with confidentiality.

 

The significance of FHE Rollups cannot be overstated, especially because they unlock the potential for sensitive and private data to be processed securely on Ethereum and other EVM networks. Such advancement means that institutions can conduct private on-chain transactions, and it opens the door for additional applications like confidential trustless gaming, private voting, and more.

 

What sets FHE Rollups apart is that they allow developers to build confidential smart contracts using an optimistic rollup structure. Developers wishing to use our FHE Rollup will benefit from both the scalability of a rollup and the ability to introduce encryption into their applications, using familiar EVM programming languages that are part of our FHE libraries.

While our whitepaper is rather technical, this article aims to be a companion that provides a simplified overview, covering topics such as:

  • A quick review of Fully Homomorphic Encryption

  • The need for confidential smart contracts

  • L2 rollups

  • Our design choice & implementation procedures

We demonstrate through a proof-of-concept (PoC) implementation, that an optimistic FHE rollup can be built on top of Ethereum without any changes to the base layer.

FHE Encryption – A Quick Primer

 

In a recent blog post, we covered Fully Homomorphic Encryption (FHE), a cutting-edge technology that allows computation over encrypted data. Research into FHE began in the late 1970s, but only recently has computing power and technology advanced enough to bring it to fruition.

 

The computation of encrypted data has far-reaching implications across many industries but is particularly important for blockchains where data is publicly visible. By encrypting data on the blockchain and being able to compute upon it, use cases revolving around sensitive data become possible. This could include trustless gaming, private voting, and privacy-preserving AI, but we expect the full range of possibilities to be much greater. It also includes institutional use cases, such as payments, which would otherwise not be possible without sacrificing privacy.

 

Implementing FHE on the blockchain, especially on the Ethereum Virtual Machine (EVM), brings privacy to the blockchain and is a critical advancement for the space.

 

The Move Towards Rollups

 

Ethereum and EVM-compatible networks are leading the blockchain race but suffer from scalability limitations. A Layer 2 (L2) architecture has been proposed by leaders in the space (such as Vitalik Buterin) as Ethereum’s primary proposed scaling solution.

 

While Ethereum typically works by handling both execution and consensus itself, an L2 handles execution off of Ethereum. Transactions are then “rolled up” into one big update that is periodically sent to Ethereum for settlement. This is significantly more efficient given that smart contract execution is the heavy-duty part of block validation, but security is maintained as these executions are then sent to Ethereum for validator consensus.

 

There are two primary architectures for L2s:

  1. Optimistic Rollups: Transactions are assumed valid unless otherwise challenged. They post all transaction data to Ethereum, allowing anyone to verify for themselves that the off-chain execution was done correctly. If any verifier detects malicious behavior, they can submit a fraud-proof on-chain which instigates a dispute process.

  2. Zero-Knowledge (ZK) Rollups: Rather than post transaction data on-chain, they submit cryptographic proofs. These proofs are constructed using advanced cryptographic techniques known as ZK Proofs. They can be efficiently verified on-chain directly, without posting the full transaction data or having a dispute period.

 

Optimistic rollups require a dispute period but are much easier to implement than ZK Rollups. The reason for this is that ZK Rollups require significant computational power (and time) to create ZK Proofs, and are also much more complex to build. This also provides room for error in the code, which should be minimized.

 

If we were to implement our platform as a ZK Rollup, we would be combining two heavy-duty cryptographic techniques together. While research in this space may advance over the coming years, at the present moment the implementation of FHE through an optimistic approach is much better. A ZK approach would be orders of magnitude less efficient.

 

Therefore, we have chosen to implement the FHE Rollup as an optimistic rollup.

 

How does this work?

 

At a high level, we ensure data integrity by running a variation of Arbitrum Nitro’s fraud prover, which can do fraud proofs over the WebAssembly Virtual Machine (WASM). This has allowed us to compile FHE logic to WebAssembly and run it in a secure way on WASM code, rather than on the native Ethereum Virtual Machine (EVM) itself. Without using Arbitrum Nitro’s fraud prover, there would be challenges given that Ethereum does not natively support FHE operations.

Existing Solutions

 

The FHE Rollup is not the first proposed confidential smart contract platform.

 

Some existing solutions include:

 

  1. Trusted Execution Environments (TEEs): transactions are decrypted and computed upon within a secure environment. TEEs are already in production and considered quite efficient, but they require reliance upon the environment’s security and are susceptible to vulnerabilities such as side-channel attacks.

  2. Secure MPC: similar in nature to the FHE Rollup but use linear secret-sharing and garbled circuits rather than FHE technology. A drawback to this approach is that it is challenging to manage as data loads increase. it is also not suitable to a rollup architecture.

  3. Zero-Knowledge (ZK): ZK techniques are more suited for verifying computations, instead than actually running confidential smart contracts.

 

Our FHE Rollup PoC is instead the first solution that operates fully and natively as an L2. This means that we have built a platform whereby FHE technology is built directly into the network, rather than being an external technology that comes with associated vulnerabilities and/or limitations.

Below we’ll provide an overview of our design that enables this.

 

Design Overview

 

Our platform aims to be modular which means it separates different components of the blockchain. In particular, it separates the Sequencer, Validator, and Data Availability (DA) layers. Ethereum handles the data settlement and DA component, while Fhenix handles the Sequencer (execution) and Validator (transaction validation).

 

This separation of components allows FHE Rollups to execute more efficiently while still having the necessary access to Ethereum’s DA.

 

The core FHE logic sits in our fheOS library. It is a programming library that contains everything that a developer needs to begin implementing FHE logic into their smart contracts. There are other components to fheOS, such as the TFHE-rs, which is a full FHE library built by our partner Zama. These technical specifications are beyond the scope of this article but we will cover them in future pieces.

A key technology used is our Threshold Services Network (TSN), useful for tasks such as decrypting data when necessary. An example of decryption being necessary could include announcing the outcome of a vote, which requires tallying votes. The TSN would decrypt the data and then return it. More information on the TSN can be found in the full whitepaper.

Bringing Things Together

As a summary, the first iteration of our whitepaper has proposed the construct of an FHE Rollup: a novel solution that adds confidentiality to Ethereum and other EVM chains.

Developers can use this to build Layer 2s with built-in encryption capabilities, putting them at an advantage over rival networks. This is also simple to implement, as developers can use familiar EVM programming languages, rather than being required to learn an entirely new language. We essentially make it easy for anyone to benefit from our cutting-edge FHE research.

We chose an optimistic oracle architecture as it best suits our needs, and avoids the cost of replicating expensive FHE computations across all Ethereum nodes. At the present moment, implementing FHE with a ZK architecture is not a realistic approach, but we are also closely monitoring and progressing in this realm as well.

This will help usher in a new era of confidential computing that will unlock new Web3 use cases and help to drive blockchain adoption.

The full white-paper can be viewed here.

We also recommend visiting our website at fhenix.io to learn more.

Fhenix Rising: The First Fully Homomorphic Encryption-Powered L2 to Bring End-to-End Encryption for Web3

Date: 22-10-23


Fhenix Rising: The First Fully Homomorphic Encryption-Powered L2 to Bring End-to-End Encryption for Web3

Fhenix leverages cutting-edge Fully Homomorphic Encryption (FHE) technology to introduce for the first time native encryption capabilities into EVM smart contracts, enabling computation over encrypted data. This enhances data security and privacy to unparalleled levels, unlocking a multitude of innovative Web3 applications.

Introduction

It’s become increasingly clear that Web3 is the future, but blockchain’s innate transparency presents challenges that inhibit the industry’s growth trajectory. This is because a growing number of Web3 use cases revolve around sensitive data, rendering the full openness of public blockchains problematic.

This is for two main reasons:

  1. Exclusion: Payments, voting, medical records, decentralized identity, and countless other use cases require confidentiality. As the scope of blockchain grows, the absence of robust encryption solutions could either push these applications off-chain or force them to compromise on data confidentiality.
  2. Security: On-chain data transparency makes it much simpler for malicious parties to identify and target users. This has led to billions lost through phishing attacks and other exploitative tactics like MEV extraction.

While in Web2 space data encryption is a well-established and required standard, it seems that the ‘lack-of-encryption’ for commercially sensitive and personal data in Web3 is still a growing and evolving threat. To scale the industry forward, privacy must be an integral part of blockchain, meaning that data encryption and computation capabilities should be key features of all blockchains.

To address this challenge we need to bring developers the infrastructure and tools that allow easy integration of robust data encryption capabilities in the applications that are essential for this space to grow.

Fhenix is rising to this challenge.

Fhenix is building the first confidential smart contract platform using fully homomorphic encryption (FHE). FHE is a novel cryptographic scheme that enables direct computation over encrypted data without ever revealing the underlying data. Fhenix’s goal is to advance application development in the blockchain ecosystem by bringing data encryption and encrypted data computation to smart contracts, transactions, and on-chain assets for the first time.

By leveraging the power of FHE, Fhenix redefines how sensitive data is being managed in the blockchain ecosystem, envisioning a future where privacy and decentralization are not at odds, but rather, complementary aspects of a secure digital economy.

Fully Homomorphic Encryption

FHE is considered the holy grail of cryptography, as it enables direct computation over encrypted data while never revealing the data to the server, or in the context of blockchains — to validators or sequencers. This is all groundbreaking, with recent breakthroughs paving the way for Homomorphic Encryption data processing to arrive at last on the blockchain.

This means that Fhenix now enables a wide array of versatile use cases such as:

    • Trustless Gaming: Every game that requires players to hide their information from other players, like on-chain casino gaming, where you need to hide information between opponents or the dealer, while still allowing computation on the data.
    • Private Voting: Both on-chain and off-chain voting mechanisms can operate with fully encrypted variables, ensuring confidentiality without sacrificing trustworthiness.
    • Privacy-Preserving AI: The ability to compute encrypted data opens the door for on-chain artificial intelligence applications, thereby expanding the range of possible use cases exponentially.
    • Confidential Token Transfers: P2P payments, commercial transactions, and other sensitive transfers can be made private, yet auditable.

These are all multi-billion dollar industries growing at a rapid pace, but applicability also extends to areas such as blind auctions, MEV protection, account abstraction, and confidential DAOs. We are also merely at the beginning of what’s truly possible, with many use cases undiscovered.

This is all possible due to fhEVM, which we’ll cover next.

The Gold Standard: fhEVM

fhEVM is a set of extensions for the Ethereum Virtual Machine (EVM) that allows Solidity developers to seamlessly create encrypted smart contracts without any cryptographic expertise. Solidity is the most popular Web3 language to date and comes with an extensive suite of developer tools and libraries, making fhEVM extremely easy to begin working with.

This is important, as blockchains that rely upon entirely novel programming languages have significant costs associated with attracting and training developers to begin using their unique language. In contrast, fhEVM taps into the expansive EVM community and enables developers to easily begin deploying new, innovative projects.

Fhenix also has a modular, extension-like design which means that its ability to compute encrypted data can be integrated across all blockchain layers, enabling the easy development of confidential smart contracts on public blockchains. For example, developers can now build applications around encrypted data, such as decentralized email services or private voting.

This comes in the form of the Fhenix SDK which can now be used by developers to add encryption capabilities to their existing products, seamlessly, without any changes to their existing smart contracts.

Fhenix’s limited access devnet was deployed in July 2023, and provides an approachable FHE playground where the fhEVM is already functional and in use. To apply for early access click here.

The Confidential Compute Constellation: Blockchain’s Encryption-First Future

While public blockchains are pseudonymous in nature, this is insufficient for many blockchain applications and will become increasingly easy to correlate on-chain activity with real-world identities. Also, It is important to understand that confidentiality is not a “one-size-fits-all” issue solved by one technology alone. Like in blockchains, there are multiple tradeoffs between confidentiality technologies, such as security, scalability, decentralization, complexity and cost.

This insight led to the formation of the Confidential Compute Constellation: a collective of interconnected confidential solutions serving as an encryption hub for Web 3.0.

The Confidential Computing Constellation starts by combining Secret Network’s battle-tested platform, experience and community with the novel Fully Homomorphic Encryption technology that Fhenix introduced into a full-fledged smart contract platform.

The goal of the Constellation is to combine a wide range of confidential-computing technologies and solutions to create a single hub for privacy and confidentiality on Web3, offering confidential computing applications on member networks and providing privacy as a service to the EVM ecosystem and beyond.

Encryption Allstars: The Team Behind Fhenix

Fhenix was founded by Guy Zyskind, the Founder of Secret and is led by Guy Itzhaki, a former Director at the Homomorphic Encryption & Blockchain Group at Intel.

Forged by a partnership with Zama, a market leader in fully homomorphic encryption technologies, Fhenix team is composed of the world-leading experts in private computation solutions.

“Fhenix addresses a huge problem in the Ethereum ecosystem: a lack of encryption for commercially sensitive data,” said Guy Zyskind, Fhenix and Secret Founder. “Fhenix gives users the confidence to put sensitive data on public blockchains while also giving developers the tools to compute and transform that data for the first time.”

Fhenix recently raised a $7.5M Seed Round co-led by Multicoin Capital and Collider Ventures, with collaboration from Node Capital, Bankless, HackVC, TaneLabs, Hashkey and Metaplanet. The funds will be used to bring the Fhenix Network into public testnet early next year and to support ecosystem application development.

Blockchain’s Renaissance: Upcoming Public Testnet

FHENIX’s public testnet titled Renaissance will be open for participation in Q1 of 2024, inviting developers to familiarize themselves with the fhEVM environment and build novel applications. This is particularly exciting for developers keen on being first-movers in an emerging field of blockchain, and more details will be shared in the coming weeks.

We invite those interested to apply for early testnet access here.

Join our social media channels to get all the updates!

Fhenix: Programable. Scalable. Encrypted.

The Holy Grail of Encryption: The Rise of FHE Technology

Date: 22-10-23


The Holy Grail of Encryption: The Rise of FHE Technology

Fully Homomorphic Encryption, once considered impossible by leading cryptographic experts, is finally here. It is encryption’s unicorn technology, allowing for the arbitrary computation of encrypted data and in turn ushering in the new era of confidential computing.

For years, cryptography researchers have battled with the fact that while data can be encrypted in transit, actual data processing requires that data be first unencrypted. These additional steps present data vulnerabilities and have contributed to major data breaches impacting hundreds of millions.

Groundbreaking research from leading academic cryptographers, alongside advances in computing power, have at long last brought us Fully Homomorphic Encryption: the ability to conduct secure operations on encrypted data.

In this post, we’ll cover:

  • What is Fully Homomorphic Encryption?
  • How does it work?
  • And, what can it do?

Let’s dive in.

What is FHE?

In 1978, researchers first examined the issues surrounding modifying computer hardware in order to perform secure operations on encrypted data. For the following 30 years little progress was made, primarily due to insufficient computing power required for such complex computations.

In 2009, progress resumed when a possible FHE scheme was proposed by Craig Gentry. This coincided with significant increases in computing power that fueled early progress in artificial intelligence. Further progress has since been made, including a groundbreaking research paper in 2013 that sidestepped FHE’s computationally expensive relinearization step, have helped lead us to the present day.

At long last, the “once mythical” technology known as Fully Homomorphic Encryption has arrived, allowing us to conduct confidential computing. At its core, confidential computing introduces a totally new paradigm of securing data, and performing secure computations.

So what does Fully Homomorphic Encryption actually mean? Let’s consider each term separately:

  1. Fully: In the context of FHE, fully means that arbitrary operations such as addition and multiplication are supported.
  2. Homomorphic: The ability to allow computations on encrypted data without first decrypting it.
  3. Encryption: The process of converting information into code that prevents unauthorized access.

Taken together, FHE refers to the ability to perform binary operations on encrypted data without decrypting the data — ever. Kind of like magic.

Binary operations refer to mathematical operations that take two inputs and produce a single output — such as addition, multiplication, subtraction, and division. Blockchains, at their core, primarily deal with integer operations, meaning that this is tremendously valuable for the industry as a whole.

FHE’s Significance to Blockchain

The status quo requires data to first be decrypted in order to run computations on it. It must then be encrypted again, and later decrypted, with each step presenting new opportunities for the data to be exploited.

This has contributed to major data exploits in nearly every industry, impacting hundreds of millions and the biggest firms including EquifaxMarriot InternationalEasyJet, and countless more. Each exploit of sensitive data costs billions to rectify, and exposes the personal data of millions. FHE’s ability to compute encrypted data has far reaching ramifications for nearly every industry and will become the new standard for data security.

How can this be implemented?

While future content will cover FHE at a technical level, here we will provide a simple overview in regards to how FHE would integrate in blockchain. Keep in mind that FHE has far reaching implications beyond just the blockchain industry — but this space is our focus.

As mentioned, blockchains primarily deal with integer operations, such as managing smart contract “states”, updating block indices, or processing cryptocurrency transactions. This means that applying FHE onto encrypted blockchain data is extremely powerful.

That being said, FHE is niche and very complex, so the barrier to entry is high. That’s why we’ve partnered with Zama, which built the fhEVM.

fhEVM is a set of extensions for the Ethereum Virtual Machine (EVM) that allows any Solidity developers to integrate FHE into their workflow. This enables the creation of encrypted smart contracts without any FHE expertise and means that developers can benefit from Solidity’s extensive suite of developer tooling.

fhEVM is used for writing the application itself, but we also have fhenix.js which allows developers to create the frontend using Javascript.

FHE vs. ZK

Zero-knowledge (ZK) technology has been widely covered in recent times, often heralded as the future of blockchain privacy.

It’s important to note some distinctions from FHE:

  • Encryption computation: ZK cannot compute over encrypted data from multiple users (which would be the case for private ERC-20 tokens) without sacrificing security. FHE can do so, which makes it more composable throughout blockchain. ZK technology often requires custom integrations for new networks and assets.
  • Scalability: ZK is considered more scaleable than FHE, at least at the present moment. Technological developments will scale FHE over the coming years.
  • Complex calculations: FHE can handle complex calculations on encrypted data, suitable for needs such as machine learning, secure MPC, and fully private computations. In contrast, ZK Proofs are typically users for simpler tasks such as proving a value without revealing it.
  • Universal Applicability: while ZK Proofs are great for specific use-cases like identity verification, authentification, and scalability, FHE can be applied to a broader range of applications. This includes confidential data processing, secure cloud computing, and privacy-preserving AI applications.

We believe that both have their place in blockchain. However, while ZK technology is more mature than FHE at the present moment, we believe that FHE will ultimately emerge as the most suitable privacy-preserving solution.

For more information, we covered the fhEVM in greater depth in our last blog post.

Conclusion

FHE represents a breakthrough for confidential computing

The above article aimed to provide the reader with a fundamental understanding of FHE, including:

  • how it came to be,
  • how it works, and
  • its implications for blockchain as a whole.

No longer must data be unencrypted in order to have computations run — it can now remain encrypted the entire journey, vastly reducing the number of attack vectors. This also means that many institutional blockchain use-cases are now feasible, as data privacy is a key consideration for them.

Future content of ours will cover FHE at a more granular level. In the meantime, if you are interested in getting started, you can learn more about the process here.

Join our social media channels to get all the updates!

FHENIX: Programmable. Scalable. Encrypted.