Beyond Zero Knowledge: How Fully Homomorphic Encryption Enables Private Shared State

Table of contents

• Introduction
• What Does FHE Bring To The Table?
• Option 1: Adding FHE Computation Natively into the VM
• Option 2: Using an FHE Coprocessor
  • Private Shared State
• What Can Be Built Using FHE?
• What OpenZeppelin is Working On

Introduction

Onboarding the world to blockchain has always been the ultimate goal. Over the years, countless taglines have promised to bring the next billion users into the space. But to truly achieve this, we must build a system that incorporates all the essential features required at a global scale. Chief among these is privacy — an issue that has once again taken center stage in 2025.

In prior years, zero-knowledge proofs (ZKPs) have been the most prominent privacy-enhancing technology. However, ZKPs have certain limitations, and one school of thought is to remedy some of these limitations through the use of FHE, specifically as a coprocessor. In this blog post, we’ll explore Fully Homomorphic Encryption (FHE) and its potential applications in blockchain. It has become increasingly clear that there is no one-size-fits-all solution for privacy, and FHE is no exception. We'll examine the benefits and trade-offs of integrating an FHE coprocessor into blockchain infrastructure.

The typical FHE workflow is as follows: a user has sensitive data they want to keep private but still needs to compute on it. They encrypt the data and send it to a powerful server or computing resource. That machine performs the desired computation on the encrypted data and returns the encrypted result. Finally, the user decrypts the result to obtain the output without ever having revealed their original data.

What we've described so far can happen without a blockchain. However, blockchain technology brings unique value through decentralization and security. The question then becomes: how can we integrate the FHE primitive into blockchain systems to leverage both privacy and trustless computation?

While this blog post avoids diving into the cryptographic details of FHE, it's important to understand that these addition and multiplication operations are far more complex than simple integer arithmetic. We could assign gas costs to these FHE operations or precompiles based on the computational effort required by the nodes. However, due to their complexity, these operations would be extremely expensive in terms of gas. On the Ethereum Layer 1 blockchain, the cost would likely be prohibitively high, making such functionality impractical for real-world use.

Moreover, introducing changes to a system like Ethereum is a lengthy and rigorous process, often taking years to review and implement. Therefore, to enable FHE-based computation in the near term, it would likely require a separate blockchain, or at least a dedicated Layer 2 (L2) solution.

The benefits of doing so would be to have a synchronous system that works as one whole distributed state machine as we know it today. A transaction could be run and settled with the same finality that we have become used to with Ethereum's consensus. However, as of today, the cons outweigh the pros, and this method is not commonly adopted.

Concretely, how it works is the following: the user will encrypt their data and put it into a transaction, with the desire to do FHE computations on this encrypted data. The smart contract that is called will incorporate a special library that contains functions which emit events. For example, the library contains an FHE addition and an FHE multiplication function that will emit an event named "FheAdd" or "FheMul" when called. That is all that these functions do. Off-chain, the supernode (the FHE coprocessor) will be listening to these events and performing the actual FHE computation (and storing the output of that computation as well). One of the main benefits of the FHE coprocessor approach is that this can be "added onto" any existing EVM blockchain without any changes to the nodes themselves.

When the user wants to obtain the output off-chain, they can ask the coprocessor for the encrypted output themselves, or if they want that posted on-chain, after decryption, they could submit a transaction with the decrypted output and post that on-chain (or have a relayer do it for them).

With the architecture described above, this begs one question: how do we ensure that the coprocessor is performing the correct computation? In the option where the execution nodes are performing the operation, the security is guaranteed by consensus. However, in this model, we are just "trusting" that the coprocessor actually does what the emitted events dictate.

There are a few options to solve this trust issue. The first option is to use ZKPs. We could force the coprocessor to perform the FHE computation, and then prove that indeed that was the operation performed (such as in zkVMs or zkEVMs). However, for reasons outside of the scope of this blogpost, this method is computationally super intensive and slow. As you can imagine, given that a ZK prover generally takes much longer than running the statement itself, an already slow FHE computation proven in ZK would be extremely slow! While recent advancements in lattice-based SNARKs and recursive proof systems are improving feasibility, practical deployment for day-to-day blockchain applications remains challenging and may require further optimization over the coming years.

Another option is to use a staking/slashing mechanism such as Eigenlayer's AVS or a Cosmos chain. Essentially, this would be forcing the coprocessors to act as the execution nodes, but on a different system than the native one. Using consensus methods, the coprocessors could be incentivized to perform the correct output to avoid losing tokens. However, finality would still be an issue here as the nodes would take a long time to compute. Furthermore, having many nodes perform this computation would create a lot of overhead. A similar approach could be to use fraud proofs. In this method, again the coprocessor could be slashed if they misbehaved. However, only one coprocessor needs to perform the computation and anyone could dispute it. However, the drawback to this approach is that the time-window until finality must be long enough to allow parties to be able to dispute the claim.

