# Introduction
Welcome to this handbook. If you’ve ever wished you could **use data without revealing it**, FHE is the tool you’ve been looking for.
> Note: While this handbook covers FHE concepts generally, it will focus specifically on TFHE a scheme optimized for exact math and fast, programmable operations.
FHE (Fully Homomorphic Encryption) lets you:
* **Encrypt data**
* **Compute directly on encrypted data**
* **Decrypt the result** to obtain the same answer as if the computation had occurred on the plaintext.
The key idea is simple but powerful:
> **You can outsource computation without outsourcing data privacy.**
This introduction explains **what FHE is**, **why it matters**, and **what problems it solves, especially in Web3**.
***
> This handbook is a beginner-friendly introduction to Fully Homomorphic Encryption (FHE), with a particular focus on TFHE-style schemes and how they are used in practice. It is not meant to be a research textbook full of formal proofs. Instead, it prioritizes clear intuition, consistent notation, and step-by-step explanations that help you build a correct mental model of how FHE works.
>
> We include only the math you actually need to understand the core ideas, ciphertexts, encodings, noise, and bootstrapping. And we explain it in a way that’s approachable for readers who are new to lattice-based cryptography. If you want to go deeper into proofs and cutting-edge research, we’ll point you to high-quality references, but the main goal here is simple: **help you get from “FHE feels mysterious” to “I can explain TFHE and follow how real systems implement it.”**
## What is FHE?
**Fully Homomorphic Encryption** is an encryption method that supports computation on ciphertexts (encrypted values) in a way that generates an encrypted result which, when decrypted, matches the result of operations performed on the plaintexts.
If you have:
* plaintexts: `m1, m2`
* encrypt them: `c1 = Enc(m1), c2 = Enc(m2)`
Then, for an operation `⊕` (like addition) There exists a corresponding ciphertext operation `⊗` such that:
`Dec( c1 ⊗ c2 ) = m1 ⊕ m2`
The magic is that the server (or blockchain, or node) performing `⊗` **never learns** `m1`, `m2`, or the result.
### The three “levels” of homomorphism
* **PHE (Partially Homomorphic)**: supports *one* type of operation (e.g., only addition *or* only multiplication) an unlimited number of times.
* **SHE / Leveled HE (Somewhat Homomorphic)**: supports both addition and multiplication but for **limited-depth circuits**. (Eventually, "noise" accumulates and decryption fails).
* **FHE (Fully Homomorphic)**: supports *arbitrary* computation depth. This is enabled by a computationally expensive "refresh" step called **bootstrapping** that reduces noise.
***
## Teach Me Like I’m 5 (ELI5)
Imagine your data is a raw ingredient (like gold) inside a locked glovebox.
* You put the gold in the glovebox and lock it (encryption).
* You give the box to a jeweler.
* The jeweler uses gloves built into the side of the box to hammer, mold, and shape the gold (computation).
* The jeweler **never touches** the gold directly and **cannot see** it clearly through the dark glass.
* They return the box to you.
* You unlock it with your key (decryption).
* Inside is a finished gold ring, exactly as if they had worked on it directly.
So, **others can work on your data without ever seeing it.**
***
## Why FHE?
Because modern systems keep forcing a painful tradeoff:
### The tradeoff today
To compute on data, you usually must choose one:
* **Privacy** (keep data secret, but do nothing with it)
* **Utility** (run useful computation, but expose the data)
Most systems sacrifice privacy:
* Your cloud provider processes unencrypted data in RAM.
* Your database admin can see records.
* A public blockchain makes everything transparent by default.
FHE breaks that tradeoff:
* **You keep privacy** (data remains encrypted in RAM and at rest)
* **You still get computation** (the application still works)
***
## What problem does FHE solve in Web3?
Web3 makes **state and computation transparent**. That’s great for verification (don't trust, verify), but terrible for privacy.
On public blockchains:
* Balances are public
* Trades are public
* Strategies are public
* User behavior is linkable
This creates real problems:
### 1) Privacy of user data on public state
Most dApps unintentionally leak:
* who you are (linkability)
* what you own (balances)
* What you will do next (mempool visibility)
**FHE enables an encrypted state**, so the chain can update balances and storage slots while keeping the actual values hidden.
### 2) Confidential computation for on-chain apps
Many real-world applications require hiding inputs to work fairly:
* **Poker:** You can't show your hand.
* **Auctions:** Sealed bids must remain sealed until the end.
* **Enterprise:** Supply chain data and invoices.
FHE enables dApps in which inputs are encrypted, contract logic operates on those encrypted values, and outputs are revealed only to authorized parties.
### 3) Reducing Negative MEV (Maximal Extractable Value)
Transparency enables predatory behaviors like front-running and sandwich attacks because attackers can see your intent.
FHE can reduce this by:
* Encrypting the **amount** and **limit price** of a swap.
* Keeping the **liquidation threshold** of a loan private.
*Note: FHE does not solve all MEV (metadata like "who is calling the contract" is often still visible), but it significantly hardens the execution layer.*
### 4) On-chain identity and compliance without doxxing
FHE allows for "blind" compliance checks.
* A user encrypts their credit score or country of residence.
* The smart contract checks: `Enc(UserCountry) != Enc(SanctionedCountry)`.
* The contract gets a result (True/False) without ever learning the user's actual country.
### 5) Enterprise adoption
Enterprises cannot use public blockchains if it means revealing trade secrets or customer PII (Personally Identifiable Information). FHE allows them to use the **public settlement layer** while keeping the **business logic private**.
***
## What makes FHE different from ZK, MPC, and TEEs?
Web3 already has privacy tools. FHE is a different point in the design space.
### FHE vs Zero-Knowledge Proofs (ZK)
* **ZK**: "I verify that a computation was done correctly." (Proving)
* **FHE**: "I perform the computation on hidden data." (Calculating)
**Use ZK when:** One party knows the data and wants to prove a fact to everyone else. **Use FHE when:** No one should know the data, but everyone wants to process it (or when multiple private inputs need to be combined).
### FHE vs MPC (Multi-Party Computation)
* **MPC**: Splits a secret key across many servers. To compute, the servers must communicate constantly.
* **FHE**: The data is encrypted with a single key. One server can do all the work alone.
**Tradeoff:** MPC is chatty (high bandwidth). FHE is heavy (high CPU/computation).
### FHE vs TEEs (Trusted Execution Environments like SGX)
* **TEEs**: Rely on "secure hardware" (Intel/AMD chips). If the hardware is hacked, privacy is lost.
* **FHE**: Relies on mathematics. Even if the hardware is malicious, they cannot read the data.
TEEs are fast but brittle. FHE is slower but cryptographically secure.
***
## The big caveat: FHE is harder than normal cryptography
FHE is not a magic wand you can wave over any code.
### 1) Performance overhead
It is significantly slower than plaintext computation (currently 100x - 10,000x slower depending on the operation). You must optimize for:
* **Circuit depth:** How many operations happen in a sequence.
* **Noise management:** Using bootstrapping sparingly.
### 2) Ciphertext expansion
An encrypted boolean (1 bit) might take up 16KB of space. This impacts:
* **Bandwidth:** Sending data takes longer.
* **Storage:** On-chain storage is expensive.
### 3) The programming model is different
You cannot easily branch on encrypted data (e.g., `if (enc_x > 0) { do_A } else { do_B }`). Since the computer doesn't know if `x > 0`, it must execute **both** branches and combine the results mathematically.
***
## What security assumptions does FHE rely on?
Most modern practical FHE schemes (like TFHE, BGV, CKKS) rely on **Lattice Cryptography**. Specifically, problems like:
* **LWE (Learning With Errors)**
* **RLWE (Ring Learning With Errors)**
These are considered **post-quantum secure**, meaning even a quantum computer likely cannot break them.
Intuition:
* Encryption adds a small amount of random "noise" to the data.
* If you have the secret key, you can filter out the noise.
* If you don't, the noise makes the data look entirely random.
***
## When should you use FHE?
Use FHE when:
1. **Input Privacy is critical:** The server must not see the data.
2. **Shared State is needed:** Multiple users are adding private data to a shared calculation (e.g., a voting tally or a dark pool).
3. **Hardware trust is insufficient:** You cannot trust an SGX enclave or a centralized server.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://sabanaku77.gitbook.io/fhe-handbook-for-beginners/introduction.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.