Read the fully homomorphic encrypted EVM protocol fhEVM in one article

Author: ZAMA, Translator: Golden Finance xiaozou

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

Blockchain, as a decentralized data storage and processing mechanism, requires transparency to enable network members to reach a consensus on the state of the system. This transparency in itself represents a huge privacy challenge, as all on-chain data is widely distributed and publicly visible, even when hidden behind anonymous addresses.

How to solve this challenge while ensuring the strong security of existing blockchains is an area of research that is being explored. Without a solution, blockchain transparency can hinder the adoption of some useful applications, so the widespread use of blockchain depends on how this privacy challenge is addressed.

The goal of fhEVM is to solve this challenge with 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. That’s why our solutions are designed 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 combinations.

The solution we propose is based on a combination of Fully Homomorphic Encryption (FHE) and a threshold protocol. All data is on-chain and available to all, and some of it is in encrypted form. Due to the deterministic nature of the evaluation of homomorphic functions, everyone can perform computations on 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, fhEVM

In this article, we’ll look at the innovative blockchain components and how they can be used to build an Ethereum Virtual Machine (EVM)-based blockchain that supports the computation of cryptographic values. The specific contributions are as follows:

· fhEVM, which will be Zama’s open-source FHE library TFHE-rs [Zam22] Integrated into a typical EVM that exposes homomorphic operations as precompiled contracts.

· Decryption mechanism based on distributed threshold protocol [DDE+23].[Sma23] , which prevents the bad operation of malicious smart contracts, but is flexible and friendly for honest smart contract developers.

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

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

2, examples

On-chain cryptographic value enhancements have even revealed many use cases for blockchains, some of which are listed below.

2.1 Crypto ERC-20 tokens

The fungible ERC-20 token standard is an important standard for blockchains. However, due to the public nature of the blockchain system, the personal balances of ERC-20 token holders are public, and simply providing an anonymous address can lead to personal privacy issues. Since fhEVM supports the use of cryptographic values in smart contracts, it is possible to build a cryptographic version of the ERC-20 token standard. To do this, simply change the data type of the balance from integer to cryptographic 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’re bidding. When the bid closes, the highest bidder is determined and declared the winner. Blind auctions encourage bidders to bid no more than they have in mind the value of the lot. This form of auction can be implemented entirely on-chain using cryptographic values naturally, without the need for a trusted entity to perform calculations on plaintext bids, unlike promise-based or zero-knowledge proof-based solutions. With crypto ERC-20 tokens, bidders simply transfer the crypto amount into a blind auction smart contract and then compare bids to determine and announce the winner.

2.3DAO for Enhanced Privacy

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 members’ votes. In general, DAOs have their own coffers, which are managed by their members through proposals. Proposals are voted on by members and can only be implemented after they have been voted on. The voting system here can be implemented through an ERC-20 token contract, where the number of tokens held by members reflects their voting power. Thus, on-chain cryptographic values enable DAO members to vote in secret.

Using crypto vaults, DAOs can also compete fairly in auctions, preventing others from knowing the details of the funds (i.e., the ability to bid) in advance.

2.4 Decentralized identifiers

Decentralized identifiers (DIDs) are a new type of identifier that provides individuals and organizations with verifiable and autonomous digital identities. Leveraging encrypted data, smart contracts located in fhEVM are able to securely store and process sensitive information related to user identities, protecting user privacy throughout the process.

For example, a central authority or government can publish a cryptographic date of birth for an authorized user in a smart contract. Subsequently, the authorized party can query the smart contract if 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 calculations on private inputs. While some solutions can use more than one technology, we broadly divide these technologies into four categories:

Zero-knowledge (ZK) proofs, Trusted Execution Environment (TEE), Secure Multi-Party Computation (MPC), and Homomorphic Encryption (HE).

3.1 Zero-knowledge (ZK) proofs

ZK proofs address privacy challenges by only keeping submitted data on-chain and correctly computing proofs. However, this data must be in plaintext for calculations to take place, which means that a plaintext copy of the data must be kept somewhere. This approach 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] [Ped92]Provide anonymity to both the sender and receiver in the transaction, while using the Pedersen commitment Privacy protection for the number of traded tokens.

Zexe [BCG+20] and VeriZexe [XCZ+23] allow the use of zkSNARKs to evaluate arbitrary scripts in zero-cash-like blockchains. The restriction is that since multiple smart contracts or multiple parties do not have access to the cryptographic state on the chain, the input data must be known to at least one party in order to generate a zkSNARK. Currently, it is not possible to update the encryption state without revealing it using this method.

Hawk [KMS+16] uses ZK proofs where the input to the smart contract is displayed to a trusted manager who performs the computation.

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

3.2 Trusted Execution Environment (TEE)

The TEE-based blockchain system only stores the encrypted data on-chain and performs the computation by decrypting the data inside the secure enclave containing the decryption keys [YXC+18, KGM19, CZK+19, SCR23, Oas23, Pha23]. The security of such a solution depends on whether the decryption key is securely contained in the Secure Enclave. This makes users dependent on the Secure Enclave hardware and its manufacturers that rely on remote attestation mechanisms.

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

3.3Multi-Party Computation (MPC)

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

Eagle [BCDF23] The Hawk structure has been improved to allow customers to outsource their inputs to the MPC engine, which will do the calculations for them. Eagle has also added features such as identifiable aborts and public verifiability to the outsourced MPC engine. Although in Eagle, the input side does not have to be online all the time, they need to interact with the MPC engine for at least one round to provide the input [DDN+16].

Although their yellow book is very detailed, there is nothing about Partisia in it [Par23] How to implement privacy protection stored information.

3.4Homomorphic encryption (HE)

A number of homomorphic cryptographic solutions have been proposed based on partial homomorphic cryptography, which limits the types of operations that can be performed, so that only specific classes of smart contracts and applications are supported. For example, Zether [BAZB20] The use of ElGamal-based encryption scheme ensures the confidential transfer of funds. But when it comes to more complex smart contracts, this isn’t enough to achieve complete secrecy.

Zkay [SBG+19] defines how to execute Ethereum smart contracts using FHE, but using a trusted third party holding the decryption key. smartFHE [SWA23] [FV12]BFV is used FHE is built as a base layer (HE) block. In their setup, each wallet runs the BFV key generation process locally to obtain a public key pair. Multiple wallets have different keys, so in order to execute more complex smart contracts, such as blind auctions, a distributed key generation protocol needs to be run and a joint (PK, SK) is generated. The ciphertext involved in the computation then needs to be re-encrypted under a new PK, and after the homomorphic execution of the blind shot, a distributed decryption protocol needs to be run to get the result (although the distributed decryption protocol is not detailed in their documentation).

FISHING [Dai22] Using a similar architecture to ours, a global public key PK is used, which everyone uses to encrypt their own balances, and a threshold FHE protocol is used to help decrypt the output. One major difference is that their threshold protocol modulo operations are performed with q = p as the prime number, whereas ours applies to ring zq, where q is usually a power of 2. Another difference is that in PSCA, the threshold FHE modulus q is exponentially related to the number of participating parties n; That is, the ciphertext modulus must increase (n!) compared to the non-threshold scheme 3 times.

There have been a number of Ethereum Improvement Proposals (EIPs) that have explored the idea of adding homomorphic cryptographic storage to the EVM.