一文讀懂FHE-Rollups：第一個基於FHE的Rollup架構

Fhenix引入了全同態加密（FHE）Rollup的概念：一種用於執行任意機密智慧合約的更具可擴展性的技術。最近的研究表明FHE是為智慧合約添加機密性的可行解決方案。然而，這些工作限制了可擴展性，因為它們需要網路中的所有節點執行 FHE計算並就加密狀態達成共識。

受到乙太坊生態系統中最近轉向L2解決方案發展的啟發，Fhenix提出了第一個基於FHE的Rollup架構。我們認為，FHE對於明文計算Rollup是一個必要的解決方案，儘管在FHE背景下，計算開銷要高出幾個數量級。

在我們的設計中，我們採用樂觀Rollup方法，使我們能夠避免由最先進的可驗證FHE技術帶來的數量級損失。事實上，我們的框架可以被視為解決同樣問題的加密經濟解決方案。

專注於乙太坊生態系統，我們提出並克服了基礎層仲裁非EVM原生欺詐證明的挑戰。我們無需對乙太坊進行任何更改即可實現這一目標，這表明乙太坊上的原生FHE Rollup確實是可能的。我們構建了一個部分概念驗證，使用Arbitrum的Nitro證明者和Zama的 tfhe-rs庫來演示這一點。

一、引言

前言

這是Fhenix 關於 FHE Rollups 的“滾動白皮書”的第一個版本（v0.1）。它是一份有生命力的檔，我們會滾動更新和擴展，包括納入來自我們不斷壯大的社區以及外部研究人員的回饋。

區塊鏈以信任最小化的方式（即不信任任何中心化運營商）確保正確執行和抗審查，但代價是資料機密性。本質上，鏈上的所有資料都是公開的，因為所有節點都需要看到資料才能達成共識。儘管普遍認為，這種極端的透明度只是系統的副產品，而不是系統的目標，而且它在很大程度上限制了我們可以構建的用例類型，因為我們無法構建任何需要利用敏感性資料的應用程式。

近年來，研究人員和從業者在一系列被稱為機密智慧合約的工作中採用了多種隱私保護技術來解決區塊鏈的機密性問題。在所有這些技術中，全同態加密（FHE）可能是最雄心勃勃的，因為它允許直接計算加密資料而無需解密。自從Gentry在大約十五年前提出第一個構造以來，FHE已經取得了突飛猛進的進步。儘管如此，與明文計算相比，FHE 需要大量的計算開銷，這使得在L1執行不切實際，其中每個節點都需要複製整個計算，而這也是最先進的基於FHE 的機密智慧合約框架正在採用的方法。

受到乙太坊生態系統中最近轉向L2解決方案發展的啟發，我們提出了第一個基於FHE的Rollup架構。我們認為，FHE對於明文計算Rollup是一個必要的解決方案，儘管在FHE背景下，計算開銷要高出幾個數量級。在Rollup架構中，智能合約執行（驗證區塊的繁重部分）與驗證執行和達成共識是分開的。這確保只有單個節點（或少量節點）實際上在執行繁重的計算工作，而不會降低安全性。此外，該節點可以根據需要垂直（和水準）擴展，包括利用更昂貴的專用硬體（GPU、ASIC）。後者在基於ZK的Rollup中很常見 ，與FHE一樣，它也利用計算密集型密碼學，並且可以以與 FHE 計算大致相同的方式利用。

然而，在我們的設計中，我們採用樂觀Rollup方法而不是zk-rollup 方法，這使我們能夠避免由最先進的可驗證FHE技術帶來的數量級損失。事實上，我們的框架可以被視為解決同樣問題的加密經濟解決方案。

1.1 貢獻

在本文中，我們做出了以下主要貢獻： 

• 推出Fhenix，第一個L2機密智慧合約平臺，可實現更高的效率和可擴展性。 
• 我們通過概念驗證實施證明，可以在乙太坊之上構建樂觀FHE rollup，而無需對基礎層進行任何更改。雖然我們的工作超出了乙太坊和 EVM 鏈的範圍，但表明這在今天的乙太坊上是可能的，這意味著最常用的智慧合約生態系統可以通過機密智慧合約來增強。 
• 在區塊鏈背景之外，我們的解決方案可以被視為解決可驗證FHE問題的更有效（加密經濟）解決方案。 

