Verify, don’t trust. That is the philosophy that has been at the center of blockchain development for over a decade, underpinning all the work that was done around consensus, ZK, optimistic rollups and more. But one major issue with requiring public verifiability of state updates is that all onchain data needs to be publicly available, creating what seems like an impossible dilemma: either use a public blockchain and have no confidentiality, or use a private blockchain and have no verifiability. And while some ZK-based protocols have offered some degree of confidentiality, they lack the most essential feature that makes blockchains unique: composability.

To solve these problems, Zama created the fhEVM: a novel protocol leveraging FHE to enable confidential smart contracts on EVM chains:

• The data (transaction inputs and onchain state) is encrypted: no-one can see it, not even validators.
• The encrypted state is fully composable: smart contracts can run on encrypted data, like they do on plaintext data, thanks to FHE.
• Privacy is programmable: smart contracts define who can decrypt the data, enabling access control to be managed onchain. The network’s decryption key is decentralized using a threshold MPC protocol, avoiding the need to trust a centralized authority.

Our first implementation, which was released a year ago, could process around two transactions per second, and required validators to run a modified version of the EVM that supports FHE operations. While the integration was easy for a new chain or rollup, it prevented existing chains such as Ethereum, Base or Solana from benefiting from FHE without a major upgrade and slowdown. Until now.

fhEVM coprocessors

Today, we are announcing Zama’s most exciting product to date: the fhEVM coprocessor. It allows developers to build confidential smart contracts on any EVM chain, including those that don’t support FHE natively, without changing anything to the underlying protocol.

As a developer, you can already start building using our Sepolia coprocessor testnet, with Ethereum and many other ecosystems following soon.

We also made major performance improvements, and can now handle close to 20 transactions per second, ten times more than a year ago, and more than the average Ethereum throughput over the past 10 years. In other words, we could run Ethereum encrypted end-to-end. Our new architecture is in fact so scalable that we are confident we will enable hundreds, or even thousands, of FHE transactions per second in the near future, simply by adding more hardware. 

To achieve this, we had to completely reinvent the fhEVM stack from the ground up, building on two core ideas: symbolic execution and threshold decryption. 

‍Symbolic execution

The idea behind symbolic execution is that whenever a contract calls Zama’s TFHE library on the L1 to perform an FHE operation, the L1 itself doesn’t do any actual FHE computation, and instead produces a pointer to the result which is then computed by an offchain server that monitors the L1. This is akin to how lazy evaluation works in programming languages, and allows deferring computation to a later point (in this case to when the block is finalized). 

This has many advantages:

• The L1 does not need to run expensive FHE operations or use specific hardware
• The L1 is not slowed down by FHE, so non-FHE transactions can be executed as fast as they always have been
• FHE operations can be executed in parallel, rather than sequentially, dramatically increasing throughput. 

Since all ciphertexts on the L1 are simply pointers (the actual data is stored in a DA), FHE operations can be chained just like regular operations, without needing to wait for the previous ones to complete. The only time we need to wait for a ciphertext to be computed is when it has to be decrypted. 

From a security perspective, everything the coprocessor does is publicly verifiable, and anyone can just recompute the ciphertexts to verify the result. Initially, Zama will be running the coprocessors, but longer term the goal is to enable anyone to compete to execute FHE operations, leveraging ZK-FHE to prove the correctness. 

Threshold decryption

To maintain composability onchain, all ciphertexts need to be encrypted under the same public key. This means the private decryption key has to be secured in a way that prevents illegitimate decryption of ciphertexts. The fhEVM solves this by splitting the private key amongst multiple parties, using a dedicated threshold MPC protocol called a KMS (for Key Management Service). 

In order for a user or contract to decrypt a value, they need to first have been explicitly allowed to do so by the contract that produced it on the L1. To request a decryption from the KMS, they then need to provide a Merkle proof that they are allowed to do so on the L1. 

Behind the scenes, Zama’s KMS is actually a blockchain L1, with a convenient web API on top. Whenever an application requests a decryption through Zama’s APIs, a transaction is made to Zama’s KMS chain, which verifies the proofs and runs the threshold decryption protocol. We will share more about it soon.

Solidity is all you need

Getting to this point was hard. The fhEVM is likely the most advanced, complex cryptographic protocol to ever be pushed into production (and we haven’t even talked about the details of the KMS yet!). But this is what it takes to bring privacy and confidentiality to everyone onchain, without compromising on security and user experience.

When it comes to user experience, anyone who has tried to build confidential dapps will know how terrible the experience is: you need to learn a new language, think about “circuits”, then do heavy computation on slow laptops, and so on. With the fhEVM, none of this is necessary. All you need to know is Solidity, and with that you can get started immediately. As an example, consider an ERC20 token with encrypted balances:

// SPDX-License-Identifier: BSD-3-Clause-Clear
pragma solidity ^0.8.4;

