Data integrity and transparency are two of the main focuses of blockchain systems. However, transparency can raise concerns for various reasons, which call for privacy-preserving solutions. On public blockchain platforms such as Ethereum, achieving privacy can be challenging. Nonetheless, Web3 research and development teams have made substantial progress with different approaches, combining proven methods and novel tools to achieve confidential Web3 dApps. In this article, we will examine some of the latest developments, specifically FHE on EVM.
In the following article, blockchain refers to open, public, and permissionless blockchains
Tell me
When asked what blockchain is, one of the correct answers is that it is a distributed information system. Let’s keep this definition in mind throughout the rest of the article.
In general, sensitive data and information require protection and security against data corruption, loss, unwanted access, inspection, modification or tampering, and disclosure. Blockchain technology provides the highest level of data record protection and data integrity. Protecting sensitive data also involves data privacy, which blockchain can only partially provide under specific conditions. Privacy is the freedom of choice to selectively share (disclose) sensitive information. In the context of information security and the CIA triad model (confidentiality, integrity, availability), blockchain fully assures integrity and availability.
Not all blockchains are created equal. Open, public, permissionless blockchains are natively transparent by design, which affects confidentiality and makes them not the best choice for many business applications. To keep data confidential and secure in general, various cryptography methods are applied. This is not specific only to modern communication systems, as history shows with examples such as the Caesar Shift Cipher, Simple Scytale Cipher, Steganography, Pigpen Cipher, Enigma Code, and many others.
Cryptography plays a vital role in blockchain technology and powers all of its security, privacy, and operational aspects. These include hashing (SHA256, keccak256), private-public key (Elliptic Curve), zero-knowledge (zk) proofs, multisig (Schnorr), ring signatures, and more. Cryptography is quintessential for addresses, wallets, transactions, block production, consensus, Merkle Trees, and smart contracts. Without cryptography, there is no blockchain.
Blockchain Platforms
The shift from 'primitive' blockchains with a single use-case towards modern blockchains with broad application scenarios was unlocked with the addition of arbitrary programmable smart contracts by the Ethereum blockchain. Smart contracts are neither legal contracts nor are they inherently smart. They are computer programs with automated and unstoppable execution once predefined conditions are met. Smart contracts do not run on a private server or on your local computer; they live on a blockchain and are executed in a special runtime environment.
On the Ethereum blockchain, smart contracts are executed in the Ethereum Virtual Machine (EVM). It is a runtime environment that provides a set of resources that a smart contract can use, such as memory, storage, and processing power. The EVM ensures the execution of smart contracts in a decentralized, secure, and trustless manner.
A transaction is a single cryptographically signed instruction, and any transaction data that smart contracts use as input and output is public and transparent, with immediate availability. By executing transactions and smart contract code, the EVM calculates the new blockchain state involving publicly accessible transaction data. The transparency of this data may be undesirable for certain business processes or aspects of an individual's private life.
Why conceal anything?
It can be detrimental to a business if its investment or divestment strategy, its treasury, financing, payroll, and all business cash flows are publicly available in real-time. Clients, stakeholders, competition, criminals, creditors, suppliers, employees... everyone has insight. Once a blockchain address is tied to a real-life identity, all previous and future transactions are easily tracked and analyzed. The aforementioned confidentiality of (pseudo)anonymity on a blockchain is lost forever.
Wallet and address tracking services, such as Nansen, Arkham, Chainalysis, or Ciphertrace, are in the business of deanonymization, which can be used for various legitimate purposes. However, full confidentiality and privacy also have legitimate purposes within regulated business practices. The lack of both acts as one of the deterrents for increased blockchain adoption.
Blockchain is, per design, meant to be transparent; it is its innate strength. Someone might be quick to point out that privacy and transparency do not go hand in hand. Though, this is false.
Privacy is the freedom to decide what information to disclose and to whom. When talking to different people, you can decide to whom you reveal your passwords, income, or holiday plans. Privacy is not absolute secrecy, and yet it is often criminalized. Transparency, on the other hand, especially non-optional and forced transparency such as on a public blockchain, can leave you fully exposed, like being naked in a glass house in the middle of a city.
You got any data?!
In today's digital age, data is the new oil, and arguably, almost everything runs on data. In the coming years, we can expect a continuous increase in off-chain and on-chain data, emphasizing the need for security and privacy. Data of any sort is mined and sold on data markets to the highest bidder. Self-Sovereign Identities (SSI) are one of the approaches to tackle many challenges related to privacy and control of personal data usage. I wrote about SSI and blockchain in one of my previous articles; read it here:
As mentioned, cryptography is one of the security layers to protect sensitive data. By encrypting it, only the holder of the secret key can decrypt and use it. In modern information systems, encryption is used everywhere: for data storage (clients, local and cloud servers) as well as for protecting data in transit.
When a software process needs that data, it has to be retrieved from the data storage and decrypted before any use of it is possible. Think of a spreadsheet containing financial or medical records that should be analyzed as a basis for decision-making. The decryption step actually reveals the data as it strips it of its protection, making it vulnerable to unauthorized access, disclosure, tampering, etc.
In Web3, dApps and smart contracts operate on publicly transparent (plaintext) data. This raises critical challenges:
How can the entire CIA triad model be ensured for smart contract execution?
How can any data remain encrypted but still be routinely used?
FHE on EVM
Fully homomorphic encryption (FHE), also regarded as "cryptography's holy grail," enables direct usage and analysis of encrypted data (ciphertext) without prior decryption, hence preserving privacy and increasing data security.
With FHE, any blockchain transaction data can be kept confidential, and smart contract computations happen with encrypted data as if they were unencrypted.
FHE was introduced in 1978 by Rivest, Adleman, and Dertouzos, but until the breakthrough in 2009 by Craig Gentry at IBM, presented in his PhD thesis, FHE was more theoretical than practical, too complicated, too slow, and highly resource-intensive for routine computational loads.
There are already quite a few privacy-preserving solutions for payment transactions, such as the blockchains Zcash or Komodo with t-addresses and z-addresses, using zk-proofs. However, on-chain execution of arbitrarily programmable (EVM) smart contracts is a different use case altogether. Several highly interesting Web3 projects are already taking up this challenge.
One of the main uses of the general concept of zk-proofs is verification, enabling proving that some statement (data) is true without revealing the proof. Unlike Ethereum Optimistic rollups, ZK rollups use zk-SNARK proofs of validity for off-chain computation verification, thus mathematically ensuring the correctness of the blockchain state, which evolves with every new transaction.
By the way
Have you ever wondered why you sometimes pay extremely high gas fees on Ethereum for transaction processing, depending on which dApps you interact with, as opposed to when simply sending tokens to another wallet? No, I am not talking about network congestion; assume you are the only user on-chain. The answer lies in the complexity of the transaction itself, depending on its functionality encoded in the smart contract. This is a part of the on-chain computational load.
Another part is transaction verification. It is one of the challenges for blockchain scaling because hashing operations and signature verification also generate computational load and require processing time. With increased usage, the processing load can go beyond the chain's limits imposed by its technical design and prevailing technical possibilities.
As the volume of transactions and complexity of smart contracts increase, ways to optimize efficiency have come into focus. Therefore, Ethereum's main approach post-transitioning to Proof-of-Stake is off-chain computation with Layer 2 (L2) scaling solutions.
Back to zk
Granting EVM smart contracts a full layer of selective confidentiality is not possible with zero-knowledge due to its inability to process encrypted data from multiple users. dApps can have tens of thousands of users (unique active wallets) interacting with the dApp's smart contracts. Furthermore, zk is suitable for simpler tasks and specific use cases, such as verifications. Complex and fully private on-chain computations, as well as broader applicability, require different solutions other than just zk.
For example, there are Trusted Execution Environments (TEEs) and Secure Multi-Party Computation (MPC) available. However, both have their drawbacks for on-chain computations, such as higher computational overhead with increased data load, security concerns, integration complexity for existing blockchain architectures, required parties' interaction, etc.
FHE tackles some of the above points of TEEs and MPC and offers a high level of flexibility and composability. However, it has much lower scalability, is slow, and needs specific FHE computation hardware. By combining zk-proofs and FHE, the verifiability of encrypted data and computation over that data is improved, as FHE alone can't prove data correctness without revealing it; it can only process it. FHE itself generates a lot of encrypted data as output, which can't be stored directly on-chain, and thus requires adequate off-chain storage and a data availability (DA) solution. Unfortunately, at the moment, there is no production-ready DA solution optimized for FHE encrypted data.
It is important to note that FHE for on-chain use is an active area of research and has its challenges and limitations.
As the saying goes, "Many roads lead to Rome," and various Web3 teams choose different approaches to solve the same problems. Regarding on-chain privacy on Ethereum, Aztec leverages zero-knowledge proofs, and TEN (The Encrypted Network) uses secure enclaves. These two projects are very interesting and will be discussed separately in future articles.
Oh, look! Another L2
There are dozens of rollups out there, and many more will come, especially after the Dencun upgrade, which brought a minimum of 10x lower fees for Layer 2 solutions (L2s).
An FHE rollup, named Fhenix, is a welcomed addition to the existing set of L2s. It unlocks privacy and confidentiality on Ethereum, making for a near-perfect gap fill for privacy-preserving Web3 dApps. Writing smart contracts with Solidity remains the same, but now developers can tap into the power of FHE. Fhenix provides FHE extensions and precompiles to the EVM, enabling computation over encrypted on-chain data.
Fhenix is an FHE Layer 2 rollup that combines an optimistic rollup structure, the Arbitrum Nitro prover, WASM execution, and a Threshold Services Network to enable privacy-preserving smart contracts and dApps on the Ethereum blockchain. The Arbitrum Nitro prover plays a crucial role in generating fraud proofs for the FHE computations performed within the Fhenix rollup.
An example use is DeFi with shielded ERC20 tokens, that is, encrypted token balances, which are publicly visible but actually invisible and compatible with every other dApp that uses ERC20. This allows for verification and processing of confidential (private) transactions while concealing its details. Any bots, including those for Maximal Extractable Value (MEV), will not be able to exploit and manipulate transactions anymore. On-chain analysis services that heavily use machine learning (LLMs) and AI for deanonymization and profiling will have a hard time.
FHE has broad application scenarios, both off-chain and on-chain (see an aside at the end of the article). Businesses can offer services without accessing raw (user) data, and service users (clients, consumers) will experience no difference in the service they receive. All of the users' online activities can now be encrypted end-to-end, including data in transit and during processing. Even with compromised servers, FHE keeps sensitive data secure. This achievement unlocked is an enormous leap forward in encrypted cloud computing services.
What do do with FHE on-chain?
To begin with, Fhenix identifies seven areas where FHE can provide privacy benefits in the context of blockchain use cases:
Confidential Transactions:
Full privacy of sensitive transaction data.On-chain Auctions:
Safeguarded bidder data and auction integrity (e.g., Token Generation Events, DeFi liquidations).Confidential Voting:
Protecting voter privacy, preventing manipulation, and ensuring compliance with regulations.Encrypted Gaming:
On-chain state updates while keeping player data concealed and in-game transactions secure.Decentralized Identities:
On-chain identifiers with control over personal data, secure encryption, interoperability, and authentication.MEV Protection:
Confidential mempool transactions prevent MEV and enable fair transaction ordering.Privacy-Preserving AI:
FHE keeps end-to-end privacy and security of data used for AI models.
Of course, FHE features come at a higher gas cost, which depends on how a smart contract handles data.
Under the hood
Fhenix builds on Zama's fhEVM, which allows Solidity developers to create encrypted smart contracts without cryptographic expertise. Headquartered in Paris, Zama is the leading open-source cryptography company specializing in FHE solutions for blockchain and AI. Their fhEVM brings Solidity integration, and so guarantees confidentiality and composability of smart contracts. Thus, fhEVM can be seamlessly integrated into any EVM-compatible chain, which enables the coexistence of already launched public and new encrypted dApps simultaneously.
Fhenix uses an Optimistic Rollup structure to avoid the computational overhead associated with FHE. Since Ethereum does not natively support FHE, Fhenix utilizes the Arbitrum Nitro* prover to enable the FHE logic to be compiled and run on WASM (WebAssembly) code. This prover is the key component responsible for generating fraud proofs used to validate the correctness of off-chain computations and transactions. By compiling the FHE logic into WASM code, the prover can efficiently execute the necessary computations and generate fraud proofs when required.
*Arbitrum Nitro is a high-performance rollup that uses a unique approach to scaling called optimistic rollup with a fraud proof. This approach combines aspects of both optimistic rollups and zk-rollups to provide a scalable and secure platform for decentralized applications (dApps) on Ethereum.
Fhenix employs a modular design that separates the rollup into different layers for the sequencer, validator, and data availability (DA). This modular approach allows for flexibility and scalability in the rollup architecture.
For the decryption of data, Fhenix uses a Threshold Services Network (TSN). TSN is a decentralized network of nodes that collaborate to perform threshold cryptography operations, such as distributed key generation and decryption. By using TSN, Fhenix ensures that the decryption process is secure and resistant to single points of failure. It's important to mention that Fhenix's TSN has limitations in fault tolerance thresholds (up to 1/3).
Currently, the Fhenix L2 is still in the development phase, but they have already put out their first public build called 'Fhenix Frontier'. See instructions here on how to connect to it and to get test tokens from the faucet. If you're a developer looking to begin with Fhenix, their developer documentation is an excellent starting point. It provides guidance for Remix, Gitpod, and Hardhat environments.
To wrap it up
Blockchain data is fully transparent and freely available to anyone. Albeit absolutely secure from tampering, its visibility is a privacy concern.
Contrary to the popular belief, blockchains are neither anonymous nor data-concealing, but they can be under specific conditions.
In general, data encryption is used to protect and secure sensitive data, but encrypted data cannot be used by software without decryption beforehand.
On-chain computation and data usage by smart contracts is public by design, allowing insight into data to anybody interested.
FHE enables direct usage and analysis of encrypted data without decryption, hence preserving privacy and increasing data security.
With the Fhenix FHE rollup (L2), EVM smart contracts can now have selective confidentiality, opening new use cases for Web3.
An aside:
Example off-chain use cases for FHE are:
Search and data retrieval (e.g. using search engines or databases with concealed query and results)
Genomic (DNA) data processing
Biometrics
Secure cloud services (medical, financial, e-commerce, e-government, insurance, critical infrastructure, etc.)
Machine Learning (ML) and AI applications
Industrial (corporate) espionage protection
Personal data protection (KYC, consumers, users)
Secure outsourcing of data analysis to 3rd parties (e.g. consumer analytics, marketing research, statistics, economic, financial analysis and forecasts, AI, IoT)
Secure voting systems
Secure credit scoring
Private auctions and bidding (confidential trading)
Thank you for reading!