1.2 相關工作

我們的工作建立在現有的機密智慧合約平臺研發機構的基礎上。與所有其他工作不同，據我們所知，我們是第一個描述完全且原生作為L2運行的解決方案。更具體地說，其他機密智慧合約平臺通常因其使用的隱私保護技術的種類而有所不同：

• 基於可信執行環境(TEE)。目前，生產中唯一的機密智慧合約網路使用的是TEE（或安全飛地secure enclaves）。這些網路通過允許使用者使用安全飛地（secure enclaves）內保存的金鑰來加密其交易來類比安全計算。然後，交易在安全飛地（secure enclaves）內被解密並執行，只要我們可以信任 TEE 的安全性，就可以確保機密性。雖然 TEE 是迄今為止最有效的解決方案，但它們容易受到旁道攻擊和其他漏洞的影響。 

• 基於安全多方計算(MPC)。由於我們的工作依賴於 Threshold FHE，因此我們與這些工作共用類似的威脅模型。然而，出於演示的目的，我們將它們與基於FHE的解決方案分開，因為它們通常依賴於線性金鑰共用和亂碼電路技術（garbled circuits techniques）。與我們的工作相比，這些技術的主要缺點是MPC協定需要傳輸與電路大小成比例的資料才能對其進行評估。在基於金鑰共用的MPC情況下，所有參與方在評估乘法門時還需要順序地與所有其他參與方進行通信。在公鏈背景下，這是不切實際的，因為延遲非常高並且頻寬有限。 此外，由於這些系統的每個合約執行都需要多個交互節點，因此它們不適合我們提議的Rollup架構。 

• 基於ZK。不同的工作考慮了使用不同 ZK 方案的機密智慧合約。然而，由於 ZK 技術更適合可驗證計算，因此它們在機密智慧合約中的效用受到限制。為了克服這個問題，Hawk建議設立一個資料管理器——一個鏈外機構，其任務是收集不同客戶的輸入，並被信任可以查看每個人的資料。或者，其他平臺對開發人員施加限制。 

• 基於FHE。在過去幾年中，由於FHE性能的顯著改進，基於 HE 和 FHE 的解決方案開始出現。這些平臺與我們的工作最接近，但它們都沒有採用Rollup架構，這限制了它們在實踐中的可擴展性。其中一些工作像我們一樣採用閾值FHE結構，而其他工作允許有限的功能，但沒有共用的全域加密金鑰對。 

二、基礎部分

2.1 Rollups

Rollups是一種擴展解決方案，旨在緩解主 L1 （尤其是乙太坊）的擁塞。隨著乙太坊使用者群的不斷增長，對擴展解決方案的需求變得至關重要。可擴展性的主要目標是在不影響去中心化或安全性的情況下提高交易速度和輸送量。Rollup在基礎層之外執行交易，發回狀態更新以及正確執行的證明。最終，L1（在我們的例子中是乙太坊）就這些狀態更新達成共識，但它不需要在基礎層上重新執行交易。換句話說，L2 Rollup 上的交易受到乙太坊固有安全性的保護。Rollup 有兩種主要類型，其不同之處在於證明的創建和驗證方式： 

• 樂觀Rollup。其假設交易除非受到質疑，否則都是有效的。他們將計算移至鏈外，但將交易資料發佈到乙太坊，允許任何人在鏈外重新運行交易並自行驗證執行是否正確。如果任何驗證者檢測到惡意行為，他們可以在鏈上提交欺詐證明，在這種情況下，L1 充當最終仲裁者。因此，樂觀Rollup需要一個爭議期（通常為幾天）。 

• ZK Rollup。這些Rollup類似地在鏈外執行合約，並在發送狀態更新時提交有效性證明。有效性證明是使用稱為（簡潔）ZK 證明的先進加密技術構建的。它們可以直接在鏈上進行有效驗證，無需發佈完整的交易資料或存在爭議期。 

