FHE × DeFi

Fully Homomorphic Encryption in Decentralized Finance — Survey & Landscape

FHE enables computation on encrypted data without decryption — the "holy grail" of cryptographic privacy. For DeFi, this means encrypted on-chain state, ブラインドアービトラージ, 封印された オークション, and ダークプール マッチング where validators compute on ciphertexts without ever seeing 平文 values. Currently research-stage for real-time applications; near-term wins in auctions and governance.

What is FHE and Why Does DeFi Need It?

The Fundamental Problem

Smart contract state is completely public by default. Every balance, every order, every AMM reserve is visible to all participants — enabling front-running, sandwich attacks, and information leakage.

FHE の約束

With FHE, contract state can be encrypted on-chain, with validators computing over ciphertexts without ever seeing 平文. The "magical" property: compute on data without decrypting it.

Normal 計算 vs. FHE 計算 Normal (平文公開) ユーザー 平文: x=42 暗号化 暗号文 enc(42) 復号化! サーバーは x を見る 平文: 42 計算 問題: サーバーがデータを見る FHE (平文非公開) ユーザー 平文: x=42 暗号化 暗号文 enc(42) 暗号化を保持 FHE 計算 on 暗号文 サーバーは x を見ることがない FHE DeFi アプリケーション フロー ユーザー tx を暗号化 公開鍵付き 暗号化された Tx オンチェーン / メモリプール 全員に表示 バリデータ / サーチャー FHE は上で計算 暗号文 — blind 暗号化結果 暗号化出力 状態更新 ユーザー 結果を復号化 プライベートキー付き キー インサイト At no point does the validator / searcher / matching engine see x in 平文. Computation happens entirely in "暗号文 space" — results decrypt to the correct answer.

DeFi が FHE を必要とする理由 (そして難しい理由)

MEV 軽減

Searchers currently see all mempool Tx in 平文, enabling front-running and sandwiching. FHE: searchers compute on encrypted Tx without seeing content.

まだ実践的ではない

ダークプール マッチング

オーダーブックはすべての参加者に取引意図を公開します。FHE ダークプール: マッチングエンジンは暗号化された注文を評価し、マッチング結果のみを公開します。

短期研究

封印された オークション

バッチ オークションは封印された入札が必要です。FHE により、決済前に個別の入札を公開することなく、入札超での計算が可能になります。

短期的に実行可能

現実チェック (2024年): FHE is まだ実践的ではない for real-time DeFi (millisecond latency requirement). 128 ビット整数の比較は CPU で数秒かかります。ギャップは約 1000 倍のパフォーマンス改善です。 タイムライン: ハードウェア アクセラレーションを想定して、リアルタイム実用化まで 5 ~ 10 年。

FHE 系統: TFHE, BFV, BGV, CKKS

BFV — Brakerski-Fan-Vercauteren

算術: 整数 mod q (正確)

最適用途: 正確な整数計算、準同型データベース

ライブラリ: Microsoft SEAL, OpenFHE

DeFi 適用: トークン残高 (正確な算術)、台帳状態

正確な整数

BGV — Brakerski-Gentry-Vaikuntanathan

算術: SIMD バッチング付き整数 mod p

最適用途: ベクトル上の並列操作 (暗号文ごとに複数メッセージをパック)

ライブラリ: HElib, OpenFHE

DeFi 適用: バッチ決済、集計統計

ベクトル化された整数

CKKS — Cheon-Kim-Kim-Song

算術: 実数/複素数に対する近似算術

最適用途: ML 推論、統計計算 — 小さな近似誤差を許容

ライブラリ: Lattigo, OpenFHE, HEAAN

DeFi 適用: リスクモデル、価格オラクル (近似 OK)

近似実数

TFHE — Torus FHE

算術: 高速ブートストラッピング付きゲートごと (ビット操作)

最適用途: 条件分岐、比較 — 任意の boolean 回路

ライブラリ: Zama の tfhe-rs (Rust)

DeFi 適用: MEV ブラインドアービトラージ (FHE-MEV 論文)、fhEVM

Boolean 回路 + 高速ブートストラップ

パフォーマンス比較 (CPU、2024 年)

