全同態加密（FHE）被譽為“密碼學的聖杯”，但目前其應用受到性能、開發體驗和安全性方面的限制。

作者：Jeffrey Hu、Arnav Pagidyala

核心觀點

· 全同態加密（FHE）被譽為“密碼學的聖杯”，但目前其應用受到性能、開發體驗和安全性方面的限制。

· 如上圖所示，為了構建一個真正保密且安全的共享狀態系統，需要將FHE與零知識證明（ZKPs）和多方計算（MPC）結合使用。

· FHE正在迅速發展；新的編譯器、庫、硬體等的開發，以及Web2公司（如英特爾、谷歌、DARPA等）的研發大大促進了FHE的發展。

· 隨著FHE及其周邊生態系統的成熟，我們預計“可驗證的FHE”將成為標準。去中心化應用程式（DApps）/rollups可能選擇將計算和驗證外包給FHE輔助運算器。

· 鏈上FHE的一個基本限制是“誰持有解密密鑰”。閾值解密（Threshold decryption）和MPC提供了針對這種限制的解決方案，但它們通常有需要在性能與安全性之間權衡的問題。

引言

區塊鏈的透明性是一把雙刃劍。雖然其開放性和可觀察性很有吸引力，但這也恰恰是企業採用區塊鏈技術時的顧慮所在。

鏈上隱私一直是加密領域近十年來最具挑戰性的問題之一。儘管有許多團隊正在構建基於零知識證明（ZKP）的系統來實現鏈上隱私；但它們無法支持共享的加密狀態。原因在於這些方案是一系列ZKP的函數，因此不可能對當前狀態應用任意邏輯。這意味著我們不能僅僅使用ZKP來構建加密的共享狀態應用程式（比如私有的Uniswap）。

然而，最近的技術突破錶明，將ZKP與全同態加密（FHE）相結合，可以實現完全通用化、加密的去中心化金融（DeFi）。這是如何實現的呢？FHE是一個新興的密碼學領域，能夠在加密數據上進行任意計算。如上圖所示，ZKP可以證明用戶輸入和計算的完整性，而FHE可以處理計算本身。

雖然FHE被譽為“密碼學的聖杯”，我們將試圖提供對該領域及其各種挑戰及可能解決方案的客觀分析。該技術報告將涵蓋以下鏈上FHE主題：

1. FHE方案、庫和編譯器（FHE Schemes, Libraries and Compilers）

2.安全閾值解密（Secure Threshold Decryption）

3.用戶輸入和計算方的ZKP（ZKPs for User Inputs + Computing Party）

4.可編程、可擴展的數據可用性（DA）層（Programmable, Scalable DA Layer）

5. FHE硬體（FHE Hardware）

全同態加密（FHE）方案、庫和編譯器

挑戰：新興的FHE方案、庫和編譯器

鏈上FHE的基本瓶頸在於其開發工具和基礎設施的滯後。與零知識證明（ZKP）或多方計算（MPC）不同，FHE自2009年以來發展時間較短，因此成熟度較低。

FHE開發體驗的主要限制包括：

· 缺少易於使用的前端語言，讓開發者在不需要深入瞭解後端密碼學的情況下進行編碼。

· 缺少功能齊全的FHE編譯器，能夠處理所有複雜的工作（如參數選擇、BGV/BFV的SIMD優化和並行優化）。

· 現有的FHE方案（特別是TFHE）與普通計算相比大約慢1000倍。

為了真正理解整合FHE的複雜性，讓我們來看一下開發者所要經歷的流程：

將FHE整合到應用程式中的第一步是選擇一個FHE方案。下表解釋了主要的方案：

如上表所示，布爾電路（如FHEW和TFHE）具有最快的bootstrapping 速度，可以避免複雜的參數選擇過程，並且可以用於任意/通用計算，但相對較慢；而BGV/BFV適合一般DeFi應用，因為它們在高精度算術計算方面更高效，但開發者必須提前知道電路的深度以設置scheme的所有參數。另一方面，CKKS支持同態乘法，允許精度誤差，使其適用於非精確用例，如機器學習。