Optimistic和 ZK Rollups本質上有不同的權衡。樂觀Rollup會受到爭議期延遲的影響，從而導致最終結果更長。它們還需要將交易本身發佈到鏈上，這抵消了一些可擴展性優勢。

另一方面，ZK Rollups 需要大量的計算能力（和時間）來生成證明，尤其是當你嘗試原生EVM 時。一個相關的缺點是這些Rollup的構建要複雜得多，從而導致大量代碼。因此，zkEVM 出現嚴重漏洞的可能性要高得多，至少在它們經過足夠時間的戰鬥測試之前是這樣。

2.1.1樂觀Rollup詳細解讀
Optimistic Rollups 將多個鏈下交易捆綁在一起提交到 L1 鏈上，降低用戶的成本。他們被稱為“樂觀”，因為他們假設交易是有效的，除非另有證明其是欺詐的。如果交易受到質疑，則會計算欺詐證明。如果證實存在欺詐行為，將受到處罰。如今，樂觀Rollup在乙太坊上運行，由基於乙太坊的智慧合約管理。他們在鏈外處理交易，但將資料批次發佈到鏈上Rollup合約。乙太坊確保Rollup計算的正確性並處理資料可用性，使Rollup比獨立的鏈外解決方案或側鏈更安全。它們還在兩層之間創建了固有的經濟安全一致性，因為 L2 在支付 L1 層產生的費用的同時獲得安全性。

從架構角度來看，Optimistic Rollup 包含以下內容：

• 交易執行。使用者將交易發送給運營商或驗證者，他們將交易聚合並壓縮到 L1。 
• 提交給L1。 運營商捆綁交易並使用 calldata 將它們發送到 L1。 
• 狀態承諾。Rollup 的狀態表示為 Merkle 樹。運營商提交新舊狀態根，確保鏈的完整性。 
• 欺詐證明和爭議。這些允許任何人質疑交易的有效性。如果挑戰有效（由 L1 仲裁），則欺詐方將受到懲罰。

欺詐證明在樂觀Rollup中發揮著至關重要的作用，它們是我們確保Rollup發佈正確狀態更新的根本。即使面對試圖延遲或篡改交易的惡意節點，只要有一個誠實的節點觀察狀態更新並檢查它們是否正確，鏈的完整性就會得到保留。在乙太坊上構建的 Rollups 背景下，因為實際資料發佈到乙太坊上，世界上任何人都可以充當驗證者。一旦誠實的驗證者檢測到不正確的狀態更新（例如，通過包含被篡改的交易），它就可以提交爭議，從而啟動防欺詐遊戲：多輪交互協議。在這裡，斷言者（產生狀態更新的節點）和挑戰者（發出爭議的驗證者）遵循由 L1 驗證者合約監督的協議來確定誠實方。該協議遞迴地進行，每次將計算分成兩個相等的部分。挑戰者每次選擇一個部位進行挑戰。這一過程稱為二分協議，一直持續到只有一個計算步驟有問題為止。一旦交互協定縮小到單個指令，就輪到 L1 合約通過評估指令結果以及斷言者和挑戰者的聲明及其各自的結果來解決爭議，以確定哪一個是正確的。 

2.2 全同態加密（FHE）

全同態加密 (FHE) 可以對密文進行計算，解密後，這些運算的結果與直接對明文執行的結果相一致。

在實踐中，自從Gentry提出原始方案以來，已經開發了幾種 FHE 方案，這些方案基於最初的誤差學習難度問題（Learning With Errors hardness problem），或相關的代數結構，例如其環變體。我們的實現使用了一種名為TFHE的方案，但由於該方案本身對於構建 FHE Rollup的目的並不重要，因此我們在下面以黑盒方式更一般地描述 FHE。
通用 FHE 方案可以用演算法元組 FHE = (Gen, Enc, Dec, Eval) 表示，如下所示： 