TFHE 操作遅延 — ログスケール (CPU、2024 年) 0.1ms 1ms 10ms 100ms 1s 10s DeFi RT threshold ~1ms ~1ms Boolean AND ~100ms Bootstrap ~50ms 8-bit add ~200ms 8-bit compare ~2s 128-bit add ~5-10s 128-bit cmp GPU 10-100x faster

When to Use Each Variant

Scheme 算術 Bootstrapping DeFi Use Case Status
TFHE Boolean gates / small integers Fast (~100ms CPU) FHE-MEV, fhEVM, dark pool (comparisons) Research
BFV 正確な整数 mod q Slow Encrypted ledger balances (batch ops) Research
BGV Integers + SIMD batching Moderate Batch settlement, aggregate stats Research
CKKS 近似実数 Moderate Risk models, pricing oracles Research

性能進化 Timeline

78
1978 — Rivest et al. pose the problem (theoretical only)
09
2009 — Gentry's first FHE construction (exponentially slow)
11
2011 — BGV scheme (polynomial improvement)
16
2016 — TFHE ブートストラッピング in milliseconds (vs. hours in 2009)
20
2020 — tfhe-rs 1.0 (Rust, practical open source)
23
2023 — GPU-accelerated FHE (10-100x speedup); FHE-MEV paper
24
2024 — FPGA/ASIC FHE designs emerging; Zama raises $73M
?
2028-2030? — Hardware-accelerated FHE practical for DeFi

FHE-MEV: Blind Arbitrage Without Seeing Transactions

Paper: "FHE-MEV: Blind Arbitrage in MEV" — Passerat-Palmbach et al. (Flashbots / Imperial College London, 2023). Concept: searcher runs arbitrage on TFHE-encrypted UniswapV2 transactions without ever seeing content.

The Core Problem: Searchers Must See Tx to Profit (Today)

Current State (Broken)

Searchers observe 平文 mempool Tx:

  • Token pair (USDC→ETH)
  • Swap amount (e.g. 100,000 USDC)
  • Slippage tolerance (e.g. 0.5%)

This enables targeted front-running, sandwich attacks, and precise price impact computation — at user expense.

FHE Goal

Searcher receives only encrypted 暗号文. Performs FHE computation:

  • Which pair? (on 暗号文)
  • Opportunity exists? (on 暗号文)
  • Optimal size? (on 暗号文)

Learns only: "opportunity exists" (yes/no) and optimal backrun parameters — not the original Tx content.

Protocol Flow — Blind Arbitrage

ユーザー Mempool Searcher Block Builder Chain STEP 1 User TFHE-encrypts swap(USDC→ETH, amount=X, slippage=Y%) with network public key enc_tx = TFHE.enc(swap_params) STEP 2 Searcher fetches 暗号文 from mempool — sees only opaque bytes, no 平文 enc_tx (opaque) STEP 3 — FHE Computation (on 暗号文, no decryption) enc_pair = FHE.select_bits(enc_tx, TOKEN_PAIR_BITS) // which pair? enc_opportunity = FHE.compare(enc_price_impact, threshold) // opportunity exists? enc_backrun_size = FHE.compute_optimal(enc_reserves, enc_amount) // optimal size FHE Engine TFHE gates on 暗号文 STEP 4 Decrypt only: opportunity_exists (1 bit). If true: submit backrun_tx with enc_optimal_size to builder. backrun_tx (平文) STEP 5 Builder assembles [enc_user_tx, backrun_tx] bundle → block. Both txs commit atomically. bundle Searcher never learns: exact amount X, slippage Y, user identity — only "opportunity exists" (1 bit) Privacy guarantee: even if searcher colludes with builder, original Tx parameters remain encrypted until on-chain execution

TFHE Gate 操作 Required

// Pseudocode: FHE gate count for ブラインドアービトラージ
// 1. Extract token pair field (64-bit comparison in 暗号文 space)
enc_pair = TFHE.select_bits(enc_tx, offset=0, len=64)   // ~64 gates

// 2. Check validity constraint: amount > minimum
enc_valid = TFHE.compare_ge(enc_amount, MIN_AMOUNT)     // ~1,000 gates (128-bit)