作為開發者，你需要非常謹慎地選擇一個FHE方案，因為它將影響所有其他設計決策和未來的性能。此外，還有幾個關鍵參數對於正確設置FHE方案至關重要，例如模數大小的選擇和多項式次數的作用。

接下來我們討論庫，下表展示了目前使用較多的FHE庫的功能和能力：

但是，這些庫與不同的FHE方案和編譯器的關係也各不相同，如下所示：

選擇了FHE方案後，開發者需要設置參數。正確選擇參數將對FHE方案的性能產生巨大影響。比較困難的是，這需要對抽象代數、FHE特定操作（如重新線性化和模數切換）以及算術或二進制電路有所瞭解。最後，為了有效選擇參數，需要從概念上理解它們如何影響FHE方案。

此時，開發者可能會問：

我的明文（plaintext）空間需要多大？可以接受多大的密文？我在哪裡可以並行計算？等等問題……

此外，儘管FHE可以支持任意計算，但開發者在編寫FHE程式時需要改變思維方式。例如，程式中不能根據變量寫一個分支（if-else），因為程式不能將變量視為普通數據進行直接比較。相反，開發者需要將代碼從分支改為可以包含所有分支條件的某種計算。同樣，這也阻止了開發者在代碼中編寫迴圈。

簡而言之，對於不熟悉FHE的開發者來說，將FHE整合到他們的應用程式中幾乎是不可能的。這將需要顯著的開發工具和基礎設施來抽象化FHE所呈現的複雜性。

解決方案：

1. Web3特定的FHE編譯器

雖然已經存在由谷歌和微軟等公司構建的FHE編譯器，但它們：

· 沒有以性能為設計目標，與直接編寫電路相比增加了1000倍的“開銷”

· 為CKKS（即ML）優化，對於DeFi所需的BFV/BGV並不那麼有益

· 不是為Web3構建的。不支持與ZKP方案、可編程區塊鏈等的相容性。

直到Sunscreen FHE編譯器的出現。它是一個Web3原生編譯器，為算術操作（例如DeFi）提供了一些最佳性能，而不需要硬體加速器。如上所述，參數選擇可能是實施FHE方案最困難的部分。Sunscreen不僅自動化了參數選擇，還實現了數據編碼、密鑰選擇、實施重新線性化和模數切換、設置電路和實現SIMD操作。

隨著技術的不斷進步，我們期待看到不僅在Sunscreen編譯器中，還有其他團隊構建屬於自己的，能夠支持其他高級語言的進一步優化。

2.新的FHE庫

雖然研究人員不斷探索新的有效方案，但FHE庫也可以使更多開發者整合FHE。

以FHE智慧合約為例。儘管從不同的FHE庫中進行選擇可能很困難，但當我們談論鏈上FHE時，選擇就變得更容易了，因為在Web3中只有少數幾種主導編程語言。

例如，Zama的fhEVM將Zama的開源庫TFHE-rs集成到典型的EVM中，將同態操作作為預編譯合約公開。有效地使開發者能夠在他們的合約中使用加密數據，而無需對編譯工具進行任何更改。

而對於其他特定場景，可能還需要一些其他基礎設施。例如，用C++編寫的TFHE庫維護得不如Rust版本好。儘管TFHE-rs可以支持C/C++的導出，但如果C++開發者想要更好的相容性和性能，他們必須編寫自己的TFHE庫版本。

最後，市場缺乏FHE基礎設施的一個核心原因是我們缺少有效的方式來構建FHE-RAM。一個可能的解決方向是針對一個沒有某些操作碼的FHE-EVM進行研究。

安全閾值解密（Secure Threshold Decryption）

挑戰：不安全/中心化的閾值解密