• Gen(1k)。給定安全參數 1k ，演算法輸出一對金鑰 (pk, sk) ，其中 pk是公共加密金鑰，sk是秘密解密金鑰。定義明文域P、隨機性域R、密文域C，以及允許的函數集F。 

•  Enc(pk,m;r)。給定公開金鑰pk、消息m∈ P 和隨機性r ∈ R，加密演算法生成密文c ∈ C ，使得

? = Enc?? (?;?)。

• Dec(??, ?).。使用金鑰??和密文 ?，解密演算法檢索原始明文消息

? = Dec?? (?)。 

• Eval(??, ? , {?? } ? ?=1 )。給定公開金鑰??、函數? ∈ F和一組密文{?? } ? ?=1 ，該演算法生成密文? ′ ∈ C，使得：

Dec?? (? ′ ) = ? ({Dec?? (??)}? ?=1 )。 

這意味著函數?是在加密資料上執行的，其結果被加密為?'。 

三、架構

3.1 FHE Rollups：樂觀還是基於ZK？

如前所述，ZK Rollups 在證明方面本質上較慢，但這為驗證方面提供了好處。在 FHE 的背景下考慮 ZK 時，這個問題變得更加複雜，因為我們現在基本上將兩種重型加密技術結合在一起。雖然越來越多的工作試圖解決這一研究空白，但目前提出的解決方案速度要慢幾個數量級。因此，對於加密域來說，使用基於樂觀的方法成為更自然的選擇。 

3.2 設計概述和實現細節

我們的平臺在構建時考慮到了模組化。它包括 Rollup 的典型元件，包括排序器、證明器和 DA 層，同時交織支持 FHE Rollup 所需的新元件和特定元件。圖 4 說明了總體設計。我們在下面詳細介紹了新的 FHE rollup 特定組件。 

3.3 fheOS 

FHE核心邏輯位於我們的 fheOS 庫中。它是一個預編譯常見加密操作碼的加密計算庫，例如比較兩個數字以及進行加法和乘法等算數運算。它使網路上運行的智慧合約能夠在合約中使用 FHE 原語。這意味著在 Fhenix 上運行（或使用）的 dApp 將能夠將加密資料集成到其智慧合約邏輯中。開發人員可以選擇決定哪些內容將被加密，哪些內容將保留明文。fheOS 是 Zama 的 tfhe-rs 3 FHE 庫的另一個 EVM 友好包裝器，類似於 fhEVM 。出於實現目的和模組化，我們選擇設計自己的版本。 

fheOS庫是Fhenix節點的核心引擎；利用加密功能的智慧合約將調用 fheOS 預編譯來執行常見的 FHE 操作，並且 fheOS 本身將負責Rollup和閾值服務網路（TSN，請參閱第 4 節）之間的通信和身份驗證，以處理解密和重新加密請求，同時證明解密請求是合法的。 

fheOS庫旨在作為擴展注入到任何現有的 EVM 中，這意味著它完全相容 EVM，從而保留所有現有的 EVM 功能，同時提高開發人員探索新用例的能力。

圖 1. FHE Rollup 架構概述 

 3.4 go-tfhe 

當我們試圖擴展乙太坊 goethereum (geth)（他們用 Go 編寫的主要用戶端）的功能時，我們遇到了一個挑戰：核心 FHE 數學運算庫 tfhe-rs 是用 Rust 編寫的，需要通過外部函數介面（FFI）進行通信。為了解決這個問題，我們開發了 go-fhe，其中包括： 

1.基於Go的API。該元件提供了使用 Go 執行 FHE 數學運算的所有必要介面。它是熟悉 Go 的區塊鏈開發人員的主要交互點。 

2. TFHE.rs 的Rust包裝。我們創建了一個專門的包裝器，用於調整 TFHE.rs 庫函數以適應區塊鏈應用程式。 

3. Go API和Rust Wrapper之間的FFI集成。為了橋接這兩種語言，我們的介面採用了 cgo 和 extern“C”機制。這有利於 Golang 和 Rust 之間的綁定，對齊函式呼叫、類型和命名約定。

