FHE是ZK的下一步，加密技術的終局？

加密貨幣的發展主線異常清晰，比特幣創造了加密貨幣，以太坊創造了公鏈，泰達公司創造了穩定幣，BitMEX 創造了永續合約，四種創造如同加密原語搭建出萬億的市場，數不清的暴富神話，或是被人時時刻刻記得的去中心化的迷夢。

加密技術的發展軌跡卻不甚明了，各類共識演算法，種種精巧的設計都敵不過質押和多簽系統，而後者才是維持加密系統運轉的真正支柱，例如抽去中心化質押的WBTC 後，大部分BTC L2 都無法存在，而Babylon 的原生質押是這個方向的探索，價值7 千萬美元的探索。

我嘗試在本文中勾勒一種加密技術的發展史，這區別於加密行業的各類技術變遷過程，例如FHE 和ZK 以及MPC 的關係，從一個粗略應用的過程而言，MPC 用於開始，FHE可以用於中間的計算過程，而ZK 可以最終證明，而從應用時間順序，則是ZK 最早落地，之後AA 錢包概念大火，MPC 作為一種技術方案得到重視，發展提速，唯獨FHE 在2020 年已經被神施以喻言，但在2024 年才略微起火。

 MPC/FHE/ZKP

與ZK 和MPC 不同，FHE 甚至和目前所有的加密演算法都不同，除了FHE 之外，任何的對稱或非對稱加密技術，都在試圖創造一個「不容易或無法破解的密碼系統」來達到絕對的安全，但FHE 的目標是讓加密後的密文發揮作用，即加密和解密是重要的，但加密後，解密前的內容也不該浪費。

理論齊備，Web2 先於Web3 落地

FHE 是一種基礎技術，並且在學術上已經完成理論探索，Web2 巨頭出力頗多，例如微軟、英特爾、IBM 和DARPA 支援的Duality 已經進行軟硬體適配和開發工具的準備。

有個好消息是，Web2 的巨頭們也不知道該拿FHE 來做什麼，Web3 從現在起步不算晚，還有一個壞消息是Web3 的適配約等於0，主流的比特幣、以太坊都無法原生相容FHE 演算法，儘管以太坊是世界計算機，但是硬算FHE 恐怕要算到世界末日。

我們主要關注Web3 的探索，只需要記住Web2 巨頭們對FHE 非常熱衷，並且已經做了大量基礎工作。

這是因為Vitalik 從2020 年到2024 年，重心都在ZK 上。

這裡要簡單闡釋下我對ZK 的爆火歸因，在以太坊確立以Rollup 的擴容路線之後，ZK 的狀態壓縮功能可以極大減少L2 向L1 傳輸數據的大小，這在經濟上具有巨大價值，當然，這只是理論上的，L2 的碎片化以及排序器等問題，甚至部分L2/Rollup 收割用戶手續費問題，這都屬於發展中的新問題，只能用繼續發展來解決。

簡單歸納下，即以太坊需要擴容，確立了Layer 2 發展路線，ZK/OP 系Rollup 爭奇鬥艷，形成短期OP，長期ZK 的行業共識，塑造出ARB/OP/zkSync/SatrkNet 四大巨頭。

經濟性是ZK 能被加密世界，尤其是以太坊系統接納的重要原因，甚至是唯一原因，因而接下來的FHE 技術特點不會贅述，重點在於考察FHE 能在哪些方向提高Web3 的運作效率，或者降低Web3 的運作成本，降本和增效，總要佔一個。

FHE 發展小史與成果

首先是區別同態加密和全同態加密，嚴格意義上而言，全同態加密是前者的一種特例，同態加密意味著「對密文的加法或乘法計算等同於對明文的加法或乘法計算”，即：

此時，c 和E(c)，d 和E(d) 可以視為等價值，但要注意，這裡的有兩個困難：

1. 明文和密文的相等，其實是明文在加入一些雜訊後，對其進行進行運算得到密文，如果密文導致的偏離值過大，則會導致計算失敗，因此控制雜訊的各類演算法的關鍵；
2. 加法和乘法的開銷巨大，密文計算可能是明文計算的1 萬到100 萬倍以上，而只有同時實現無限次的加法和乘法密文計算才能被稱為全同態加密，當然，各類同態加密在各自領域也有其獨特價值，依實現程度的不同，可做如下劃分：

• 部分同態加密（Partially homomorphic encryption）：只允許對加密資料執行有限的操作集，如加法或乘法。某種同態加密（Somewhat homomorphic encryption）：允許有限數量的加法和乘法運算。
• 全同態加密（Fully homomorphic encryption）：允許無限數量的加法和乘法運算，從而實現加密資料的任意計算。