每個保密的共享狀態系統都基於加密和解密密鑰。由於不能信任任何單一方，因此解密密鑰在網路參與者之間通過多方計算（MPC）進行分片。

鏈上全同態加密（FHE）最具挑戰性的方面之一是構建一個安全且高性能的閾值解密協定。主要有兩個瓶頸：

（1）基於FHE的計算引入了顯著的“開銷”，因此需要高性能的節點，這本質上減少了驗證者集合的潛在規模；

（2）隨著參與解密協定的節點數量增加，延遲也會增加。

至少目前為止，FHE協定依賴於驗證者中的大多數是誠實的（honesty majority），然而如上所述，鏈上FHE意味著較小的驗證者集合，因此存在更高的串謀和惡意行為的可能性。

如果閾值節點串謀作惡怎麼辦？它們將能夠繞過協定，基本上解密任何東西，包括用戶輸入到任何鏈上數據。此外，更要注意的是在當前系統中解密協定可以不被察覺地發生（即“無聲攻擊”）。

解決方案：改進的閾值解密或動態MPC

有幾種可能的方法來解決閾值解密的缺點。

（1）啟用n/2閾值，這將使串謀更加困難；

（2）在硬體安全模塊（HSM）內運行閾值解密協定；

（3）使用基於受信任執行環境（TEE）的閾值解密網路，由去中心化鏈控制認證，允許動態密鑰管理。

與其利用閾值解密，更可能的情況是使用MPC。一個在鏈上FHE中可以使用的MPC協定的現象級的例子：Odsy的新的2PC-MPC，這是第一個非串謀且大規模去中心化的MPC算法。

另一種方法可能是僅使用用戶的公鑰來加密數據。然後驗證者處理同態操作，必要時用戶自己可以解密結果。雖然這只適用於特定的使用案例，但我們完全可以避免閾值假設。

總結來說，鏈上FHE需要一個高效的MPC實現，這種實現具備如下特點：

（1）即使在存在惡意行為者的情況下也能工作；

（2）引入最小的延遲；

（3）允許無需許可/靈活的節點加入。

用戶輸入和計算方的零知識證明（ZKP）

挑戰：用戶輸入和計算的可驗證性：

在Web2世界中，當我們請求執行一個計算任務時，我們完全信任某個公司會按照他們承諾的方式在幕後運行這個任務。在Web3中，這個模型完全顛倒了。我們不再依賴公司的聲譽並簡單地相信他們會誠信做事，而是在一個無需信任的環境中運作，這意味著用戶不應該需要信任任何人。

雖然全同態加密（FHE）允許處理加密數據，但它無法驗證用戶輸入或計算的正確性。如果沒有驗證的能力，FHE在區塊鏈的背景下幾乎沒有用處。

解決方案：用戶輸入和計算方的ZKP：

雖然FHE允許任何人對加密數據進行任意計算，但ZKP允許人們在不透露底層資訊本身的情況下證明某事是真實的。那麼它們是如何相關的呢？

FHE和ZKP結合在一起有三個關鍵方式：

1.用戶需要提交一個證明，表明他們的輸入密文是正確的格式。這意味著密文符合加密方案的要求，而不僅僅是任意的數據字串。

2.用戶需要提交一個證明，表明他們的輸入明文滿足給定應用程式的條件。例如，賬戶餘額大於轉賬金額。

3.驗證節點（即計算方）需要證明他們已正確執行FHE計算。這被稱為“可驗證的FHE”，可以看作是rollups所需ZKP的類比。

為了進一步探索ZKP的應用：

1.密文的ZKP

FHE建立在基於格（lattice-based）的密碼學上，這意味著加密原語的構造涉及格（lattice），這些格是後量子（post-quantum）安全的。相比之下，流行的ZKP，如SNARKs、STARKs和Bulletproofs，並不依賴於基於格的密碼學。