一般來說，go-tfhe 充當 tfhe-rs 和區塊鏈應用程式之間的模組化可擴展羽量級橋樑。 

{{AD}}

四、閾值服務網路（TSN）

我們設計中的一個關鍵元件是閾值服務網路（TSN）。該網路與 L1 或其他Rollup元件分開，並發揮多個關鍵作用。特別是，該網路被集體委託給秘密共用的網路金鑰[??]，可以用於閾值解密。我們當前的實現利用了它，它使用 Shamir 秘密共用將 ?? 分割為 ? 份，其中需要 ? + 1 份來重建。實際上，每個位都是單獨共用的，但出於本文的目的，我們將忽略這種區別。

4.1 閾值解密和重新加密

有時，網路需要解密某些結果，或者將它們重新加密給指定用戶。TSN 負責來自Rollup的任何此類請求，並且可以使用 閾值解密協定來容納它。 

為了說明為什麼需要這樣做，請考慮以下兩個示例。首先，想像一下部署在 rollup 上的私密投票合約。當用戶投票給某個候選人時，他們會對自己的選票進行加密，合約會統計這些選票（全部加密）。在某個時間點，合約中的功能應該能夠解密計數並宣佈獲勝者。該請求被路由到 TSN，TSN 對其進行解密並返回結果以存儲在合約的狀態中。此流程如圖 2 所示 ，Solidity 合約代碼片段如圖 3 所示。 

一個類似的例子是擁有 NFT 的用戶，其中的私密中繼資料只有他們自己才能看到。此類中繼資料存儲在網路金鑰下的合約狀態中。當使用者嘗試訪問該資訊時，合約應該對其進行閾值重新加密，以便只有指定的用戶才能解密並訪問底層資料。 

4.2 秘密共用資料的證明

在某些情況下，我們也許能夠利用 TSN 來協助證明有關加密資料的重要陳述。例如，眾所周知的事實是，密文需要格式正確，否則嘗試解密格式錯誤的密文可能會洩露有關金鑰的資訊。同樣，在這樣的多使用者系統中，我們需要確保使用者不會（例如）發送他們未加密的密文，並要求 TSN 為他們解密。出於這些原因，每當用戶提交加密輸入時，我們都需要確保它已被正確加密並且使用者知道底層的明文。 

圖 2. Fhenix上解密FHE加密資料的智能合約請求

目前，基於 FHE 密文的最先進的零知識知識證明（ZKPoK）仍然相對昂貴，並且會給每筆交易增加大量的開銷。一種替代方案是讓用戶端首先使用可驗證的秘密共用協定 (VSS) 將其秘密輸入秘密共用到 TSN。在確認輸入已正確秘密共用後，網路可以例如通過以下簡化的協議草圖聯合加密輸入。 

• 協議閾值加密。給定共用使用者消息 [?] 和預處理的隨機元組 ([?], ????? (?))，各方輸出 FHE 密文 ?? := ????? (?)。 

• 伺服器與用戶端運行VSS 協定，接收並驗證[?] 的共用。 

• 伺服器使用主動安全的 MPC 協定聯合重建 ? := ????( [?] − [?]) 

• 輸出?? := ????? (?) + ????? (?)。 

* 請注意，由於??是安全順序協定結果的公共值，因此各方可以就其達成共識以確保正確性。 

4.3 隨機信標

智慧合約的一個獨特的必要功能是產生隨機性。智慧合約本質上是確定性的，因此它們需要外部隨機性來源來啟用非確定性功能。

圖 3. Solidity中的FHE投票合約示例

需要此類功能的用例示例包括鏈上遊戲（例如撲克、賭場）、NFT 鑄幣等。 

存在許多分散式拋硬幣協議。非常適合我們的案例的一個例子是基於可驗證隨機函數（VRF）的例子。 

4.4 安全洗牌

在許多情況下，我們需要一個專門用於對輸入向量進行洗牌的功能。許多隱私保護計算技術，包括那些利用 FHE 的計算技術，都可以從高效的安全洗牌原語中受益。洗牌發揮作用的例子不勝枚舉。一個簡單的例子是撲克遊戲——安全、私密地洗牌至關重要。 