import "fhevm/lib/TFHE.sol";
import { IEncryptedERC20 } from "./IEncryptedERC20.sol";

abstract contract EncryptedERC20 is IEncryptedERC20 {

    uint64 internal _totalSupply;
    string internal _name;
    string internal _symbol;

    // Balances are encrypted
    mapping(address account => euint64 balance) internal _balances;

    /// @notice A mapping of the form mapping(account => mapping(spender => allowance)).
    mapping(address account => mapping(address spender => euint64 allowance)) internal _allowances;

    // Transfer an encrypted amount
    function transfer(address to, einput encryptedAmount, bytes calldata inputProof) public virtual returns (bool) {
        // Verify the input is correct
        euint64 amount = TFHE.asEuint64(encryptedAmount, inputProof);

        // Check if the user can enough balance, otherwise set the transfer amount to zero
        ebool transferValue = TFHE.select(TFHE.le(amount, _balances[msg.sender]), amount, TFHE.asEuint64(0));

        // Make the transfer
        _balances[to] = TFHE.add(_balances[to], transferValue);
        _balances[from] = TFHE.sub(_balances[from], transferValue);

        // Allow users to see their balances, and the contract to update it
        TFHE.allow(_balances[to], to);
        TFHE.allow(_balances[from], from);
        TFHE.allowThis(_balances[to]);
        TFHE.allowThis(_balances[from]);

        return true;
    }
}

This involves only 3 steps:

1. Use the fhEVM javascript SDK to encrypt the user’s transfer amount, then submit the transaction just like you would normally.
2. Convert your ERC20 contract to an FHE equivalent by replacing “uint” types with their “euint” FHE equivalents, then give users the right to decrypt their balance.
3. Use the javascript SDK to decrypt the user’s balance and display it.

That’s it. It really is that simple. You can check out the documentation for more examples.

FHE is end-to-end encryption for blockchain

The ability to build confidentiality in blockchain applications is not just a matter of personal privacy. It’s a matter of enabling a whole suite of use cases that were previously impossible. Here are some examples:

• Confidential stablecoins and tokens. Would you be comfortable sharing your bank statement with everyone? Probably not. And yet, this is what currently happens with tokens. With FHE however, you can keep the balances, transfer amounts and even assets private, ensuring that nobody but you knows how much you own.‍
• Confidential swaps. DeFi has been one of the most successful use cases of blockchain, but it suffers from two major issues: people don’t like sharing everything they own, and MEV makes it expensive for end users to swap assets onchain. FHE can solve both issues by enabling end-to-end encrypted swaps, where the amount and possibly asset is kept private at all times. ‍
• Onchain credit. Lending money requires collecting sensitive information, such as credit scores, identity, and financial statements. With FHE, this becomes possible onchain, as all the data can be used by smart contracts confidentially to determine whether someone is credit-worthy or not.‍
• Confidential governance. The idea of onchain voting, whether for DAOs or governments, has been explored for as long as blockchains exist. But having the votes cast publicly onchain can lead to biases, blackmailing, or bribing. With FHE, votes (and numbers of tokens staked) can be kept private, ensuring only the final tally is revealed, and not the individual votes. ‍
• Onchain corporations. Managing a company onchain would be impossible without the promise of confidentiality. Indeed, information such as the cap table, financials, board votes, customers, and employee registers  should not be disclosed publicly. With FHE, all this information could be kept onchain, allowing smart contracts to automate many day-to-day company operations. ‍
• Sealed-bid auctions for token sales. Run a public token sale as a sealed-bid auction to have better price discovery. Each participant places an encrypted bid consisting of a number of tokens and a price per token they are willing to pay. When the auction is over, run through the bids from highest to lowest until all tokens have been “bought”. The price at which the last token is bought is the clearing price that everyone who has bid more ends up actually paying, regardless of their initial bid.‍
• Composable onchain identity. Offchain, we use our identities all the time, from buying products online to booking plane tickets. Doing so onchain however would leak sensitive information such as your name, address, social security number and more. With FHE however, you can have a complete DID+VC system onchain, where your identity is encrypted while being fully composable with decentralized applications. Just like you can have account abstraction, you can now have identity abstraction.

But what if we went beyond that? What if FHE was the key to running everything onchain? From money, finance, and identity to companies, elections, and games, from AI, social media, and cloud services, all the way to entire states and their governments. – all of this could run on a public blockchain while being encrypted end-to-end. We call this vision HTTPZ: just like HTTPS brought privacy online, HTTPZ will bring privacy onchain.

The infrastructure for HTTPZ is here. What we now need are applications, so if you are a builder and want to make this future happen, if you want to be an FHE pioneer, get in touch!

Additional links

• Read Zama's fhEVM whitepaper
• Star Zama's fhEVM Github repository to endorse our work.
• Review Zama's fhEVM documentation.
• Get support on our community channels.
• Help us advance the FHE space with the Zama Bounty Program.