1. 何為FHE？

FHE (Fully homomorphic encryption)：

• 是一種隱私技術(shù)，支持直接對密文進(jìn)行計算，而無需對密文先解密再計算。
• 即，任何第三方或云廠商，都可對敏感信息的密文進(jìn)行處理，而無需訪問密文內(nèi)的任何明文數(shù)據(jù)。

1.1 FHE歷史

FHE歷史演變路徑為：

• Ronald Rivest、Leonard Adleman 和 Mike Dertouzos 于1978年 On Data Banks and Privacy Homomorphisms 論文中，提出了“基于密文計算”的概念。
• 2009年Craig Gentry 在其博士論文 A fully homomorphic encryption scheme 中，構(gòu)建了首個支持通用電路的方案——通過加法和乘法來實例化FHE。

2. FHE用例

FHE可用于：

• 隱私加強(qiáng)：如用于機(jī)器學(xué)習(xí)、云計算、FHE+ZKP+MPC實現(xiàn)鏈上gambling、加密搜索和數(shù)據(jù)庫操作。
• 鏈上私有交易、私有智能合約、專注隱私的VM如FHEVM等。

2.1 何為專注隱私的VM？

以下將“專注隱私的VM”稱為“加密VM”。
加密VM環(huán)境支持：

• 上傳合約S和交易T
• 計算S(T)，在不公開S和（或）T的情況下，來做資產(chǎn)轉(zhuǎn)移、swap等。
  • 如，某些云廠商提供合約隱私，某些云廠商提供數(shù)據(jù)隱私，而有的云廠商同時提供合約隱私和數(shù)據(jù)隱私。

實現(xiàn)加密VM的挑戰(zhàn)在于：

• 1）Overheads開銷
• 2）Breaking composability突破現(xiàn)有組合性
• 3）Breaking dev tools突破現(xiàn)有開發(fā)工具
• 4）Regulatory監(jiān)管

2.1.1 Overheads

• 需要將program轉(zhuǎn)換為“FHE-friendly”表示，如只包含加法和乘法門的電路。相比于直接計算，這引入了大量的開銷。
• 對每個電路執(zhí)行密碼學(xué)運(yùn)算，將單個操作符，替換為，一系列基于大數(shù)的復(fù)雜運(yùn)算。這仍會增加開銷。

具體區(qū)間與具體的計算，以上步驟將增加數(shù)十倍的開銷。

2023年9月，Intel聲稱正在開發(fā)對FHE運(yùn)算高效的定制芯片：

• Intel plans custom accelerator chip, model for encrypted computing

挑戰(zhàn)在于，該算法仍在進(jìn)化，且有大量的參數(shù)選型。Sergey Gorbunov參與了2019年的 Homomorphic Encryption Standard 制定。至今仍有一些選型未完成。

電路設(shè)計的挑戰(zhàn)在于需要非常準(zhǔn)確的域和運(yùn)算，來最大限度地利用固定電路拓?fù)洹?/p>

有沒有什么“突破”使FHE成為現(xiàn)實？當(dāng)前還沒有。

• 正在算法和優(yōu)化方面進(jìn)行扎實但漸進(jìn)的改進(jìn)。從必須將程序轉(zhuǎn)換為某種形式的THE友好表示（這將增加開銷）到必須對更大的數(shù)字進(jìn)行計算，這一切都不會改變。

2.1.2 Breaking composability

隱私破壞了可組合性。

• 不能像編寫公共數(shù)據(jù)[和程序]那樣編寫私有數(shù)據(jù)。
• 也就是說，加密交易不能像明文值那樣在智能合約中使用——接收加密交易的程序不能調(diào)用另一個程序，也不能向僅通過明文值操作的程序發(fā)送存款。這使得在一個生態(tài)之上構(gòu)建另一生態(tài)更具挑戰(zhàn)性。

2.1.3 Breaking dev tools

似乎很少有人討論這一點(diǎn)，但在加密的領(lǐng)域中不可能有相同的監(jiān)控/調(diào)試工具。如，