為了證明用戶的FHE密文格式正確，我們需要展示它滿足某個帶有環中元素（entries from rings）的矩陣-向量方程，並且這些元素的數值是小的。本質上，我們需要一個為處理基於格關係（lattice-based relations）而設計的、在鏈上驗證成本效率高的證明系統，這是一個開放的研究領域。

2.明文輸入的ZKP

除了證明格式正確的密文外，用戶還需要證明他們的輸入明文滿足應用程式的要求。幸運的是，與之前的步驟不同，我們可以利用通用的SNARKs來證明用戶輸入的有效性，從而使開發者能夠利用現有的ZKP方案、庫和基礎設施。

然而，挑戰在於我們需要“連接”這兩個證明系統。連接意味著我們需要確保用戶對兩個證明系統使用了相同的輸入。否則，惡意用戶可能會欺騙協定。這裡需要再次強調，這是一個極其困難的密碼學壯舉，也是一個早期研究的開放領域。

Sunscreen已經為此奠定了基礎，他們的ZKP編譯器支持Bulletproofs，因為它最容易與SDLP連接。針對“連接”FHE和ZKP編譯器的研究也在不斷推進。

Mind Network一直在引領ZKP的整合，以確保零信任輸入和輸出，同時利用FHE進行安全計算。

3.正確計算的ZKP

在現有硬體上運行的FHE極其低效和昂貴。正如我們之前所見的可擴展性三難問題的動態表現，那些對節點資源要求較高的網路無法擴展到足夠的去中心化水準。一個可能的解決方案是一個被稱為“可驗證的FHE”的過程，其中計算方（驗證者）提交一個ZKP來證明交易的誠實執行。

一個可驗證的FHE的早期原型可以通過一個名為SherLOCKED的專案展示。本質上，FHE計算被載入到Risc ZERO的Bonsai zkVM上，該VM在鏈下處理加密數據上的計算，並返回帶有ZKP的結果，並在鏈上更新狀態。

舉一個利用FHE輔助運算器的最近的例子：Aztec的鏈上拍賣演示。正如我們之前所討論的，現有的FHE鏈使用閾值密鑰加密整個狀態，這意味著系統的強度僅取決於其閾值委員會（threshold committee）。相反，在Aztec中，用戶擁有自己的數據，因此不受閾值安全假設的約束。

最後，重要的是要了解開發者可以在哪裡首先構建FHE應用程式。開發者可以在FHE支持的L1、FHE rollup上構建他們的應用程式，或者在任何EVM鏈上構建並利用FHE輔助運算器。每種設計都有其自身的權衡，但我們更傾向於設計良好的FHE rollups（由Fhenix開創）或FHE輔助運算器，因為它們從以太坊中繼承了安全性等其他好處。

直到最近，在FHE加密數據上實現欺詐證明還是複雜的，但最近Fhenix.io的團隊展示瞭如何使用Arbitrum Nitro堆棧與FHE邏輯編譯到WebAssembly來實現欺詐證明。

FHE的數據可用性（DA）層

挑戰：缺乏可定製性和吞吐量

雖然在Web2中“存儲”已經商品化，但在Web3中情況並非如此。考慮到全同態加密（FHE）維持著超過10000倍的數據膨脹，我們需要確定在哪裡存儲大量的FHE密文。如果給定的DA層中的每個節點操作者都要下載並存儲每個FHE鏈的數據，那麼只有機構操作者才能跟上需求，從而增加了中心化的風險。

關於吞吐量，Celestia的最高速度為6.7 MB/s，如果我們想運行任何形式的FHEML，我們將需要每秒數GB的帶寬。根據1k(x)最近分享的數據，由於設計決策限制了吞吐量（有意為之），現有的DA層無法支持FHE。

解決方案：水準擴展+可定製性

我們需要一個能夠支持水準可擴展性的DA層。現有的DA架構將所有數據傳播到網路中的每個節點，這是可擴展性的一個主要限制。相反，隨著更多DA節點進入系統，水準可擴展性意味著每個節點存儲的數據量減少，隨著更多區塊空間的可用，性能和成本得到改善。