更重要的是，安全洗牌是 Oblivious RAM (ORAM) 的關鍵構建塊，這些方案不僅確保記憶體被加密，而且確保對記憶體的所有訪問都是私密的。使用 ORAM 可以成為構建更高效的 fhEVM 的構建塊，該 fhEVM 允許 直接在程式上運行 FHE 計算，而無需首先將它們展開到電路中。其他應用程式，例如構建私密搜尋引擎，或在基於帳戶的模型中構建真正的匿名代幣，需要某種形式的ORAM。

4.5 安全性

需要注意的是，整個系統底層的機密性保障與 TSN 的信任假設密切相關。與保持閾值解密金鑰安全、正確解密/重新加密密文等相關的任何事務均由 TSN 負責。 

目前，15提出的最先進的協議要求 TSN 最多有 ? < ? 3 個惡意損壞，才能實現快速而穩健的協議，或者 ? < ? 2（如果我們願意通過中止來滿足安全性） 。 

4.5.1 擬議的改進（以及開放的未來研究）。我們提出了幾個關於 TSN 及其當前閾值解密協議的開放研究領域。我們邀請社區與我們一起推進這些感興趣的主題： 

• 支持不誠實多數的主動安全閾值解密協議 

• 作弊者識別——對於支持最多 ? < ? 2 個腐敗的協議（或任何不誠實的多數協議），我們應該能夠識別作弊方（無論是破壞協議的一方，還是中止協議的一方）。如果沒有它，就無法防止對 TSN 的拒絕服務攻擊。 

• 通過抽樣提供許多驗證器（>1000）——目前該方案對於許多驗證器的擴展性不夠好。對於限制為 ? < ? 3 的情況尤其如此，其計算複雜度隨著 (?, ?) 呈指數級增加。解決這個問題的一個方法是集中精力為每個時期抽取一個小委員會 [20, 49]。 

• 共用輪換和恢復。許多這樣的方案已經存在於文獻中。 

五、欺詐證明

Optimistic Rollups 的關鍵在於其欺詐證明機制。但我們如何適應該機制，特別是乙太坊的 EVM，以與在加密資料上執行 FHE 電路的智慧合約配合使用？ 

首先，觀察到 FHE 與 MPC 等其他加密計算技術不同，它本身允許任何人驗證計算是否正確完成，而不會破壞隱私保證。這是因為持有加密輸入和輸出的對手對底層加密資料一無所知（如果不是這種情況，那麼加密方案在語義上將不安全）。 

這使得驗證 FHE 計算與樂觀Rollup的思想相容，至少在理論上是這樣。如前所述，樂觀Rollup基於在 L1（或其他一些資料可用性服務）上發佈完整的交易資料以及輸出。在這種情況下，兩者都被加密。就像明文資料一樣，任何鏈下驗證者都可以獲取加密的交易資料，重新執行交易，並確保它們收到相同的加密輸出。如果情況並非如此，那麼誠實的驗證者可以提交爭議並開始與 L1 的仲裁過程。 

然而，整個欺詐證明機制植根於 L1 明確確定發佈狀態更新的 L2 節點或有爭議的驗證者（即挑戰者）是否作弊的能力。為此，L1 需要能夠運行底層計算的單個計算步驟。由於我們對乙太坊作為 L1 感興趣，這就提出了一個問題：乙太坊或任何傳統的 EVM 鏈如何在沒有對 FHE 操作的固有支援的情況下驗證 FHE 原語的執行？ 

答案就在 Arbitrum 的 Nitro 欺詐prover證明者中，我們根據需要重新調整了它的用途，允許我們將所有 FHE 邏輯編譯到 WebAssembly，並在 WASM runtime (WAVM) 中執行整個證明輪，在乙太坊上鏈上，而不是原生EVM。由於底層 FHE 代碼也可以編譯為 WASM，因此不需要對 L1 本身進行任何更改。 