全同態加密（FHE）的發展歷程可以追溯到2009 年，Craig Gentry 首次提出了基於理想格的全同態演算法，理想格是一種數學結構，它允許使用者定義一個多維空間中的點集，其中這些點滿足特定的線性關係。

在Gentry 的方案中，使用理想格來表示密鑰和加密數據，從而使得加密數據可以在保持隱私的同時，並且使用自舉來降低噪音，自舉可以理解為「自己使勁揪自己的鞋帶，把自己翻過來”，實際操作上是透過對FHE 加密後的密文再加一次密，達到降低噪音並維持保密性，以此支持複雜的計算操作。

這個演算法是FHE 的里程碑，首次在工程上證明了FHE 的可行性，但是開銷巨大，甚至要三十分鐘才能運算一步，基本上沒有實用化的可能性。

從0 到1 解決後，剩下的只是大規模實用化，也可以理解為基於不同的數學假設，開展對應的演算法設計，除理想格外，被用於安全性假設的還有LWE（Learning with Error ）及其變種，也是目前最常見的方案。

在2012 年，Zvika Brakerski, Craig Gentry 和Vinod Vaikuntanathan 提出了BGV 方案，這是第二代FHE 方案之一，其最重要的貢獻是模數轉換技術，這項技術有效地控制了同態運算帶來的密文雜訊增加，從而建構了Leveled FHE，即這樣的FHE 可以實現給定計算深度的同態計算任務。

與之類似的還有BFV 和CKKS 等方案，尤其是CKKS 方案可以支援浮點運算，但會進一步增強對算力資源的消耗，仍然需要更好的方案。

最後是TFHE 和FHEW 方案，尤其是TFHE 方案，這是Zama 的首選演算法，我們對其進行簡要介紹，簡單來說，FHE 的噪音問題可以透過Gentry 首次應用的自舉來降低，而TFHE 可以做到高效自舉，並且在精度上有保障，因此和區塊鏈領域有較好的結合點。

我們對各方案的介紹點到為止，實際上他們之間的差異並不是優劣之分，更多是場景不同，但是基本上都需要強大的軟硬體資源支持，即使是TFHE 方案，也需要解決硬件問題才能大規模應用，基本上不可能沿襲ZK 領域「演算法和軟體先行，硬體和模組化跟進」的路徑，也就是從一開始FHE 就要和硬體同步發展，至少在加密領域必然如此。

Web 2 OpenFHE vs Web3 Zama

前文提到Web2 巨頭都在探索，也形成了一些實踐成果，這裡進行總結，並引入Web3 的應用場景。

刪繁就簡，IBM 貢獻了Helib 函式庫，主要支援BGV 和CKKS，微軟的SEAL 函式庫主要支援CKKS 和BFV 方案，值得一提的是， CKKS 作者之一的Song Yongsoo 參與了SEAL 的設計和開發，而OpenFHE 是最為集大成者，由DARPA 支持的Duality 研發，目前支援BGV、BFV、CKKS、TFHE 和FHEW 等主流演算法，估計是市場上現存的FHE 庫中最為齊備的。

並且，OpenFHE 也探索過和因特爾的CPU 加速庫合作，以及調用英偉達的CUDA 接口，以支持GPU 加速，但是CUDA 對FHE 最近的支持停留在2018 年，暫時未找到更新的支持，如有錯訥，還請指正。

OpenFHE 支援C++ 和Python 兩種語言，Rust API 正在開發中，並且致力於提供簡單全面的模組化和跨平台能力，如果是Web2 開發者，那麼這是最簡單的開箱即用方案。

如果是Web3 開發者，就要上難度了。

受限於孱弱的運算能力，大部分公鏈無法支持FHE 演算法的執行，其次是比特幣和以太坊生態目前缺乏對FHE 的“經濟需求”，再次強調，是先有了對L2-->L1高效傳輸資料的需求，才激發了ZK 演算法的落地，而不能為了FHE 而FHE ，這是拿著錘子敲釘子，強行的匹配，只會增加落地成本。

 FHE+EVM 工作原理

後文會詳述目前遇到的困難和可能的落地場景，主要給Web3 開發者一些信心。

2024 年Zama 拿到了加密領域最大的一筆涉FHE 概念融資，由Multicoin 領投的7,300 萬美元，Zama 目前主要有基於TFHE 演算法庫，其次是fhEVM 支援在其上開發具備FHE 功能的EVM 相容鏈。