// 3. Compute price impact on encrypted reserves
enc_impact = TFHE.div(enc_amount, enc_reserve_in)       // ~10,000 gates

// 4. Determine if opportunity profitable
enc_opp = TFHE.and(enc_valid, TFHE.compare_ge(enc_impact, THRESHOLD))

// Total: ~50,000-100,000 gate operations
// At ~1ms/gate (CPU 2024): 50-100 seconds total
// With GPU (10-100x): 0.5-10 seconds — still too slow for MEV

Current Limitations and Improvement Path

Problem 1: Latency

Gate count × 1ms/gate = 50-100 seconds on CPU. MEV requires sub-1 second to be competitive. Even with GPU (100ms), misses most opportunities.

Fix: ASIC/FPGA accelerators targeted for 2025-2027.

Problem 2: Key Management

Who holds the FHE private key? If user holds it: needs to be online. If network holds it: threshold key ceremony, MPC-based distributed decryption required.

Fix: Threshold FHE decryption (active research area).

Improvement Path

  1. Algorithmic: Reduce gate count via custom FHE circuits for AMM operations
  2. Hardware: GPU → FPGA → ASIC FHE accelerators
  3. Hybrid: FHE for outer privacy layer, ZKP for inner verification

Zama Ecosystem: fhEVM, Fhenix, Inco

Zama is the primary FHE infrastructure company in blockchain/DeFi. Founded by Pascal Paillier (of Paillier cryptosystem fame) and Nigel Smart (co-inventor of CKKS, Professor of Cryptography at KU Leuven). Raised $73M Series A (2023). Open-source tfhe-rs library is the de facto standard for TFHE in production.

tfhe-rs (Rust Library)

Open source TFHE library, maintained by Zama. Core building block for all FHE DeFi projects.

  • TFHE ブートストラッピング: ~100ms CPU, ~10ms GPU
  • Boolean gates: ~1ms per gate
  • Integer ops: 8-bit add ~50ms, compare ~200ms
  • 128-bit compare: 5-10 seconds

Open source (BSD-3)

fhEVM

FHE-powered Ethereum Virtual Machine. Smart contracts run on encrypted state. Developers write Solidity with encrypted types.

  • euint8, euint32, euint256, ebool
  • FHE operations as Solidity precompiles
  • Network validators run FHE computation collectively
  • No single party sees 平文 state

Early testnet (2024)

fhEVM Contract Example: Encrypted ERC-20

// Traditional ERC-20 — balances are PUBLIC
contract PublicToken {
    mapping(address => uint256) public balance; // visible to everyone

    function transfer(address to, uint256 amount) external {
        balance[msg.sender] -= amount; // readable by MEV bots
        balance[to] += amount;
    }
}

// fhEVM ERC-20 — balances are ENCRYPTED on-chain
contract PrivateToken {
    mapping(address => euint256) private encBalance; // encrypted 暗号文

    function transfer(address to, euint256 amount) external {
        // All operations are FHE — validators can't see amount
        encBalance[msg.sender] = FHE.sub(encBalance[msg.sender], amount);
        encBalance[to]         = FHE.add(encBalance[to], amount);
        // No 平文 is ever revealed during execution
    }

    function balanceOf(address owner) external view
        returns (euint256) {
        require(msg.sender == owner); // only owner can decrypt
        return encBalance[owner];     // returns 暗号文; owner decrypts locally
    }
}

Ecosystem: Who's Building on FHE

Fhenix

FHE-powered Ethereum L2 rollup. Uses Zama's fhEVM as execution layer. Developers deploy standard Solidity contracts with encrypted types. Targets DeFi applications where on-chain privacy is needed.

Testnet (2024)

Inco Network

Confidential computing layer. Integrates with existing EVM chains as a privacy middleware. Smart contracts can call into Inco for FHE operations, enabling existing L1/L2 apps to add encryption without full migration.

Early testnet

Zama's Concrete ML

FHE-enabled machine learning: train model in 平文, convert to FHE-compatible circuit, run inference on encrypted data. Applications: credit scoring on private financial data, medical AI with privacy.

