Author: ZAMA, Translator: Golden Finance xiaozou

fhEVM is an EVM confidential smart contract protocol using fully homomorphic encryption developed by the fully homomorphic encryption project ZAMA.

As a decentralized data storage and processing mechanism, blockchain requires transparency in order for network members to reach consensus on the state of the system. This transparency itself presents a huge challenge in terms of privacy, as all on-chain data is widely distributed and publicly visible, even if hidden behind anonymous addresses.

How to solve this challenge while ensuring strong security guarantees for existing blockchains is an area of ​​ongoing research. Without a solution, the transparency of blockchains will hinder the adoption of certain useful applications, so the widespread use of blockchains depends on how to solve this privacy challenge.

The goal of fhEVM is to solve this challenge for general-purpose (Turing-complete) blockchains such as Ethereum. We believe that the only way for smart contract development to be scalable is to not require developers to have expertise in cryptography. Therefore, our solution aims to provide a smooth and intuitive developer experience. In addition, a successful privacy-preserving solution must support common blockchain use cases and design patterns, such as easily combining data from different users, keeping encrypted data on-chain, and smart contract composition.

The solution we propose is based on a combination of Fully Homomorphic Encryption (FHE) and the Threshold Protocol. All data is on-chain and available to everyone, some of which is in encrypted form. Due to the deterministic nature of homomorphic function evaluation, everyone can perform computations on the encrypted data and use typical consensus protocols. This also intentionally preserves a key benefit of blockchain transparency: the computations performed remain public, while only the data being computed is hidden.

1. Contribution of fhEVM

This article will introduce innovative blockchain components and how to use them to build a blockchain based on the Ethereum Virtual Machine (EVM) to support the calculation of encrypted values. The specific contributions are as follows:

fhEVM, which integrates Zama’s open source FHE library TFHE-rs [Zam22] into a typical EVM, exposing homomorphic operations as precompiled contracts.

A decryption mechanism [Sma23] based on the distributed threshold protocol [DDE+23] that prevents bad operations by malicious smart contracts but is flexible and friendly to honest smart contract developers.

The Solidity library makes it easy for smart contract developers to use encrypted data in their contracts without changing compilation tools.

Note that while the demonstration given here is based on the EVM blockchain, our approach is very general and can also support other blockchains, such as WASM-based blockchains. In addition, non-threshold-like decryption mechanisms can also be easily used.

2. Use Cases

On-chain cryptographic value enhancement and even reveals many use cases of blockchain, some of which are listed below.

2.1 Encrypted ERC-20 Tokens

The homogeneous ERC-20 token standard is an important standard for blockchain. However, due to the public nature of the blockchain system, the personal balances of ERC-20 token holders are public, and simply providing anonymous addresses may cause personal privacy issues. Since fhEVM supports the use of encrypted values ​​in smart contracts, it is possible to build an encrypted version of the ERC-20 token standard. To do this, simply change the data type of the balance from an integer to an encrypted integer and replace each operation with its respective FHE counterpart.

2.2 Blind Shooting

First-price sealed auctions allow bidders to submit bids privately so that no one knows what they bid. When the bidding ends, the highest bidder is determined and declared the winner. Blind auctions encourage bidders to bid no more than they think the item is worth. This auction format can naturally be implemented entirely on-chain using encrypted values, without requiring a trusted entity to perform calculations on plaintext bids, unlike solutions based on commitments or zero-knowledge proofs. Using encrypted ERC-20 tokens, bidders simply transfer encrypted amounts to the blind auction smart contract, which then compares bids to determine and declare a winner.

2.3 Privacy-enhancing DAOs

Decentralized Autonomous Organizations (DAOs) are becoming increasingly popular in the blockchain space as a way to create autonomous communities without a central authority. They rely on smart contracts to enforce rules and make decisions based on member votes. Generally, DAOs have their own treasury and are managed by their members through proposals. Proposals are voted on by members and can only be executed if they are voted through. The voting system here can be implemented through ERC-20 token contracts, where the number of tokens held by members reflects their voting power. Therefore, the on-chain encrypted value enables DAO members to vote in secret.

Using a crypto vault, the DAO can also level the playing field in auctions by preventing others from knowing funding details (i.e. the ability to bid) in advance.

2.4 Decentralized Identity Identifiers

Decentralized identity identifier (DID) is a new type of identifier that provides individuals and organizations with verifiable, self-sovereign digital identities. Using encrypted data, smart contracts in fhEVM can securely store and process sensitive information related to user identities, thereby protecting user privacy throughout the process.