其次是效率問題，只能透過軟硬體合作解決，一個是EVM 無法直接運作FHE 合約，這和Zama 的fhEVM 方案並不衝突，Zama 的是自己搭建了一條鏈，可以直接把FHE 功能原生加入進去，例如Shiba Inu 也要搭建基於Zama 方案的Layer 3，新造的鏈支援FHE 並不困難，難的是以太坊EVM 本身如何具備FHE 合約部署能力，這需要以太坊的Opcode（操作碼）支持，好消息是Fair Math 和OpenFHE 共同舉辦了FHERMA 競賽，鼓勵開發者改寫EVM 的Opcode，算是積極探索結合可能性。

另一個是硬體加速，可以這麼說，即使Solana 等高效能公鏈原生支援FHE 合約部署，也會把其節點拖死，原生FHE 硬體主要有Chain Reaction 的3PU™（隱私保護處理單元），屬於ASIC方案，其次是Zama 或Inco 也在探索硬體加速的可能性，例如Zama 現在的TPS 是5 左右，Inco 能做到10 TPS，而Inco 認為使用FPGA 硬體加速，可以將TPS 提速到100-1000 左右。

但也無需過於擔憂速度問題，現有的ZK 硬體加速方案，理論上都可以進行改造以適配FHE 方案，因此下文的討論中均不會過度設計速度問題，而主要是尋找場景和解決EVM 兼容適配。

暗池玉殞，FHE X Crypto 未來可期

Multicoin 在領投Zama 時曾豪言，ZKP 已是過去，未來屬於FHE，未來是否成真，現實總是艱難，在Zama 之後，Inco Network 和Fhenix 組成了fhEVM 生態隱形聯盟，方向各有側重，道路基本一致，即致力於FHE 和EVM 生態的融合。

做的早不如來得巧，我們先從一盆冷水開始。

2024 年也許是FHE 的大年，而2022 年起步的Elusiv 已經停止運行，Elusiv 最早是Solana 上的「暗池」協議，現在程式碼庫和文件都被刪除。

說到底，FHE 作為技術組件的一部分，仍舊需要和MPC/ZKP 等技術一起使用，而我們需要考察的是FHE 究竟在哪些方面能改變區塊鏈的現行範式。

首先要承認，單純認為FHE 會加強隱私所以具備經濟價值並不準確，從過往的實踐來看，Web3 或鏈上用戶沒有那麼在乎隱私，只有在隱私可以提供經濟價值時才會使用相關工具，例如，駭客為了隱藏盜用資金才會使用Tornado Cash，而一般用戶只會使用Uniswap，因為使用Tornado Cash 會付出額外的時間或經濟成本。

FHE 的加密成本，本身就是對鏈上本就孱弱的運行效率的進一步折磨，只有當這種拉高成本會帶來更顯著的收益，保護隱私才具備大規模推廣的可能性，比如RWA 方向的債券發行和交易，例如2023 年6 月，中銀國際透過瑞銀，在香港向亞太客戶發行了“區塊鏈數位化結構票據”，並在瑞銀新聞稿中指出是透過以太坊進行，但是神奇的是找不到交易的合約地址和分發地址，如果有誰能找到，歡迎補充相關資訊。

這個例子可以顯性說明FHE 的重要性，對於機構級客戶，他們有使用區塊鏈等公鏈的需求，但是並不適合或想要公開全部信息，那麼FHE 這種密文顯示，並可直接進行買賣等操作的特性就會比ZKP 更適合。

而對於個人散戶而言，FHE 目前仍舊是比較遙遠的底層基礎設施，我可以列幾個方向，比如抗MEV ，隱私交易，更安全的網絡，防止第三方窺探等等，但顯然這都不是第一性需求，現在使用FHE 確實會讓網路變慢，不如坦白說FHE 的主角時刻還沒到來。

說到底，隱私是不痛不癢的需求，作為公共服務，很少人願意為隱私溢價付費，我們需要找到利用FHE 加密後的資料可計算特性能節省成本或提升交易效率的場景，從而產生市場自發的助推力。例如抗MEV 的解決方案有很多種，例如中心化節點其實可以解決，FHE 並不能直擊場景痛點。

另外一個問題是計算效率的問題，表面上看這是需要硬體加速或是演算法優化的技術問題，但本質上這是市場沒太大需求，專案方沒有捲的動力，計算效率說到底都是捲出來的，還是以ZK 為例，在蓬勃的市場需求下，SNARK 和STARK 路線互相比拼，各類ZK Rollup 從程式語言到相容性玩命開卷，ZK 的發展在熱錢催熟下一日千里。

