加密貨幣的發(fā)展主線異常清晰，比特幣創(chuàng)造了加密貨幣，以太坊創(chuàng)造了公鏈，泰達(dá)公司創(chuàng)造了穩(wěn)定幣，BitMEX 創(chuàng)造了永續(xù)合約，四種創(chuàng)造如同加密原語搭建出萬億的市場，數(shù)不清的暴富神話，或者被人時刻銘記的去中心化的迷夢。
加密技術(shù)的發(fā)展軌跡卻不甚明了，各類共識算法，種種精巧的設(shè)計都敵不過質(zhì)押和多簽系統(tǒng)，而后者才是維持加密系統(tǒng)運轉(zhuǎn)的真正支柱，比如抽去中心化質(zhì)押的 WBTC 后，大部分 BTC L2 都無法存在，而 Babylon 的原生質(zhì)押是這個方向的探索，價值 7 千萬美元的探索。
我嘗試在本文中勾勒一種加密技術(shù)的發(fā)展史，這區(qū)別于加密行業(yè)的各類技術(shù)變遷過程，比如 FHE 和 ZK 以及 MPC 的關(guān)系，從一個粗略應(yīng)用的過程而言，MPC 用于開始，F(xiàn)HE 可以用于中間的計算過程，而 ZK 可以最終證明，而從應(yīng)用時間順序，則是 ZK 最早落地，之后 AA 錢包概念大火，MPC 作為一種技術(shù)方案得到重視，發(fā)展提速，唯獨 FHE 在 2020 年已經(jīng)被神施以喻言，但在 2024 年才略微起火。
MPC/FHE/ZKP
與 ZK 和 MPC 不同，F(xiàn)HE 甚至和當(dāng)前所有的加密算法都不同，除了 FHE 之外，任何的對稱或非對稱加密技術(shù)，都在試圖創(chuàng)造一個「不容易或無法破解的密碼系統(tǒng)」來達(dá)到絕對的安全，但是 FHE 的目標(biāo)是讓加密后的密文發(fā)揮作用，即加密和解密是重要的，但是加密后，解密前的內(nèi)容也不該浪費。
理論齊備，Web2 先于 Web3 落地
FHE 是一種基礎(chǔ)技術(shù)，并且在學(xué)術(shù)上已經(jīng)完成理論探索，Web2 巨頭出力頗多，比如微軟、英特爾、IBM 和 DARPA 支持的 Duality 已經(jīng)進(jìn)行軟硬件適配和開發(fā)工具的準(zhǔn)備。
有個好消息是，Web2 的巨頭們也并不知道該拿 FHE 來做什么，Web3 從現(xiàn)在起步不算晚，還有一個壞消息是 Web3 的適配約等于 0，主流的比特幣、以太坊都無法原生兼容 FHE 算法，盡管以太坊是世界計算機，但是硬算 FHE 恐怕要算到世界末日。
我們主要關(guān)注 Web3 的探索，只需要記住 Web2 巨頭們對 FHE 非常熱衷，并且已經(jīng)做了大量基礎(chǔ)工作即可。
這是因為 Vitalik 從 2020 年到 2024 年，重心都在 ZK 上。
這里要簡單闡釋下我對 ZK 的爆火歸因，在以太坊確立以 Rollup 的擴(kuò)容路線之后，ZK 的狀態(tài)壓縮功能可以極大減少 L2 向 L1 傳輸數(shù)據(jù)的大小，這在經(jīng)濟(jì)上具有巨大價值，當(dāng)然，這只是理論上的，L2 的碎片化以及排序器等問題，甚至部分 L2/Rollup 收割用戶手續(xù)費問題，這都屬于發(fā)展中的新問題，只能用繼續(xù)發(fā)展來解決。
簡單歸納下，即以太坊需要擴(kuò)容，確立了 Layer 2 發(fā)展路線，ZK/OP 系 Rollup 爭奇斗艷，形成短期 OP，長期 ZK 的行業(yè)共識，塑造出 ARB/OP/zkSync/SatrkNet 四大巨頭。
經(jīng)濟(jì)性是 ZK 能被加密世界，尤其是以太坊體系接納的重要原因，甚至是唯一原因，因而接下來的 FHE 技術(shù)特點不會贅述，重點是考察 FHE 能在哪些方向提高 Web3 的運轉(zhuǎn)效率，或者降低 Web3 的運作成本，降本和增效，總要占一個。
FHE 發(fā)展小史和成果
首先是區(qū)別同態(tài)加密和全同態(tài)加密，嚴(yán)格意義上而言，全同態(tài)加密是前者的一種特例，同態(tài)加密意味著「對密文的加法或乘法計算等同于對明文的加法或乘法計算」，即：
此時，c 和 E(c)，d 和 E(d) 可以視為等價值，但是要注意，這里的有兩個難點：
- 明文和密文的相等，其實是明文在加入一些噪音后，對其進(jìn)行進(jìn)行運算得到密文，如果密文導(dǎo)致的偏離值過大，則會導(dǎo)致計算失敗，因此控制噪音的各類算法的關(guān)鍵；
- 加法和乘法的開銷巨大，密文計算可能是明文計算的 1 萬到 100 萬倍以上，而只有同時實現(xiàn)無限次的加法和乘法密文計算才能被稱為全同態(tài)加密，當(dāng)然，各類同態(tài)加密在各自領(lǐng)域也有其獨特價值，按照實現(xiàn)程度的不同，可做如下劃分：
- 部分同態(tài)加密（Partially homomorphic encryption）：只允許對加密數(shù)據(jù)執(zhí)行有限的操作集，如加法或乘法。某種同態(tài)加密（Somewhat homomorphic encryption）：允許有限數(shù)量的加法和乘法運算。
- 全同態(tài)加密（Fully homomorphic encryption）：允許無限數(shù)量的加法和乘法運算，從而實現(xiàn)對加密數(shù)據(jù)的任意計算。
全同態(tài)加密（FHE）的發(fā)展歷程可以追溯到 2009 年，Craig Gentry 首次提出了基于理想格的全同態(tài)算法，理想格是一種數(shù)學(xué)結(jié)構(gòu)，它允許用戶定義一個多維空間中的點集，其中這些點滿足特定的線性關(guān)系。
在 Gentry 的方案中，使用理想格來表示密鑰和加密數(shù)據(jù)，從而使得加密數(shù)據(jù)可以在保持隱私的同時，并且使用自舉來降低噪音，自舉可以理解為「自己使勁揪自己的鞋帶，把自己翻過來」，實際操作上是通過對 FHE 加密后的密文再加一次密，達(dá)到降低噪音并維持保密性，以此支持復(fù)雜的計算操作。
（自舉是 FHE 實用化非常重要的技術(shù)進(jìn)步，但是數(shù)學(xué)知識不再展開）
這個算法是 FHE 的里程碑，首次在工程上證明了 FHE 的可行性，但是開銷巨大，甚至要三十分鐘才能運算一步，基本上沒有實用化的可能性。
從 0 到 1 解決后，剩下的只是大規(guī)模實用化，也可以理解為基于不同的數(shù)學(xué)假設(shè)，開展對應(yīng)的算法設(shè)計，除理想格外，被用于安全性假設(shè)的還有 LWE（Learning with Error）及其變種，也是目前最為常見的方案。
在 2012 年，Zvika Brakerski, Craig Gentry 和 Vinod Vaikuntanathan 提出了 BGV 方案，這是第二代 FHE 方案之一，其最重要的貢獻(xiàn)是模數(shù)轉(zhuǎn)換技術(shù)，這一技術(shù)有效地控制了同態(tài)運算帶來的密文噪聲增加，從而構(gòu)造了 Leveled FHE，即這樣的 FHE 可以實現(xiàn)給定計算深度的同態(tài)計算任務(wù)。
與之類似的還有 BFV 和 CKKS 等方案，尤其是 CKKS 方案可以支持浮點運算，但是會進(jìn)一步增強對算力資源的消耗，仍然需要更好的方案。
最后是 TFHE 和 FHEW 方案，尤其是 TFHE 方案，這是 Zama 的首選算法，我們對其進(jìn)行簡要介紹，簡單來說，F(xiàn)HE 的噪音問題可以通過 Gentry 首次應(yīng)用的自舉來降低，而 TFHE 可以做到高效自舉，并且在精度上有保障，因此和區(qū)塊鏈領(lǐng)域有較好的結(jié)合點。
我們對各方案的介紹點到為止，實際上他們之間的差異并不是優(yōu)劣之分，更多是場景不同，但是基本都需要強大的軟硬件資源支持，即使是 TFHE 方案，也需要解決硬件問題才能大規(guī)模應(yīng)用，基本上不可能沿襲 ZK 領(lǐng)域「算法和軟件先行，硬件和模塊化跟進(jìn)」的路徑，也就是從一開始 FHE 就要和硬件同步發(fā)展，至少在加密領(lǐng)域必然如此。
Web 2 OpenFHE vs Web3 Zama
前文提到 Web2 巨頭都在探索，也形成了一些實踐成果，這里對其進(jìn)行總結(jié)，并引入 Web3 的應(yīng)用場景。
刪繁就簡，IBM 貢獻(xiàn)了 Helib 庫，主要支持 BGV 和 CKKS，微軟的 SEAL 庫主要支持 CKKS 和 BFV 方案，值得一提的是， CKKS 作者之一的 Song Yongsoo 參與了 SEAL 的設(shè)計和開發(fā)，而 OpenFHE 是最為集大成者，由 DARPA 支持的 Duality 研發(fā)，目前支持 BGV、BFV、CKKS、TFHE 和 FHEW 等主流算法，估計是市場上現(xiàn)存的 FHE 庫中最為齊備的。
并且，OpenFHE 也探索過和因特爾的 CPU 加速庫合作，以及調(diào)用英偉達(dá)的 CUDA 接口，以支持 GPU 加速，但是 CUDA 對 FHE 最近的支持停留在 2018 年，暫時未找到更新的支持，如有錯訛，還請指正。
OpenFHE 支持 C++ 和 Python 兩種語言，Rust API 正在開發(fā)中，并且致力于提供簡單全面的模塊化和跨平臺能力，如果是 Web2 開發(fā)者，那么這是最簡單的開箱即用方案。
如果是 Web3 開發(fā)者，就要上上難度了。
受限于孱弱的運算能力，大部分公鏈無法支持 FHE 算法的執(zhí)行，其次是比特幣和以太坊生態(tài)目前缺乏對 FHE 的「經(jīng)濟(jì)需求」，再次強調(diào)，是先有了對 L2–>L1 高效傳輸數(shù)據(jù)的需求，才激發(fā)了 ZK 算法的落地，而不能為了 FHE 而 FHE ，這是拿著錘子敲釘子，強行的匹配，只會增加落地成本。
FHE+EVM 工作原理
后文會詳述目前遇到的困難和可能的落地場景，這里主要給 Web3 開發(fā)者一些信心。
2024 年 Zama 拿到了加密領(lǐng)域最大的一筆涉 FHE 概念融資，由 Multicoin 領(lǐng)投的 7300 萬美元，Zama 目前主要有基于 TFHE 算法庫，其次是 fhEVM 支持在其上開發(fā)具備 FHE 功能的 EVM 兼容鏈。
其次是效率問題，只能通過軟硬件合作解決，一個是 EVM 無法直接運行 FHE 合約，這和 Zama 的 fhEVM 方案并不沖突，Zama 的是自己搭建了一條鏈，可以直接把 FHE 功能原生加入進(jìn)去，比如 Shiba Inu 也要搭建基于 Zama 方案的 Layer 3，新造的鏈支持 FHE 并不困難，難的是以太坊 EVM 自身如何具備 FHE 合約部署能力，這需要以太坊的 Opcode（操作碼）支持，好消息是 Fair Math 和 OpenFHE 聯(lián)合舉辦了 FHERMA 競賽，鼓勵開發(fā)者改寫 EVM 的 Opcode，算是在積極探索結(jié)合可能性。
另一個是硬件加速，可以這樣說，即使 Solana 等高性能公鏈原生支持 FHE 合約部署，也會把其節(jié)點拖死，原生 FHE 硬件主要有 Chain Reaction 的 3PU?（隱私保護(hù)處理單元），屬于 ASIC 方案，其次是 Zama 或者 Inco 也在探索硬件加速的可能性，比如 Zama 現(xiàn)在的 TPS 是 5 左右，Inco 能做到 10 TPS，而 Inco 認(rèn)為使用 FPGA 硬件加速，可以將 TPS 提速到 100-1000 左右。
但是也無需過于擔(dān)憂速度問題，現(xiàn)有的 ZK 硬件加速方案，理論上都可以進(jìn)行改造以適配 FHE 方案，因此下文的討論中均不會過度設(shè)計速度問題，而主要是尋找場景和解決 EVM 兼容適配。
暗池玉殞，F(xiàn)HE X Crypto 未來可期
Multicoin 在領(lǐng)投 Zama 時曾豪言，ZKP 已是過去，未來屬于 FHE，未來是否成真，現(xiàn)實總是艱難，在 Zama 之后，Inco Network 和 Fhenix 組成了 fhEVM 生態(tài)隱形聯(lián)盟，方向各有側(cè)重，道路基本一致，即致力于 FHE 和 EVM 生態(tài)的融合。
做的早不如來得巧，我們先從一盆冷水開始。
2024 年也許是 FHE 的大年，而 2022 年起步的 Elusiv 已經(jīng)停止運行，Elusiv 最早是 Solana 上的「暗池」協(xié)議，現(xiàn)在代碼庫和文檔都被刪除。
說到底，F(xiàn)HE 作為技術(shù)組件的一部分，仍舊需要和 MPC/ZKP 等技術(shù)一起使用，而我們需要考察的是 FHE 究竟在哪些方面能改變區(qū)塊鏈的現(xiàn)行范式。
首先要承認(rèn)，單純認(rèn)為 FHE 會加強隱私所以具備經(jīng)濟(jì)價值并不準(zhǔn)確，從過往的實踐來看，Web3 或鏈上用戶沒有那么在乎隱私，只有在隱私可以提供經(jīng)濟(jì)價值時才會使用相關(guān)工具，比如，黑客為了隱藏盜取資金才會使用 Tornado Cash，而普通用戶只會使用 Uniswap，因為使用 Tornado Cash 會付出額外的時間或經(jīng)濟(jì)成本。
FHE 的加密成本，本身就是對鏈上本就孱弱的運行效率的進(jìn)一步折磨，只有當(dāng)這種拉高成本會帶來更顯著的收益，保護(hù)隱私才具備大規(guī)模推廣的可能性，比如 RWA 方向的債券發(fā)行和交易，比如 2023 年 6 月，中銀國際通過瑞銀，在香港向亞太客戶發(fā)行了「區(qū)塊鏈數(shù)字化結(jié)構(gòu)票據(jù)」，并在瑞銀新聞稿中指出是通過以太坊進(jìn)行，但是神奇的是找不到該交易的合約地址和分發(fā)地址，如果有誰能找到，歡迎補充相關(guān)信息。
這個例子可以顯性說明 FHE 的重要性，對于機構(gòu)級客戶，他們有使用區(qū)塊鏈等公鏈的需求，但是并不適合或想要公開全部信息，那么 FHE 這種密文顯示，并可直接進(jìn)行買賣等操作的特性就會比 ZKP 更適合。
而對于個人散戶而言，F(xiàn)HE 目前仍舊是比較遙遠(yuǎn)的底層基礎(chǔ)設(shè)施，我可以列幾個方向，比如抗 MEV ，隱私交易，更安全的網(wǎng)絡(luò)，防止第三方窺探等等，但顯然這都不是第一性需求，并且現(xiàn)在使用 FHE 確實會讓網(wǎng)絡(luò)變慢，不如坦率說 FHE 的主角時刻還未到來。
說到底，隱私是不痛不癢的需求，作為公共服務(wù)，很少人愿意為隱私溢價付費，我們需要找到利用 FHE 加密后的數(shù)據(jù)可計算特性能節(jié)約成本或提升交易效率的場景，從而產(chǎn)生市場自發(fā)的助推力。比如抗 MEV 的解決方案有很多種，比如中心化節(jié)點其實就可以解決，F(xiàn)HE 并不能直擊場景痛點。
另外一個問題是計算效率的問題，表面上看這是需要硬件加速或者算法優(yōu)化的技術(shù)問題，但本質(zhì)上這是市場沒太大需求，項目方?jīng)]有卷的動力，計算效率說到底都是卷出來的，還是以 ZK 為例，在蓬勃的市場需求下，SNARK 和 STARK 路線互相比拼，各類 ZK Rollup 從編程語言到兼容性玩命開卷，ZK 的發(fā)展在熱錢催熟下一日千里。
應(yīng)用場景和落地是 FHE 成為區(qū)塊鏈基礎(chǔ)設(shè)施的突破口，如果邁不出這一步，F(xiàn)HE 將永遠(yuǎn)無法在加密行業(yè)成勢，各大項目方也就只能敲敲邊鼓，在自己的一畝三分地自娛自樂了。
從Zama 和他的朋友們的實踐來看，一個共識是以太坊外做新鏈，并將 ERC-20 等技術(shù)組件和標(biāo)準(zhǔn)復(fù)用其上，形成 FHE L1/L2 鏈接以太坊的加密方案，這種方案的好處是可以先行先試，打造 FHE 的基礎(chǔ)組件，劣勢在于如果以太坊自身不支持 FHE 算法，那么鏈外方案始終會處于比較尷尬的境地。
Zama 自身也認(rèn)識到這個問題，在前述提及的 FHE 相關(guān)類庫外，也發(fā)起了 FHE.org 組織，并贊助了相關(guān)會議，希望能將更多學(xué)術(shù)成果轉(zhuǎn)化為工程應(yīng)用。
Inco Network 的發(fā)展方向是「通用隱私計算層」，本質(zhì)上是一種計算外包服務(wù)商模式，基于 Zama 搭建了 FHE EVM L1 網(wǎng)絡(luò)，一個有趣的探索是和跨鏈消息協(xié)議 Hyperlane 合作，可以將另外一條 EVM 兼容鏈上的游戲機制部署在 Inco 之上，在游戲運行時需要用到 FHE 計算時，通過 Hyperlane 調(diào)用 Inco 的計算能力，隨后只將結(jié)果回傳原鏈。
實現(xiàn) Inco 設(shè)想中的此類場景，需要滿足 EVM 兼容鏈愿意相信 Inco 的信譽，并且 Inco 自身的計算能力要足夠強，在鏈游這種高并發(fā)、低延時的需求中，能否真的良好運作是具有相當(dāng)挑戰(zhàn)性的。
由此引申下，某些 zkVM 其實也可以承當(dāng) FHE 計算外包商的角色，比如 RISC Zero 便已經(jīng)具備該能力，ZK 系產(chǎn)品和 FHE 的下一步碰撞也許有更多火花可以迸發(fā)。
更進(jìn)一步，某些項目希望能更靠近以太坊一點點，至少朝著成為以太坊的一部分方向前進(jìn)，Inco 能用 Zama 方案實現(xiàn) L1，F(xiàn)henix 就能用 Zama 方案實現(xiàn) EVM L2，其目前還在發(fā)展中，看起來想做的方向有很多，不知道最終落地會是什么產(chǎn)品，也許是一條主打 FHE 能力的 L2 吧。
此外還有上文提及的 FHERMA 競賽，讀者中有精通以太坊開發(fā)的程序員可以去試試，幫助 FHE 落地的同時還有獎金拿。
此外，還有 Sunscreen 和 Mind Network 這兩個比較神奇的項目，Sunscreen 主要由 Ravital 一個人運營，方向是用 BFV 算法打造適合 FHE 的編譯器方案，但是長期處于測試和實驗狀態(tài)，距離產(chǎn)品實用化尚需時日。
最后，Mind Network 的思路主要集中在 FHE 和各現(xiàn)有場景，如再質(zhì)押的結(jié)合上，但具體如何實現(xiàn)還需要時間來驗證。
最后的最后，回收下本節(jié)開頭，Elusiv 現(xiàn)在更名為 Arcium，還拿到了新的融資，轉(zhuǎn)型成為「并行 FHE 」方案，這是要從執(zhí)行效率上對 FHE 進(jìn)行改進(jìn)。
結(jié)語
本文看似是在講 FHE 的理論和實踐，但暗線是厘清加密技術(shù)自身的發(fā)展史，這不完全等同于加密貨幣用到的技術(shù)，ZKP 和 FHE 有很多相似點，其中之一是都在致力于讓區(qū)塊鏈保持公開特性之外保有隱私設(shè)計，而 ZKP 隱私方案指向的是降低 L2 <> L1 之間交互的經(jīng)濟(jì)成本，而 FHE 仍在尋找自己的最佳場景。
各方案分型
路漫漫其修遠(yuǎn)兮，F(xiàn)HE 仍在上下求索。可以按照和以太坊的關(guān)聯(lián)度遠(yuǎn)近，分為三型：
- Type 1：獨立王國，溝通以太。以 Zama/Fhenix/Inco network 為代表，主要是在提供開發(fā)基礎(chǔ)件，鼓勵自建 FHE L1/L2，適用于某些細(xì)分領(lǐng)域；
- Type 2：外掛其上，融入以太。以 Fair Math/Mind Network 為代表，雖然保留一定的獨立性，但是整體思路是和以太坊進(jìn)行更深度的融合。
- Type 3：相約通行，改造以太。如果以太坊無法原生支持 FHE 功能，那么需要在合約層進(jìn)行探索，將 FHE 的功能散發(fā)到各 EVM 兼容鏈上，目前還沒有太符合該標(biāo)準(zhǔn)的方案。
和 ZK 發(fā)展到后期才出現(xiàn)一鍵發(fā)鏈和硬件加速實用化不同，F(xiàn)HE 站在了 ZK 巨人的肩上，現(xiàn)在發(fā)一條 FHE 鏈可能是最簡單的事，但是如何溝通自身和以太坊是最難的。
每日三省吾身，在區(qū)塊鏈?zhǔn)澜缰袑ふ?FHE 的未來坐標(biāo)：
- 什么場景必須加密，而不能使用明文？
- 什么場景需要 FHE 加密，而不能使用其他加密方法？
- 什么場景用完 FHE 加密用戶感覺良好，愿意付出更高費用？
未完待續(xù)，我會保持對 FHE 的關(guān)注！