For example, a central authority or government could publish the encrypted birthdate of an authorized user in a smart contract. Authorized parties could then query the smart contract when necessary to obtain information about the user’s age (e.g., whether they are of legal age).

3. Related Work

There are multiple ways to perform smart contract computations on private inputs. While some solutions may use multiple techniques, we broadly group these techniques into four categories:

Zero-knowledge (ZK) proofs, trusted execution environments (TEEs), secure multi-party computation (MPC), and homomorphic encryption (HE).

3.1 Zero-Knowledge (ZK) Proof

ZK proofs address privacy challenges by only storing submitted data and proof of correct computation on-chain. However, this data must be in plaintext to be computed, which means a plaintext copy of the data must be stored somewhere. This works well when the computation only requires data from one party, but what about applications that require data from multiple parties?

ZCash [BCG+14] and Monero [Mon23] provide anonymity for both senders and receivers in transactions, while using Pedersen commitments [Ped92] to protect the privacy of the amount of tokens traded.

Zexe [BCG+20] and VeriZexe [XCZ+23] allow the evaluation of arbitrary scripts in zerocash-like blockchains using zkSNARKs. The relevant limitation is that, since multiple smart contracts or parties cannot access the encrypted state on the chain, the input data must be known to at least one party to generate the zkSNARK. Currently, it is impossible to update the encrypted state without leaking it using this method.

Hawk [KMS+16] uses ZK proofs where the inputs to a smart contract are revealed to a trusted manager that performs the computation.

Our solution is to perform computations directly on encrypted data, which means it is simple to aggregate and mix data from multiple users, and computations can be performed on-chain.

3.2 Trusted Execution Environment (TEE)

TEE-based blockchain systems store only encrypted data on-chain and perform computations by decrypting data within the secure enclave containing the decryption key [YXC+18, KGM19, CZK+19, SCR23, Oas23, Pha23]. The security of such solutions depends on whether the decryption key is securely contained in the secure enclave. This makes users dependent on the secure enclave hardware and its manufacturer, which relies on remote attestation mechanisms.

The enclave approach has been shown repeatedly to be vulnerable to several side-channel attacks [VMW+18, LSG+18, KHF+19, vMK+21, TKK+22, vSSY+22], including attacks that only look to leak memory access patterns [JLLJ+23].

3.3 Multi-party Computation (MPC)

zkHawk [BCT21] and V-zkHawk [BT22] use the MPC protocol to replace the trusted manager in Hawk [KMS+16], and all input parties need to participate online.

Eagle [BCDF23] improves the Hawk architecture to allow clients to outsource their inputs to an MPC engine, which then computes them for them. Eagle also adds features such as abort-awareness and public verifiability to the outsourced MPC engine. Although in Eagle, input parties do not have to be online all the time, they need to interact with the MPC engine for at least one round to provide inputs [DDN+16].

Although their yellow paper is very detailed, it does not contain any information on how Partisia [Par23] achieves privacy-preserving storage.

3.4 Homomorphic Encryption (HE)

Some homomorphic encryption solutions based on partially homomorphic encryption have been proposed, which restrict the types of operations that can be performed and thus only support specific categories of smart contracts and applications. For example, Zether [BAZB20] uses an ElGamal-based encryption scheme to ensure the confidential transfer of funds. But when it comes to more complex smart contracts, this is not enough to achieve complete confidentiality.

Zkay [SBG+19] defines how to use FHE to execute Ethereum smart contracts, but using a trusted third party that holds the decryption key. smartFHE [SWA23] builds on FHE using BFV [FV12] as the underlying (HE) block. In their setup, each wallet runs the BFV key generation process locally to obtain a public key pair. The keys for multiple wallets are different, so in order to execute more complex smart contracts, such as blind auctions, it is necessary to run a distributed key generation protocol and generate a joint (pk, sk). Then, the ciphertexts involved in the computation need to be re-encrypted under the new pk, and after homomorphically executing the blind auction, a distributed decryption protocol needs to be run to obtain the result (although the distributed decryption protocol is not detailed in their documentation).

PESCA [Dai22] uses a similar architecture to ours, with a global public key pk that everyone uses to encrypt their own balances, and a threshold FHE protocol to help decrypt outputs. One major difference is that their threshold protocol operates modulo q = p, while our threshold protocol works over ring Zq, where q is typically a power of 2. Another difference is that in PESCA, the threshold FHE modulus q scales exponentially with the number of parties n; that is, the ciphertext modulus must increase by a factor of (n!) 3 compared to the non-threshold scheme.

There have been a number of Ethereum Improvement Proposals (EIPs) exploring the idea of ​​adding homomorphic encrypted storage to the EVM.