另外，考慮到與FHE相關的大量數據的大小，為開發者提供更高級別的糾刪碼閾值（erasure coding thresholds）定製化是有意義的。換句話說，開發者對DA系統的保證感到什麼程度的舒適？是基於權益的加權還是基於去中心化的加權。

EigenDA的架構可以作為FHE的DA層某種可能性的一個基礎。它的水準擴展性、結構成本降低、DA和共識的解耦等屬性，都為能夠支持FHE的可擴展性水準鋪平了道路。

最後，一個更高維度的想法可能是為存儲FHE密文構建優化的存儲槽，因為密文遵循特定的編碼方案，所以擁有優化的存儲槽可能有助於高效使用存儲空間和更快的檢索。

全同態加密（FHE）硬體

挑戰：低性能的全同態加密（FHE）硬體

在鏈上全同態加密（FHE）應用的推廣中，一個主要問題是由於計算開銷導致的顯著延遲，這使得在任何標準處理硬體上運行FHE變得不切實際。這種限制源自於與內存的大量交互，這是由於處理器需要處理巨大的數據量。除了內存交互外，複雜的多項式計算和耗時的密文維護操作也帶來了大量的開銷。

為了深入理解FHE加速器的狀態，我們需要揭開其中具體設計的面紗：針對特定應用的FHE加速器與可泛化的FHE加速器。

FHE的計算複雜性和硬體設計的核心始終與給定應用所需的乘法數量有關，稱為“同態操作的深度”。在特定應用的情況下，深度是已知的，因此係統參數和相關計算是固定的。因此，針對特定應用的硬體設計將更容易，並且通常可以優化以獲得比可泛化加速器設計更好的性能。在一般情況下，如果需要FHE支持任意數量的乘法，需要引入bootstrapping技術來移除同態操作中積累的部分噪音。bootstrapping技術代價比較高，需要大量硬體資源，包括晶片內存、內存帶寬和計算，這意味著硬體設計將與特定應用的設計大不相同。因此，儘管英特爾、Duality、SRI、DARPA等行業重要參與者在GPU和ASIC設計方面的工作無疑在提高上限，但它們可能無法一對一地應用於支持區塊鏈場景。

在開發成本方面，可泛化硬體需要位元定應用的硬體更多的資本進行設計和製造，但其靈活性允許硬體在更廣泛的應用範圍內使用。另一方面，對於特定應用的設計，如果應用的需求變化並需要支持更深層次的同態計算，則需要將特定應用的硬體與一些軟體技術（如MPC）結合使用，以實現與可泛化硬體相同的目的。

值得注意的是，與特定應用用例（例如FHEML）相比，鏈上FHE的加速要困難得多，因為它需要能夠處理更一般的計算，而不是更具特定性的集合。例如，fhEVM開發網路目前的交易處理速度僅限於個位數TPS。

鑑於我們需要針對區塊鏈定製的FHE加速器，另一個考慮因素是：從ZKP硬體到FHE硬體的可轉移性到底如何？

ZKP和FHE之間存在一些共同的模塊，例如數論變換（NTT）和底層的多項式操作。然而，這兩種情況中使用的NTT的位寬（bit width）不同。在ZKP中，硬體需要支持NTT的多種位寬，例如64位和256位，而在FHE中，由於使用了剩餘數系統，NTT的操作數較短。其次，ZKP中處理的NTT degree通常高於FHE。由於這兩個原因，設計一個同時對ZKP和FHE都有令開發者滿意的性能的NTT模塊並非易事。除了NTT之外，FHE中還存在一些其他的計算瓶頸，如自同構（automorphism），這些在ZKPs中並不存在。將ZKP硬體簡單轉移到FHE設置的一種方法是將NTT計算任務載入到ZKP硬體上，並使用CPU或其他硬體處理FHE中的其餘計算。