為了解決性能問題，可以合理地假設，如果 FHE 計算本質上是密集型的，那麼在 EVM 之上的 WASM runtime中模擬它們可能會導致嚴重的性能損失。雖然這是一個合理的擔憂，但重要的是要記住，啟動這些計算僅在爭議場景中是強制性的，並且在有足夠爭議視窗的情況下，即時速度並不是絕對必要的。考慮到標準做法為此分配了大約 7 天的時間，我們估計這對於解決任何此類爭議來說已經足夠了。然而，我們沒有通過經驗驗證這一假設，我們注意到，將來驗證很重要。 

5.1 實施細節

在開發概念驗證 FHE 欺詐證明者的過程中，我們必須克服幾個障礙，為了完整起見，我們在此予以說明。

首先，為了將 go-tfhe 作為欺詐證明機制的一部分運行，有必要調整代碼以在 WebAssembly (WASM) 中執行。鑒於我們對用 Rust 編寫的 FHE 代碼的依賴，而大部分區塊鏈代碼傳統上都是用 Golang 編寫的，因此我們在原生編譯為統一的 WASM 模組時面臨著挑戰——Rust 和 Golang 之間的默認綁定使用 cgo，與 WASM 不相容。為了解決這個問題，我們在 WASM 中綁定使用主線Golang 編譯器的外部函數指令，在Golang 和 Rust 之間架起橋樑，創建一個專用 Rust 檔作為主要 WASM 構建目標，最終使用 wasm-merge 將兩者連結起來以獲得內聚的 .wasm 輸出。 

圖 4. FHE指令的防欺詐引擎 

此外，我們還必須修改 tfhe-rs。在撰寫本文時，tfhe-rs 僅支持在流覽器中編譯和執行 WASM。在我們的例子中——在區塊鏈之上運行的智慧合約——可用的介面與流覽器的介面不同。值得注意的是，某些 API 調用（例如訪問作業系統功能或多執行緒）無法訪問。為了使 TFHE.rs 與智慧合約上下文相容，進行了兩項主要修改： 

1. 禁用多執行緒。鑒於大多數智慧合約不支持多執行緒或併發，因此代碼被調整為以單執行緒和確定性方式運行。 

2. 自訂亂數提供商集成。tfhe.rs 的初始版本依賴於預定義的亂數提供程式或播種程式。唯一可用的播種程式取決於作業系統生成亂數的能力。我們引入了由Lib使用者管理的自訂播種程式。該播種程式接收輸入種子並將其傳遞到基於 ChaCha20 的種子偽亂數產生器 (PRNG) 提供程式。此修改消除了 FHE 實現中對非確定性亂數的需求，通過使用來自區塊鏈資料和狀態的一致輸入複製計算來促進外部驗證。

我們注意到，根據在此上下文中運行的 tfhe-rs 基準測試，使用 wasmer/cranelift 時性能會出現數量級下降，而使用 wasmer/llvm 進行添加操作時性能會下降 8 倍（在 i9-13900K、128 GB RAM、wasmer 4.0上測試） ）。我們注意到 Arbitrum 欺詐證明引擎使用軟體浮點，這應該會進一步影響性能，但在撰寫本文時我們尚未完成基準測試。 

六、結論

在本文中，我們展示了第一個提出的FHE Rollup構造，這是一種為乙太坊和其他EVM鏈增加機密性的新穎解決方案。我們的方法利用FHE的力量來實現加密的EVM計算，徹底改變了交易的執行方式和鏈上處理機密資料的方式。與最近的工作不同，我們的方法使用L2 Rollup結構來避免在所有節點上複製FHE計算的成本，從而產生更高效和實用的解決方案。 

我們的方法側重於乙太坊和EVM，但作為支援可驗證 FHE 的系統也具有獨立價值。此外，我們還提出了我們提出的 FHE rollup 系統的架構，包括其元件和層，並提出並實施了防欺詐解決方案的概念驗證，該解決方案不需要對乙太坊進行任何更改。我們的工作有助於開發新一波以隱私為中心的去中心化應用程式，增強使用者信心，擴大潛在用例，並提高乙太坊網路的整體安全性和實用性。