Private Smart Contracts Using Homomorphic Encryption

May 23, 2023
Rand Hindi

× ⚠️🚀 Zama released the alpha code and white paper for the fhEVM.
See it on Github here, and please ⭐ star the repo to support our work.

FHE EVM demo - watch video

Homomorphic encryption (FHE) is a technology that enables processing data without decrypting it. This can be used to create private smart contracts on top of public, permissionless blockchains, where only specific users would be able to see the transaction data and contract states. While FHE used to be too slow to be practical, recent breakthroughs are now making this possible in the next couple of years.

Note: this blog post is an updated version of Rand Hindi's presentation during EDCON 2023.

Slide 1/23

Private smart contracts using homomorphic encryption

Slide 2/23

Everything on a blockchain is public

How else would nodes agree on state?

Slide 3/23

This makes web3 unsafe


Criminals can see what you own, so they can easily target you and steal your crypto.


Governments can surveil you, even if you use multiple addresses.


Bots can front-run you, creating a hidden tax on every transaction.

Slide 4/23

Homomorphic Encryption (FHE) enables encrypted data processing

e.g. $ Enc(a) + Enc(b) = Enc(a+b) $ or more generally $ f(Enc(x)) = Enc(f(x)) $.

Slide 5/23

FHE enables privacy in smart contracts while keeping everything on-chain

Encrypted transaction data

Data included in transactions is encrypted and never visible to anyone.

Encrypted state updates

States are updated while remaining encrypted at all times. Not even block producers can see the data.

Encrypted on-chain data

Data stored on-chain remains encrypted end-to-end, even when used by smart contacts.

Slide 6/23

Some cool use cases enabled by FHE

Trustless bridges

Use an encrypted key to sign bridge transactions homomorphically.

Blind auctions

Great for NFT auctions, RWAs, DeFi darkpools, marketplaces, etc...

Confidential voting

Keep choices and token amounts encrypted when voting.

Slide 7/23

ZK is for scalability, FHE is for privacy

Slide 8/23

Homomorphic Encryption 101

Slide 9/23

Ciphertext = encrypted data + noise

We need to add random noise to the encrypted data to guarantee security.

Slide 10/23

Problem: noise grows with every operation

If the noise grows too big, it will overwrite bits of data with random ones.

Slide 11/23

On-chain states can be updated indefinitely

This means noise will eventually grow too big and lead to incorrect states.

Slide 12/23

Bootstrapping reduces noise

Bootstrapping is a special operation that resets the noise to its nominal level.

Slide 13/23

How can we compute exact comparisons?

Using additions and multiplications alone can only approximate them.

Slide 14/23

TFHE to the rescue

TFHE is a scheme that enables fast bootstrapping and exact arbitrary computations.

TFHE bootstrapping is programmable

Slide 15/23

FHE is getting exponentially faster

FHE smart contracts are doable today, with a throughput of ~5 tps. FHE ASICs will enable 1,000+ tps at a fraction of the cost.

Zama FHE performance (Million FHE gates/$)

Slide 16/23

A private smart contract protocol using (T)FHE

Slide 17/23

What we want

Simple user experience

Users should interact with a private contract the same way they interact with a public one.

Simple developer experience

Developers should not have to learn a new language to write private smart contracts.

Simple integration

Chains should have as little to integrate as possible, and not disrupt their existing ecosystem.

Slide 18/23

FHE token contract in Solidity

Slide 19/23

There are many technical challenges

Access control

How do we selectively decrypt states without a centralized decryption key?


How can contracts be composable without breaking privacy?


How do we increase throughput while keeping block sizes small?

Slide 20/23

Secure the private key with Threshold FHE

Split the secret key amongst validators such that at least 2/3 are needed for decryption.

1. Secret sharing

Generate and distribute pieces of the secret key to each validator.

2. Partial decryption

Each validator then does a partial decryption (or keyswitch).

3. Aggregation

The partial decryptions are aggregated to yield the full decrypted value.

Note: Needs a fixed number of validators such as in DPoS, NPoS, etc..

Slide 21/23

Zero-knowledge proof of input awareness

Users need to submit a proof that they know the value of the encrypted inputs.

1. Encrypt data

Users encrypt the transaction inputs they want to keep secret.

2. Generate proof

They then generate a zero-knowledge proof to show they know the inputs.

3. Validate proof

Validators then check the input proofs before executing transactions.

Slide 22/23

Next: going from 5 tps to 1000+ tps


Tranciphering allows sending encrypted inputs with minimal size expansion vs plaintext.


Optimistic FHE rollups are already possible, and ZK FHE rollups will be possible within ~3 years.

HW acceleration

FHE hardware accelerators are coming in 2025 and will speedup FHE by 1000x or more.

Slide 23/23

Written by Rand Hindi

Dr Rand Hindi is the CEO at Zama and an investor in 30+ companies across privacy, AI, blockchain, medtech and psychedelics.

Follow Rand on Twitter.

Read more related posts

TFHE Deep Dive - Part I - Ciphertext types

This blog post is part of a series of posts dedicated to the Fully Homomorphic Encryption scheme called TFHE by Ilaria Chillotti.

Read Article

Homomorphic Encryption 101

What is homomorphic encryption?

Read Article