FHE 是 ZK 的下一步，加密技術的全新篇章
應用場景和落地是 FHE 成為區塊鏈基礎設施的突破口。作者：佐爺
加密貨幣的發展主線異常清晰，比特幣創造了加密貨幣，以太坊創造了公鏈，泰達公司創造了穩定幣，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 萬到 100 萬倍以上，而只有同時實現無限次的加法和乘法密文計算才能被稱為全同態加密，當然，各類同態加密在各自領域也有其獨特價值，按照實現程度的不同，可做如下劃分：
部分同態加密（Partially homomorphic encryption）：只允許對加密數據執行有限的操作集，如加法或乘法。某種同態加密（Somewhat homomorphic encryption）：允許有限數量的加法和乘法運算。
全同態加密（Fully homomorphic encryption）：允許無限數量的加法和乘法運算，從而實現對加密數據的任意計算。
全同態加密（FHE）的發展歷程可以追溯到 2009 年，Craig Gentry 首次提出了基於理想格的全同態算法，理想格是一種數學結構，它允許用戶定義一個多維空間中的點集，其中這些點滿足特定的線性關係。
在 Gentry 的方案中，使用理想格來表示密鑰和加密數據，從而使得加密數據可以在保持隱私的同時，並且使用自舉來降低噪音，自舉可以理解為「自己使勁揪自己的鞋帶，把自己翻過來」，實際操作上是通過對 FHE 加密後的密文再加一次密，達到降低噪音並維持保密性，以此支持複雜的計算操作。
（自舉是 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 領投的 7300 萬美元，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 仍在上下求索。可以按照和以太坊的關聯度遠近，分為三型：
Type 1：獨立王國，溝通以太。以 Zama/Fhenix/Inco network 為代表，主要是在提供開發基礎件，鼓勵自建 FHE L1/L2，適用於某些細分領域；
Type 2：外挂其上，融入以太。以 Fair Math/Mind Network 為代表，雖然保留一定的獨立性，但是整體思路是和以太坊進行更深度的融合。
Type 3：相約通行，改造以太。如果以太坊無法原生支持 FHE 功能，那麼需要在合約層進行探索，將 FHE 的功能散發到各 EVM 兼容鏈上，目前還沒有太符合該標準的方案。
和 ZK 發展到後期才出現一鍵發鏈和硬件加速實用化不同，FHE 站在了 ZK 巨人的肩上，現在發一條 FHE 鏈可能是最簡單的事，但是如何溝通自身和以太坊是最難的。
每日三省吾身，在區塊鏈世界中尋找 FHE 的未來坐標：
什麼場景必須加密，而不能使用明文？
什麼場景需要 FHE 加密，而不能使用其他加密方法？
什麼場景用完 FHE 加密用戶感覺良好，願意付出更高費用？