• 假設(shè)客戶打電話說“我的交易沒有通過”。要調(diào)試此語句，需要知道問題是否與數(shù)據(jù)編碼、加密、程序評估或管道中的其他任何地方有關(guān)。如果沒有對數(shù)據(jù)本身的可見性（客戶一開始就試圖隱藏數(shù)據(jù)），這是非常具有挑戰(zhàn)性的。

2.1.4 Regulatory

已經(jīng)看到了保護(hù)隱私的token和網(wǎng)絡(luò)的問題?？赡軙驗榫帉懺撥浖龅铰闊?。監(jiān)管機(jī)構(gòu)將如何接收和分類完全加密的環(huán)境還有待觀察。

3. FHE的當(dāng)前瓶頸

FHE的當(dāng)前瓶頸有：

• 1）為加強(qiáng)計算安全性，在加密期間會給密文添加一些“noise噪聲”。
• 2）當(dāng)密文中累積了過多“噪聲”時，會因過噪，而影響輸出的精度。
• 3）Bootstrapping自舉 是一種常用去噪技術(shù)，但其是計算密集型的。
• 4）不同的解決方案正在探索，在不給設(shè)計施加太多約束的情況下，有效去噪的方法，包括TFHE、CKKS、BGV等。

4. FHE領(lǐng)域項目

當(dāng)前，FHE領(lǐng)域項目有：

• @zama_fhe：TFHE + fhEVM
• @FhenixIO：FHE L2 + coprocessor
• @Privasea_ai：Ai X FHE
• @octra：HFHE L1
• @inconetwork：FHE L1
• @Fair_Block：Modular FHE solution
• @mindnetwork_xyz：Depin + AI X FHE
• @SunscreenTech：FHE compiler
• @zkHoldem：Gambling with FHE

5. FHE領(lǐng)域前景展望

將ZK推向今天的水平總共花費(fèi)了大約10億美元——這是一個很大的興奮和潛力，但還有更多的生產(chǎn)用例有待觀察。Sergey預(yù)計FHE將需要大約相同的資金才能達(dá)到目前的水平[需要大約9億VC]。這是因為軟件棧的類似部分需要重寫，而且可以說需要重寫更多。

Sergey認(rèn)為工程師應(yīng)該關(guān)注更多的垂直用例，并考慮端到端的開發(fā)人員體驗。當(dāng)然，考慮通用VM環(huán)境是有利可圖的，但其應(yīng)針對特定的工作負(fù)載進(jìn)行優(yōu)化。

誰將為保護(hù)隱私的固有管理費(fèi)用支付美元（工程、維護(hù)和執(zhí)行成本）還有待觀察。

FHE領(lǐng)域需要更多的資金、更多的工程師、實用的用例和簡單的開發(fā)環(huán)境。

參考資料

[1] Poopman 2024年4月7日twitter A simple explanation of FHE (Fully homomorphic encryption) 🥷🧾
[2] Sergey Axelar 2024年3月9日twitter To FHE, or not to FHE, that is the question.
[3] Sergey 2024年3月9日博客 To FHE, or not to FHE, that is the question.

FHE系列博客

• 技術(shù)探秘：在RISC Zero中驗證FHE——由隱藏到證明：FHE驗證的ZK路徑（1）
• 基于[Discretized] Torus的全同態(tài)加密指引（1）
• 基于[Discretized] Torus的全同態(tài)加密指引（2）
• TFHE——基于[Discretized] Torus的全同態(tài)加密 代碼解析
• 技術(shù)探秘：在RISC Zero中驗證FHE——RISC Zero應(yīng)用的DevOps（2）
• FHE簡介
• Zama TFHE-rs
• Zama TFHE-rs白皮書（1）
• Zama TFHE-rs白皮書（2）
• ZK系統(tǒng)內(nèi)隱私 VS. FHE系統(tǒng)內(nèi)隱私
• ZK vs FHE