應用場景與落地是FHE 成為區塊鏈基礎設施的突破口，如果邁不出這一步，FHE 將永遠無法在加密產業成勢，各大專案方也只能敲敲邊鼓，在自己的一畝三分地自娛自樂了。

從Zama 和他的朋友們的實踐來看，一個共識是以太坊外做新鏈，並將ERC-20 等技術組件和標準復用其上，形成FHE L1/L2 鏈接以太坊的加密方案，這種方案的好處是可以先行先試，打造FHE 的基礎元件，劣勢在於如果以太坊本身不支援FHE 演算法，那麼鏈外方案總是會處於比較尷尬的境地。

Zama 本身也意識到這個問題，在前述提及的FHE 相關類庫外，也發起了FHE.org 組織，並贊助了相關會議，希望能將更多學術成果轉化為工程應用。

Inco Network 的發展方向是“通用隱私計算層”，本質上是一種計算外包服務商模式，基於Zama 搭建了FHE EVM L1 網絡，一個有趣的探索是和跨鏈消息協議Hyperlane 合作，可以將另外一條EVM 相容鏈上的遊戲機制部署在Inco 之上，在遊戲運行時需要用到FHE 計算時，透過Hyperlane 調用Inco 的計算能力，隨後只將結果回傳原鏈。

實現Inco 設想中的此類場景，需要滿足EVM 相容鏈願意相信Inco 的信譽，並且Inco 自身的計算能力要足夠強，在鏈遊這種高並發、低延時的需求中，能否真的良好運作是具有相當挑戰性的。

由此引申下，某些zkVM 其實也可以承當FHE 運算外包商的角色，例如RISC Zero 便已經具備該能力，ZK 系列產品和FHE 的下一步碰撞也許有更多火花可以迸發。

更進一步，某些項目希望能更靠近以太坊一點點，至少朝著成為以太坊的一部分方向前進，Inco 能用Zama 方案實現L1，Fhenix 就能用Zama 方案實現EVM L2，其目前還在發展中，看起來想做的方向很多，不知道最終落地會是什麼產品，也許是一條主打FHE 能力的L2 吧。

另外還有上文提及的FHERMA 競賽，讀者中有精通以太坊開發的程式設計師可以去試試，幫助FHE 落地的同時還有獎金拿。

此外，還有Sunscreen 和Mind Network 這兩個比較神奇的項目，Sunscreen 主要由Ravital 一個人運營，方向是用BFV 演算法打造適合FHE 的編譯器方案，但是長期處於測試和實驗狀態，距離產品實用化尚需時日。

最後，Mind Network 的想法主要集中在FHE 和各現有場景，如再質押的結合上，但具體如何實現還需要時間來驗證。

最後的最後，回收下本節開頭，Elusiv 現在更名為Arcium，還拿到了新的融資，轉型成為「並行FHE 」方案，這是要從執行效率上對FHE 進行改進。

結語

本文看似是在講FHE 的理論和實踐，但暗線是釐清加密技術本身的發展史，這不完全等同於加密貨幣用到的技術，ZKP 和FHE 有很多相似點，其中之一是都在致力於讓區塊鏈保持公開特性之外保有隱私設計，而ZKP 隱私方案指向的是降低L2 <> L1之間互動的經濟成本，而FHE 仍在尋找自己的最佳場景。

各方案分型

路漫漫其修遠兮，FHE 仍在上下求索。可以依照和以太坊的關聯度遠近，分為三型：

1. Type 1：獨立王國，溝通以太。以Zama/Fhenix/Inco network 為代表，主要是在提供開發基礎件，鼓勵自建FHE L1/L2，適用於某些細分領域；
2. Type 2：外掛其上，融入以太。以Fair Math/Mind Network 為代表，雖然保留一定的獨立性，但整體想法是和以太坊進行更深度的融合。
3. Type 3：相約通行，改造以太。如果以太坊無法原生支援FHE 功能，那麼需要在合約層進行探索，將FHE 的功能散發到各EVM 相容鏈上，目前還沒有太符合該標準的方案。

和ZK 發展到後期才出現一鍵發鍊和硬體加速實用化不同，FHE 站在了ZK 巨人的肩上，現在發一條FHE 鏈可能是最簡單的事，但是如何溝通自身和以太坊是最難的。

每日三省吾身，在區塊鏈世界中尋找FHE 的未來座標：

1. 什麼場景必須加密，不能使用明文？
2. 什麼場景需要FHE 加密，而不能使用其他加密方法？
3. 什麼場景用完FHE 加密用戶感覺良好，願意付出更高費用？

未完待續，我會保持對FHE 的關注！