總結這些挑戰，使用FHE在加密數據上進行計算曾經比在明文數據上慢100,000倍。然而，由於較新的加密方案和FHE硬體的最新發展，目前的性能已經顯著提高到比明文數據慢大約100倍。

解決方案：

1. FHE硬體的改進

許多團隊正在積極構建FHE加速器，但他們並未專注於特定於可泛化區塊鏈計算（例如TFHE）的FHE加速器。一個針對區塊鏈的特定硬體加速器示例是FPT，一種固定點FPGA加速器。FPT是第一個重度利用FHE計算中固有噪音的硬體加速器，它完全使用近似的固定點算術實現TFHE引導。另一個對FHE可能有用的專案是BASALISC，這是一個旨在雲端大幅加速FHE計算的硬體加速器架構的系列。

正如前面提到的，FHE硬體設計中的一個主要瓶頸是與內存的大量交互。為了繞過這個障礙，一個潛在的解決方案是盡可能減少與內存的交互。處理器內存（PIM）或近內存計算（near memory computation）可能在這種情況下有所幫助。PIM是應對未來電腦系統的“內存牆（memory wall）”挑戰的有希望的解決方案，它允許內存同時承擔計算和存儲功能，承諾對計算與內存關係進行根本性改革。在過去十年中，設計解決此問題的非易失性內存方面取得了巨大進展，例如電阻式RAM、自旋轉移扭矩磁性RAM和相變記憶體。使用這種特殊內存，已有研究顯示在機器學習和基於格的公鑰加密中顯著改善了計算性能。

2.優化的軟體和硬體

在最近的發展中，軟體被公認為硬體加速過程中的一個關鍵組成部分。例如著名的FHE加速器，如F1和CraterLake，使用編譯器進行混合軟硬體共同設計。

隨著這一領域的發展，我們可以期待與針對區塊鏈的FHE編譯器共同設計的功能齊全的編譯器。FHE編譯器可以根據相應FHE方案的成本模型優化FHE程式。這些FHE編譯器可以與FHE加速器編譯器集成，通過結合硬體級別的成本模型，改善端到端性能。

3.網路FHE加速器：從垂直擴展到水準擴展

現有的針對FHE硬體加速的努力主要集中在“垂直擴展”，即專注於單個加速器的垂直改進。另一方面，“水準擴展”則關注於通過網路橫向連接多個FHE加速器，這可能會大大提高性能，類似於與零知識證明（ZKPs）的並行證明生成。

FHE加速的一個主要困難是數據膨脹問題：指的是在加密和計算過程中發生的數據大小顯著增加，為晶片內和晶片外存儲器之間的高效數據傳輸帶來挑戰。

數據膨脹對通過網路橫向連接多個FHE加速器構成了顯著的挑戰。因此，FHE硬體與網路的共同設計將是未來研究的一個有前景的方向。例如針對FHE加速器的自適應網路路由：實現一種基於即時計算負載和網路流量，來動態調整FHE加速器之間數據路徑的路由機制。這將確保最佳的數據傳輸速率和高效的資源利用。

結束語

FHE將從根本上重新構建我們在各個平臺上保護數據的方式，為一個前所未有的隱私新時代鋪平道路。構建這樣一個系統將需要在FHE、零知識證明（ZKPs）和多方計算（MPC）上取得重大進展。

當我們進入這個新領域時，密碼學家、軟體工程師和硬體專家之間的協作努力將是必不可少的。更不用說立法者、監管機構等，因為合規性是實現主流採用的唯一途徑。

歸根結底，FHE將站在數字主權變革浪潮的前沿，預示著一個數據隱私和安全不再是相互排斥而是密不可分的未來。

特別鳴謝

非常感謝Mason Song（Mind Network）、Guy Itzhaki（Fhenix）、Leo Fan（Cysic）、Kurt Pan、Xiang Xie（PADO）、Nitanshu Lokhande（BananaHQ）的審閱。我們期待讀者能去了解這些人在該領域所做的令人印象深刻的工作和努力！