Private Smart Contracts using Homomorphic Encryption

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.

Everything on a blockchain is public

How else would nodes agree on state?

This makes web3 unsafe

‍Theft

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

‍

‍

Surveillance‍

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

‍

‍

‍MEV‍

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

‍

Zero-knowledge proofs do not enable privacy when multiple users are involved

ZKs offers privacy by computing off-chain, which only works for single users. This doesn’t enable private AMMs and other multi-user dapps.

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)) $.

FHE enables on-chain privacy

- 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.

‍

FHE makes web3 safe

‍No targeting

Criminals can’t target you since they cannot see how much crypto you own.

‍

‍

‍No surveillance

Governments cannot surveil you since they cannot decrypt your on-chain state.

‍

‍

‍No MEV

Bots cannot front-run you since they cannot see transaction data.

‍

FHE enables new categories of dapps

Ciphertext = encrypted data + noise

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

Noise grows with every operation

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

Bootstrapping reduces noise

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

Levelled schemes

e.g. BGV, BFV, CKKS Avoid bootstrapping by provisioning enough room for noise to grow. Very fast but...

On-chain states can be updated indefinitely

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

That’s not the only problem though ...

Levelled schemes only allow additions and multiplications. Comparisons and non-linear functions are approximated using polynomial approximation.

TFHE to the rescue

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

TFHE is the only scheme that can support arbitrary smart contracts

‍

Concrete is an open source framework for TFHE

‍User-friendly APIs

Concrete enables using FHE without knowing cryptography.

‍

‍Hardware accelerated

Concrete can leverage accelerators such as GPUs, FPGAs, and ASICs.

‍

Written in Rust

For better performance and security.

‍

FHE will be fast enough for most applications by 2025

And probably before that for smart contracts, but it might not be cheap to run until ASICs are here.

FHE token contract pseudo-code

contract Token {
    mapping(address => uint256) public balanceOf;
	// Transfer tokens privately, amount is encrypted under the network's key 
	function transfer(address _to, FHECiphertext _value) external returns (bool) {    
		require(_to != address(0), 'ERC20: to address is not valid');
		require(_value <= _balances[msg.sender], 'ERC20: insufficient balance');

		_balances[msg.sender] -= _value;
		_balances[_to] += _value;

		emit Transfer(msg.sender, _to, _value);
		return true;
}
    
	// to enable a user to view their balance, we need to re-encrypt 
	// the balance from the network's key to the user's key 
	function view_balance(FHEPublicKey userKey, address Address) external view returns (bytes) {
		require(address == msg.sender, 'ERC20: invalid user');
    	return reencrypt(balanceOf[address], userKey);
      }
   } 

High level protocol

To enable multiple users to interact with each other, we need the data to be encrypted under the same FHE public key.

Dealing with encrypted inputs is tricky

Privacy

Who holds the network’s private key and how can we prevent them from misusing it?

‍

Validity

How do we handle requires on encrypted data without breaking privacy?

‍

‍

‍Security

How to we prevent malicious users from decrypting other users’ encrypted states?

‍

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..

‍

Dealing with encrypted requires

Requires need to be decrypted at execution time to validate transactions.

1. Block production

Validator 1 optimistically executes and proposes a block, but does not participate in threshold decryption.

2. Threshold validation

Other validators optimistically execute and validate the block, then do a threshold decryption of the requires, keyswitches, etc.

3. Block commitment

If there is threshold consensus, the failed transactions are removed and the finalized block appended to the blockchain.

‍

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.

‍

Full protocol

Future improvements

‍Provable FHE

Generate a proof of correctness for an FHE execution to avoid redundant execution.

‍

FHE-rollups

With provable FHE correctness, we can create FHE L2s for Ethereum and others.

‍

Performance

Make FHE fast to execute for block producers and cheap to verify for validators.

‍

‍

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.

‍