Research + demos

Concrete Performance Numbers (2024)

Operation CPU Latency GPU Latency (est.) DeFi Practical?
Boolean AND (TFHE) ~1ms ~0.01ms Yes (single gates)
8-bit addition ~50ms ~0.5ms Near-term
8-bit comparison ~200ms ~2ms 封印された オークション
32-bit addition ~500ms ~5ms Near-term (non-RT)
128-bit addition ~2s ~20ms No (for RT MEV)
128-bit comparison ~5-10s ~50-100ms No (for RT MEV)
Full AMM swap computation ~minutes ~seconds No (needs ~1ms)
The 1000x gap: Real-time DeFi requires ~1ms latency. A full AMM swap in FHE takes minutes on CPU, seconds on GPU. Even with ASIC acceleration (projected 2026-2028), reaching 1ms for complex DeFi operations requires algorithmic improvements alongside hardware.

FHE vs MPC vs ZKP vs Differential Privacy

Different cryptographic privacy primitives serve different roles in the DeFi privacy stack. Understanding when to choose each is critical for system design.

Property FHE MPC ZKP Differential Privacy
Who computes One party (on 暗号文) Multiple parties jointly Prover alone Anyone (adds calibrated noise)
Interaction rounds 0 (non-interactive) Multiple (O(depth) rounds) 0 (non-interactive SNARK) 0
Computation cost Very high (1000-10000x overhead) High (network bandwidth + compute) Moderate (proving); low (verifying) Very low
Communication cost Low (暗号文 only) High (multi-round) Low (proof only) Minimal
Trust assumption Key holder Honest majority (threshold) Soundness of proof system Curator / noise mechanism
Data remains private Always (even from compute server) Yes (from any individual party) Input hidden; output may be public Statistically (epsilon-DP)
最適用途 Outsourced compute on private data Joint compute among distrusting parties Proving properties of private data Statistical privacy for aggregates
DeFi 適用 Dark pools (long-term), auctions (near) Dark pools (now: Renegade, Prime Match) KYC, compliance proofs, rollups AMM privacy, order aggregates
Maturity Research → early deployment Production (Prime Match) Production (many protocols) Production (Atlas-X)

Decision Guide: When to Use Each

Choose FHE when:

  • Computation can be delegated to a single (possibly untrusted) server
  • Low communication budget (non-interactive)
  • Latency tolerance: minutes/seconds acceptable (non-real-time)
  • Use cases: 封印された オークション, governance voting, private ML inference

Avoid for: real-time order matching, AMM swaps (too slow today)

Choose MPC when:

  • Multiple parties need to jointly compute without revealing inputs
  • Latency: can tolerate 10ms-1s round trips
  • Trust model: honest majority among a known set of parties
  • Use cases: ダークプール マッチング (Renegade, Prime Match), threshold signatures

最適用途: production dark pools today

Choose ZKP when:

  • Need to prove correctness of private computation (not hide it from all)
  • Verifier needs to check result without knowing inputs
  • Use cases: KYC compliance (zkKYC), private rollups, zk-identity, selective disclosure

最適用途: compliance proofs, identity verification

Choose DP when:

  • Statistical aggregate privacy is sufficient (not individual privacy)
  • Can tolerate bounded accuracy loss
  • Use cases: AMM fee parameter optimization (Atlas-X), order flow aggregates, market statistics

最適用途: aggregate statistics with formal privacy guarantees

DeFi Privacy Stack (Layered View)

DeFi Privacy Primitive Stack Application Layer — Dark Pool / DEX / Auction Renegade / Prime Match / FHE-MEV / fhEVM FHE Layer TFHE (compute on 暗号文) MPC Layer 2PC / Garbled Circuits (joint compute today) ZKP Layer Groth16 / PLONK (proof generation) DP Layer Laplace / Gaussian noise (aggregates) Network Privacy Dandelion / Tor (mempool) Cryptographic Foundation LWE / Ring-LWE hardness (FHE) | OT / GMW (MPC) | PCP / IOP (ZKP) | Mechanisms (DP) TODAY MPC in production NEAR-TERM FHE auctions/voting LONG-TERM FHE real-time DeFi