In a private ZK system, a private storage variable is typically owned and controlled by a single entity. This is because the variable is stored on-chain in an encrypted form, and modifying it (at least performing multiplication) requires generating a zero-knowledge proof using the plaintext value as a witness. As a result, only the owner (who knows the plaintext) can update the variable.

Some schemes attempt to overcome this limitation using linear homomorphic encryption, which allows non-owners to perform additive operations on encrypted data. However, these approaches still fall short when it comes to enabling multiplicative updates by others. FHE addresses this limitation by enabling the owner of a private variable to permit third parties to perform both additive and multiplicative updates without revealing the underlying plaintext. This makes FHE particularly well-suited for scenarios requiring collaborative computation on private state.

A user can specify who is permitted to update a given variable. As a result, these systems often include access control lists, which are smart contracts that maintain a mapping between each variable and the set of users authorized to update them. Additionally, the access control list stores information about who is allowed to decrypt and view the variable. To incorporate this feature and at the same time not force users to share decryption keys off-chain, the typical architecture of an FHE coprocessor would look slightly modified from the one described above.

In addition to the FHE coprocessor, the system typically includes a privileged entity (or a set of entities) off-chain that generates a public/private key pair. All users in the system encrypt values using this public key and submit them on-chain via transactions. An access control list (ACL) maintains a mapping of which addresses have the rights to modify and/or decrypt these encrypted values.

By default, the address that submits the initial transaction is granted both modification and decryption privileges. That address can then also endow these permissions to other addresses by updating the ACL.

When a user attempts to modify a variable, they must submit a transaction, which will only succeed if the ACL authorizes the action; otherwise, the transaction will revert. Similarly, when attempting to decrypt a variable on-chain, a user must submit a transaction, and it will only succeed if their address has the necessary decryption privileges, as verified against the ACL. The flow would be that a user submits a decryption request, an event is emitted, the trusted entity decrypts the value off-chain, and then submits another transaction to post the result on-chain. If the user wants to perform the decryption off-chain (so that only they would know the value), they can provide a different public/private key pair to the trusted entity, who first decrypts the value, and then reencrypts it with the user's public key so that only the user themselves can later decrypt the value to obtain the plaintext. It is assumed that the trusted entity deletes the decrypted value after reencryption and does not leak it.

Of course, having a trusted entity that can decrypt is not ideal. Thus, in most systems, the trusted entity can be a set of entities, who each contain a piece of the private key. Together, they can decrypt the values, but no one individually can. This is performed using an MPC (multi-party computation) protocol.

The threshold of this MPC can be set to whichever values of m and n are desired (e.g. 5 of 13 working together can decrypt). If the user desires off-chain decryption (i.e. reencryption as described above), the MPC both decrypts the value and reencrypts it within the same protocol such that none of the MPC nodes view the resulting plaintext in the clear. The entities only view the reencrypted output, which is sent to the user. Therefore, as we can see, in these FHE systems, there is often an MPC trust assumption as well as the trust assumption of the FHE coprocessor, since if enough of these entities collude, then they can perform decryption on their own and view private data, even when the user has not permitted them to do so.

For instance, a confidential ERC-20 token can be implemented where both token balances and transfer amounts are fully encrypted. This ensures that no outside observer can see how much is being sent or held by any participant. Another application is a sealed-bid auction, where only the winning bid is revealed, preserving the privacy of all other participants. Similarly, a private decentralized exchange (DEX) could be created, where trading activity and liquidity positions remain confidential. These are just a few examples of applications that are now possible.

However, as with any technology, it's important to carefully consider the potential drawbacks and risks of this approach. As previously mentioned, the privileged entities operating the FHE coprocessor, as well as the MPC decryption nodes, introduce trust and security considerations that must be thoroughly evaluated.

Additionally, the computational overhead of FHE operations within the coprocessor can be significant, potentially impacting performance and scalability. If a private application does not require private shared state, or if its functionality can be achieved using linear homomorphic encryption (where only addition over encrypted values is needed) it may be more practical to use simpler and more efficient techniques, such as standard zero-knowledge proofs (ZKPs).

OpenZeppelin has developed a reference implementation of a confidential token compatible with both Zama and Inco Atlas. These platforms leverage the FHE coprocessor architecture outlined in this article, which allows for private shared state. However, given that different privacy-enhancing technologies (PETs) offer varying trade-offs, the standard is designed to be technology-agnostic and inclusive of different privacy approaches.

Looking ahead, OpenZeppelin is actively exploring applications beyond confidential tokens, including confidential identity, confidential real-world assets (RWAs), and much more, which are essential for adoption by financial institutions and government entities.