.png)
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?
.png)
This makes web3 unsafe
.png)
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.
.png)
Homomorphic Encryption (FHE) enables encrypted data processing
e.g. $ E[a] + E[b] = E[a+b] $ or more generally $ f(E[x]) = E[f(x)] $.
%20(1).png)
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
- On-chain identity
FHE enables storing identities privately on-chain, and doing encrypted KYC, etc.
- Private NFT metadata
FHE enables hiding NFT metadata while still enabling composability.
- Geolocated dapps
FHE enables dapps to use location data while hiding where users are.
Ciphertext = encrypted data + noise
We need to add random noise to the encrypted data to guarantee security.
%20(2).png)
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
.png)
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.
.png)
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.
.png)
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.
.png)
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
.png)
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.
Additional links
- Check out the Concrete Library
- Join the FHE.org discord server
.png)
.png)
.png)