Roadmap to FHE-Practical DeFi

Realistic framing: FHE is not a near-term panacea. The performance gap between current FHE and real-time DeFi requirements is ~1000x. Hardware acceleration (GPU → FPGA → ASIC) and algorithmic improvements are both necessary. The timeline below reflects optimistic but realistic estimates.
FHE × DeFi — Practicality Roadmap 2023 2024 2025 2026 2027-28 2030+ Practical threshold FHE-MEV paper Passerat-Palmbach '23 Zama $73M Series A fhEVM testnet launch Fhenix / Inco testnet GPU FHE mainstream 10-100x speedup 封印された オークション practical (few ops) FHE voting governance, polls FPGA FHE accelerators 100-1000x vs CPU FHE dark pool basic price compare ASIC FHE chips ~1000x vs CPU Real-time FHE AMM / full DeFi (if breakthrough) Practical milestone Research milestone Hardware milestone Practicality threshold

Near-Term (1-3 years): What's Viable Now

Sealed Bid Auctions

Fewer FHE operations needed. Batch auction frequency (e.g. once per block) allows seconds of computation. fhEVM + Fhenix can demo this today.

Viable 2024-2025

Private Governance Voting

Vote tallying requires simple addition over ciphertexts. Latency of minutes is acceptable for governance (not real-time). First production FHE DeFi app likely here.

Viable 2025-2026

Encrypted State (Non-RT)

Zama fhEVM: smart contract state is encrypted, but transactions settle in seconds-to-minutes. Not real-time, but useful for privacy-sensitive data storage.

Testnet 2024, mainnet 2025?

Medium-Term (3-5 years): Hardware Acceleration Required

FHE Dark Pool (Basic)

With GPU + FPGA acceleration, 64-bit price comparison may reach 10-50ms. This enables basic order matching at low frequency (e.g. once per second). Requires: FHE comparison circuits optimized for prices, threshold decryption for match results.

Dependent on FPGA/ASIC timeline

FHE-MEV (Blind Arbitrage)

If GPU FHE reaches 100ms for 128-ビット操作, ブラインドアービトラージ becomes competitive for slow-moving opportunities. Latency-sensitive sandwiching remains out of reach. Likely deployed first on alt-L1s with longer block times.

Optimistic: 2026-2028

Long-Term (5-10+ years): Breakthrough Required

Real-Time FHE AMM / Full FHE Smart Contracts

Requires ~1ms latency for full DeFi operations. Current best: ~5-10 seconds for 128-bit comparison. Gap: 5,000-10,000x. Required improvements:

  • Hardware: Dedicated ASIC achieving ~1,000x over CPU (~10ms for 128-bit compare)
  • Algorithmic: Novel FHE schemes with 10x fewer gate operations
  • Combined: 10x algo × 1,000x hardware = 10,000x → ~1ms feasibility

Timeline: 5-10 years under optimistic assumptions, possibly never for some operations.

Long-term research goal

Current Research Frontiers (2024)

Cryptography

  • Threshold FHE: Distribute private key among validators (no single point of trust)
  • TFHE programmable ブートストラッピング: Arbitrary function evaluation per bootstrap
  • FHE-friendly primitives: Hash functions with low FHE gate count
  • Hybrid FHE+ZKP: FHE for privacy + ZKP for correctness verification

Systems / Hardware

  • GPU FHE ライブラリ: NuFHE, cuFHE — 10-100x speedup on A100
  • FPGA implementations: Intel/Xilinx designs for NTT acceleration
  • ASIC designs: CraterLake (MIT), F1 (MIT), BTS (Samsung) — academic prototypes
  • FHE compiler toolchains: Concrete (Zama), Cingulata, HEaaN compiler
Bottom line: FHE is the most powerful privacy primitive theoretically, but the farthest from DeFi practicality. MPC (Renegade, Prime Match) and ZKP (Aztec, privacy pools) solve the near-term problem. FHE's DeFi moment is likely 2028+ for simple applications, 2030+ for real-time — barring hardware breakthroughs. Watch: Zama fhEVM mainnet, ASIC announcements, threshold FHE schemes.