This article dives into how fhEVMs utilize fully homomorphic encryption to enhance confidentiality in EVM-compatible blockchains, allowing for encrypted transactions and state changes without sacrificing the decentralization and trustlessness inherent to blockchain technology, and introduces the current fhEVMs that exist in the market today.
Special thanks to Jason Delabays (Blockchain Ecosystem Lead @ Zama) & Taproot (Dev Rel @ Fhenix) for contributing to this article by helping to clarify my questions. Please reach out to me if you find any errors in the article.
The World of Programmable Privacy
One of the biggest benefit of a public blockchain is that it is open, transparent, and trustless. Everything is recorded on the blockchain is processed through a consensus mechanism which chains blocks of transactions together, and this allows cooperatives to interact and develop together in a shared ecosystem without having to know each other. While the biggest benefits of transparency is undeniable that everything is recorded publicly, the biggest trade-offs with public blockchains are that…everything is recorded publicly. Every transaction you push, every NFT you mint and every smart contract you interact with are all published to the blockchain as a shared public ledger, and this level of provenance has led to attempts to capitalize and exploit this system.
Block builders use greedy algorithms [1] to find the most profitable transactions to include in their blocks; Traders copy-trade each other [2] to identify the most profitable trades, and MEV bots front-run or snipe transactions [3] to steal additional profit from victims’ transactions. If blocks generated could be concealed to not reveal the contents of transactions; if the amounts and interactions in transactions were to be private, then such problems would not exist.
To address these practical issue of enhancing privacy on the blockchain, hundreds of millions of venture capital funding has been poured into accelerating on-chain privacy enhancing technology (PET). Many protocols have spun out to tackle the many privacy issues that exist due to this blockchain privacy dilemma, with the vast majority focusing on zero-knowledge proofs (ZKPs). Notable examples include Proven raising $15.8M [4] for their seed round in 2023 and Aztec Protocol raising $100M [5] for their Series B in 2022 as a testament to how important this industry of PET is. However, zero-knowledge proofs are not the only existing cryptographic primitives that are applied to blockchains, with two of the other developments in the space being multi-party computation (MPC) and fully homomorphic encryption (FHE).
Brief Primer on Different Cryptographic Primitives
As a quick primer for the various cryptographic primitives abbreviated above, let me give a short description with a fun example involving (cryptographic) magic:
Zero-knowledge proofs (ZKPs) allow us to generate a proof from a function on whether the output is true or false without showing what the input or process is. This is like how magicians can seemingly manipulate the fabric of reality to materialize a coin out of thin air from my ear, proving that they did their little magic trick. When I ask “how did you do that?” they stay silent, give me a smile, and keep making more coins from my ear without revealing the trick behind it until I give up and walk away.
- ZKPs are useful as it allows us to do private verifiable computation [6] in a decentralized manner applied to blockchains, which allows us to generate proofs of a computation done from a smart contract function or prove that we own a certain asset without revealing details about our ownership.
Multi-party computation (MPC) allows us to compute a function between multiple parties while revealing nothing about the function to each other except the output. This is like how twins can telepathically communicate without talking to each other and somehow say the same things at the same time.
- MPC is useful in trustless distributed key management as the parts of a seed phrase is generated separately without other parties knowledge, removing central points of failure that exists in common hierarchical deterministic wallets that are generated from a single master seed phrase, or externally-owned accounts that exists as single smart contracts. There is a fun game that was created to apply how MPC works that you can play here [7].
Fully homomorphic encryption (FHE) allows us to perform a function on encrypted data without breaking the encryption of the data. This is like how a mentalist can somehow tap into the cosmic noosphere to know what you ate for breakfast and what is in your wallet without you even telling them, and this time its 100% accurate.
- FHE is useful in data analytics as data can be queried without decrypting the ciphertext that was encrypted from the plaintext data, making it so that datasets with sensitive data can be collectively queried without infringing on the security and privacy of the data itself.
As the blockchain space has evolved to adopting more privacy-centric infrastructure with the advent of multiple protocols attempting to solve this issue, there is an interesting development in the space that has attempted to combined all three cryptographic primitives of ZKPs, MPC and FHE to create a Triforce of cryptographic magic.
Introducing fhEVMs
fhEVMs attempts to add new confidentiality functionalities and encrypted data types to existing EVM-compatible blockchains while maintaining the original qualities of the blockchain. This new development is fairly important as there are distinctions as to what and how different parts of the blockchain can apply these privacy enhancing cryptographic primitives.
fhEVMs are based on the developments in FHE that has only existed as an applied field of study in blockchain has only been around since 2009 compared to its older brothers ZKPs and MPC. There has been many articles describing FHE as a cryptographic primitive, and I highly recommend this article [8] which acts as a great introductory piece on how homomorphic encryption works and FHE’s growing development in blockchain industry.
fhEVMs primarily function under the developments of FHE to enable privacy for end users, and other developments in tying in MPC and ZKPs serve to bridge the gap in other aspects that FHE cannot individually solve. These cryptographic primitives work hand-in-hand, complementing each other to enable an end-to-end privacy enhancing blockchain experience.
While zero-knowledge proofs itself allows us to compute outputs privately, the data it computes on may not be encrypted, and how the data is encrypted may not be done in a trustless distributed manner, therefore the data is not fully end-to-end encrypted. fhEVMs attempt to solve this by ensuring that there is end-to-end privacy enabled through ensuring that the created data is encrypted and private, able to be queried in the process of data retrieval while maintaining its privacy, and the output query is also privately computed and generated as well.
This is how it works in a nutshell:
- Multi-party computation (MPC) is used to generate distributed keys to parties and manage the threshold decryption of the FHE cipertexts by setting the threshold signature scheme in a decentralized key management system between multiple parties.
- Fully homomorphic encryption (FHE) is used to allow private blockchain states to be computed on by generating cipertext from plaintext that can be decrypted to reveal its information.
- Zero-knowledge proofs (ZKPs) are used to verify the integrity and verifiability of the encryption and decryption functions by generating proofs that the functions have been computed verifiably.
Application of fhEVMs
Application of FHE into blockchains seems like a match made in heaven given that public blockchains that are open, transparent, and trustless are now able to have transactions on the blockchain that are private while keeping the access to the data available. These private transactions do not reveal any information about what was being transacted on the blockchain, but still allow you to query from it.
Exciting use cases have popped up ever since the introduction of fhEVMs that enable privacy preserving applications to be created. The ability to be able to process encrypted data has unprecedented use cases around being able to conduct data analytics on sensitive data such as healthcare, legal or financial records without compromising on privacy, enabling truly anonymous data analytics at scale and potentially improving problems around transparency and availability of previously inaccessible sensitive data.
How fhEVMs Work
Currently, fhEVMs function very similarly to existing EVMs, with the exact same functionalities as before. The addition that fhEVMs provide are the ability to compute on states that can now be encrypted through FHE, therefore developers are now able to use additional precompiled encrypted data types without needing cryptographic knowledge.
fhEVMs are enabled through the developments in the field of fully homomorphic encryption, with the latest version of FHE introduced in 2018 called the “Fast Fully Homomorphic Encryption over the Torus” [9], also known as TFHE. Developments in the field of FHE applied to blockchain has been pioneered by a company called Zama [10]. They published a pivotal paper on TFHE [11] in 2022 to explain the inner-workings of how they work. To learn more about their work, I highly recommend reading the Zama whitepaper [12] for a deeper understanding of TFHE as well as checking out their introduction to homomorphic encryption [13].
However fhEVMs do not function off FHE in solidarity, requiring the need to tie in MPCs to maintain decentralization and ZKPs for verifiable computation. Let’s now unpack how a hypothetical fhEVM would function with the Triforce of cryptographic magic all together now.
Encrypted Data
On an fhEVM, users would need to be able to encrypt and decrypt their data such that that data remain private while having full control over the data they publish onto the blockchain. First, users would encrypt their data in the form of plaintext into encrypted ciphertext. To the average person, ciphertext would look like a jumbled mess of letters and numbers, however once decrypted, contains the plaintext message that it was encrypted from. How this data can transform from plaintext to ciphertext on an fhEVM is through the use of public key encryption. Public key encryption refers to the ability to generate an asymmetric public-private key pair that allows a user to encrypt data with their public encryption key, while keeping their private decryption key secret to only the user themself. In Zama’s documentation on Public Key Encryption [14], the two methods leverage off the concept of Learning-With-Errors (LWE), where errors are introduced to add noise to the data such that the data is able to hidden under the noise and remain securely private. Once the data is securely encrypted using the user’s public key, the data can then also be securely decrypted using the user’s private key.
In the above simplified scenario, the ability to encrypt and decrypt your data in an fhEVM demonstrates the basic application of FHE, however operations in a blockchain happen trustlessly with smart contracts, and therefore processing the data in a single user scenario does not apply and introduces more complexities. These complexities include how the data is handled in a multi-party setting, how that data is being encrypted and decrypted, as well as how would you know whether the inputs and operations done in an fhEVM are accurate. Blockchains require the ability to function trustlessly and in a decentralized manner, and fhEVMs require those same characteristics in order to be useful to existing blockchain users. These complexities are what FHE alone is unable to solve, but also presents opportunities for other cryptographic primitives to fill in those gaps. This is where theoretical applications of MPC and ZKPs comes in.
Encrypted State
For every state change that is published to the blockchain, the state would also need to be validated to ensure that the data is accurate. In a traditional blockchain setting, validators would be able to verify each state change directly as all the data is publicly available, however in a fhEVM, there are added complexities. In order for data to remain private in an fhEVM, each state change would need to be encrypted, however blockchain validators would need to decrypt that data in order to validate the data. It would be simple to then provide a private key for each validator to decrypt the data, however this would introduce centralization vulnerabilities in the presence of a malicious actor. In an on-chain setting, FHE could be used in combination with MPC to distribute pieces of a shared private decryption key between validators, such that each validator would do a partial decryption on the state change and then aggregated and checked for inconsistencies to yield a fully decrypted value. The validation of blockchain states can also be done off-chain, with a ZKP generated to ensure that the computation done off-chain is verifiable.
These state changes that validators compute and validate in an fhEVM would also extend to a user interacting with an fhEVM application, calling on encrypted operations that can be performed while preserving the user’s data privacy.
Encrypted Operations
A user needs to be able to interact with an fhEVM application containing confidential smart contract functionalities that does not require users to reveal their inputs and keep their data private. In this scenario, a user would interact with the application with their data already encrypted, where ZKPs come in where a zk verifier generates a proof on the accuracy of the user’s data inputs as well as validate whether the operations called from the fhEVM application is logically sound (e.g. A user should not be able to swap a token if their token amount request is less than their token balance). Once this proof is generated to validate the input and operation function, the fhEVM application would call the function and the validators would compute the results and validate the updated state of the fhEVM application.
Tying these hypothetical examples together give us a vague idea on how fhEVMs work, and how they enable an end-to-end private blockchain by ensuring that every data input is encrypted, the decryption of data inputs can only be done in a trustless manner, and that every operation done has a proof generated to ensure that all changes are ensured to be accurate and verifiably computed.
fhEVMs Today
Given how nascent fhEVMs are in applying different cryptographic primitives together, it is important to know that developments in the space are constantly improving and fhEVMs will continue to evolve over time. With that said, there are currently two implementations with their own unique approaches and considerations on how they designed their fhEVM architecture, and we will dive into both in order to understand how they have applied the various cryptographic primitives together to enable the future of end-to-end private blockchains.
The two main implementations of fhEVMs that we will be introducing are:
- Inco, a modular EVM-compatible L1 blockchain built on Cosmos
- Fhenix, a modular L2 optimistic rollup built on Ethereum
Zama created a Rust library to allow developers to implement their TFHE scheme called “TFHE-rs” [15] currently on v0.5 based off their research as outlined in their whitepaper. This FHE library contains their cryptographic library on their (discretized) variant of TFHE and opcode to utilize as a low level cryptographic library, enabling developers to use FHE-encrypted data in their smart contracts. This library is used by both Inco and Fhenix, with Fhenix choosing to do their own implementation and changes to the TFHE-rs library.
Zama’s very own fhEVM implementation also includes the “fhevm” library [16] currently on v0.3, a Solidity library they created to introduce new encrypted data types to solidity smart contracts that are already precompiled for ease-of-use.
Zama pioneered the development of applying FHE into blockchains as we know today, and the two implementations from Inco and Fhenix are both built on top of Zama’s libraries, with Fhenix taking their own approach.
The Cosmos Blockchain fhEVM (Zama & Inco)
Inco is a modular EVM-compatible L1 blockchain built on Cosmos that started in August of 2023. They raised a $4.5 million [17] seed funding round led by 1kx network [18]. At the same time of their funding announcement, they released their first testnet “Gentry” for users to interact with the protocol, with their subsequent testnet release “Paillier” set for release in Q2/Q3 of 2024 and mainnet in full steam for Q4 of 2024.
Inco’s fhEVM implementation is largely built on top of Zama’s fhEVM implementation, opting to build on Cosmos as an L1 blockchain for simplicity and to avoid critical considerations around data availability as a L2 rollup. Inco utilizes the “evmos” [19] library as an EVM stack built on top of the Cosmos ecosystem, and also uses Zama’s “TFHE-rs” and “fhEVM” libraries in their implementation.
While Zama has released a whitepaper [20] outlining their very own fhEVM implementation and a devnet for developers to interact with their encrypted data type smart contract functionalities, they have stated that they do not have any intention to release their own fhEVM blockchain in the future, opting to instead focus on providing FHE & fhEVM libraries and tooling as an infrastructure provider for fhEVM protocols like Inco and Fhenix to thrive.
Inco has not released their whitepaper as of the time this article is published and therefore we have limited information as to how their fhEVM implementation works under the hood. However, given that Inco draws heavily from Zama’s implementation, we will use Zama’s fhEVM whitepaper as a stand-in to explain the fhEVM implementation as an L1 Cosmos blockchain before Inco’s official whitepaper release.
FHE Key Architecture
Zama chose to go with the approach of a global FHE key. The key is generated asymmetrically, with the public encryption and evaluation keys stored on-chain used to encrypt all inputs and states of the blockchain, and the private decryption key split amongst validators. However, in order to ensure that the validators do not abuse the system and act maliciously to decrypt the private data, a threshold protocol is used to ensure that a certain threshold is needed to use their decryption private key as a group of validators.
Threshold Protocol
The threshold protocol used to decrypt the private data on the blockchain references Zama’s paper titled “Noah’s Ark” [21] which introduces ‘’noise flooding’’ to the TFHE Scheme used in their fhEVM implementation such that a threshold protocol can be efficiently applied to prevent malicious actors from misusing their decryption key privileges.
This threshold protocol is the only means in which private data is decrypted and re-encrypted on the blockchain, and the resulting unencrypted plaintext data is sent to validators once the threshold requirement is fulfilled.
Non-Validating Full Nodes
Validators engage with other validators to decrypt the ciphertext collectively under the threshold decryption protocol, and as a result will immediately be able to output a resulting decrypted plaintext data, however full nodes do not have the same access privileges.
Given that full nodes that are not validating the blockchain do not have a private decryption key, they are unable to directly participate in the threshold decryption protocol, and therefore Zama’s approach is for validators to store the resulting plaintext value on-chain such that full nodes are able to sync up to the same state as validators.
Certified Ciphertexts
One concept that was introduced earlier on how FHE works hand in hand with ZKPs in an fhEVM is that a proof needs to be generated for an encrypted operation to happen. In Zama’s implementation, a zero-knowledge proof of plaintext knowledge (ZKPoK) [22] is generated alongside their encrypted input to ensure that the ciphertext is accurate against the proof generated. This certified ciphertext can then be used by smart contracts to verify the proof alongside the ciphertext to generate an encrypted uint (euint) for the smart contract to execute its functions.
FHE Operations
FHE operations in Zama’s fhEVM implementation utilizes the fhEVM Solidity library they created as precompiled smart contracts, including arithmetic operators (add, sub, mul, div), logic operators (and, or, xor, not), comparison operators (le, lt, ge, gt, eq, ne, min, max), bitshift operators (shl, shr) and negation (neg).
FHE operations are much more computationally expensive than non-FHE EVM opcodes. As a comparison, a typical ADD operation on the EVM costs at minimum 3 gas, whereas the same addition operation with an fhEVM (depending on the uint size) costs 94,000 gas for an euint8 operation, ranging from 65,000 gas (euint4) at minimum to 188,000 gas (euint64) as per Zama’s gas estimates [23] on their fhEVM.
Inco’s Implementations
In addition to the fhEVM implementation that Zama has created, Inco has also announced in their blog that they are working together with Hyperlane [24], IBC [25] and The Graph [26] for additional functionalities on their fhEVM blockchain.
As an interoperable L1 EVM-compatible blockchain built on Cosmos, the integration with Hyperlane and IBC would allow cross-chain communications between Inco’s fhEVM and other blockchains to enable fhEVM capabilities to be added to other blockchains. Additionally, the integration with The Graph would allow developers to integrate subgraphs into their smart contracts and monitor emitted events.
The Optimism Rollup fhEVM (Fhenix)
Fhenix is a modular L2 optimistic rollup built on Ethereum that started in July of 2023. They raised a $7 million [27]seed funding round led by Multicoin Capital [28]and Collider Ventures [29]. Fhenix released their whitepaper [30] on November 2023 outlining their optimistic-based approach for their L2 consensus mechanism and consists of a modular sequencer, prover and data availability layer. They currently does not have a testnet available at the time of this article.
Fhenix chose to go with their optimistic-based rollup approach given the high computational overhead needed for a zero-knowledge-based rollup, which essentially combines two cryptographic primitives which are each already computationally expensive to operate on its own.
Fhenix currently does not have a devnet available for testing, however you can set up your local environment with set-up instructions [31] in Fhenix’s documentation page.
Threshold Protocol
Fhenix’s implementation also utilizes the same threshold protocol as Zama’s fhEVM that they developed, however decryption and re-encryption is handled through a Threshold Services Network (TSN), where each request is routed to the network.
The TSN is collectively entrusted with a secret-shared network key, where a certain threshold requirement needs to be fulfilled for the TSN to execute the decryption or re-encryption.
Verified Ciphertexts
An alternative approach from Zama’s ZKPoK implementation proposed by Fhenix is the use of a Verifiable Secret-Sharing protocol (VSS), where users would use the VSS to share their secret inputs to the TSN. These inputs would be validated by the VSS to be reconstructed and output a public value to ensure correctness between parties.
Fraud Proofs
As an optimistic-based rollup, fraud proofs are essential to ensure that the state of the L2 is correct and no fraudulent transactions were posted to the blockchain. In order for this to happen, an optimistic rollup would post the entire block of transaction data to the L1, and any verifier can verify if the data is correct and challenge any fraudulent transactions found.
For an fhEVM to do this as a L2 rollup, Fhenix adapted their own fraud proof mechanism by repurposing Arbitrum’s Nitro fraud prover to compile all of the FHE logic to execute the proving round in a WASM runtime on-chain on the Ethereum L1 layer.
FHE Operations
As part of their fhEVM implementation, Fhenix built the “fheOS” [32] library with their own design which is an EVM-friendly wrapper around Zama’s TFHE-rs library. This library includes all precompiled encrypted opcodes that are used for conducting encrypted operations on an fhEVM, with the same operations available to Zama’s original TFHE-rs library with the addition of support for ciphertext over ciphertext division ops.
Current benchmarks on gas cost estimates for an addition operation costs 7,315 gas for an euint8 operation, up to 34,067 gas for an euint32 operation as per Fhenix’s gas estimates [33].
Conclusion
While fhEVMs are an exciting new development in the world of programmable privacy in blockchain, current implementations do not come without it’s own challenges. The computational intensity of FHE operations introduces significant performance and gas cost concerns, particularly highlighted by the stark contrast in gas costs for encrypted operations compared to non-FHE counterparts. The added complexities require a intense amount of cryptographic rigor to develop at a pace to truly become ready for mainstream adoption.
This article only serves as a brief glimpse into the incredible complexity of implementing Fully-Homomorphic Encryption (FHE) along with Multi-Party Computation (MPC) and Zero-Knowledge Proofs (ZKPs), and with constant development happening in this special space within the blockchain ecosystem, it would be exciting to look back few years later and see that future advancements have made the information in this article seem ancient in comparison.
Links:
[1] https://en.wikipedia.org/wiki/Greedy_algorithm
[2] https://www.binance.com/en/copy-trading
[3] https://coinmarketcap.com/academy/article/frontrunners-and-mev-explained-how-to-beat-the-bots
[5] https://aztec.network/blog/aztec-raises-100-million-to-build-encrypted-ethereum/
[6] https://en.wikipedia.org/wiki/Verifiable_computing
[7] https://encryptle.sine.dev/
[9] https://eprint.iacr.org/2018/421.pdf
[10] https://www.zama.ai/
[11] https://tches.iacr.org/index.php/TCHES/article/view/9836
[12] https://whitepaper.zama.ai/
[13] https://www.zama.ai/introduction-to-homomorphic-encryption
[14] https://docs.zama.ai/tfhe-rs/how-to/public_key
[15] https://github.com/zama-ai/tfhe-rs
[16] https://github.com/zama-ai/fhevm
[17] https://www.theblock.co/post/278316/inco-raise-testnet
[18] https://1kx.network/
[19] https://github.com/evmos/evmos
[20] https://github.com/zama-ai/fhevm/blob/main/fhevm-whitepaper.pdf
[21] https://eprint.iacr.org/2023/815
[22] https://eprint.iacr.org/2023/981.pdf
[23] https://docs.zama.ai/fhevm/v/latest/guides/gas
[24] https://www.hyperlane.xyz/
[25] https://www.ibcprotocol.dev/
[27] https://www.theblock.co/post/252931/fhenix-seed-multicoin-capital
[28] https://multicoin.capital/
[31] https://docs.fhenix.zone/docs/devdocs/Setting%20Up%20Your%20Environment/intro
[32] https://github.com/FhenixProtocol/fheos
[33] https://docs.fhenix.zone/docs/devdocs/Writing%20Smart%20Contracts/Gas-and-Benchmarks