框架交易與隱私的三重門

Ethereum Research

本文為機器翻譯

展示原文

框架交易與隱私的三重門

fallout_comic_strong_compress 1200×800 168 KB

本文以EIP-8141為前提，而非對其進行論證。其目的是展示幀事務如何改善隱私協議，以及為了真正實現這一目標，公共記憶體池規則和包含清單的執行需要做出哪些變更。
非常感謝Carlos 、 Ben 、 Milos和Matt的回饋！

幀事務（ EIP-8141 ）旨在消除隱私協定中的中繼。然而，公共記憶體池准入規則、 FOCIL執行規則以及無狀態性路線圖各自對所支援事務的邊界設定了不同的界限。本文將分析這些邊界的交集和衝突之處，特別關注隱私保護事務。

幀交易如何消除中繼器

Tornado Cash和Railgun等隱私協議利用 zk-SNARKs 打破了存款人和提款人之間的鏈上連結。提款過程證明了取款人知曉 Merkle 樹中的有效承諾，但並不透露具體是哪個承諾。問題在於：提款人的地址是新地址，並且沒有 ETH 用於支付 gas 費用。目前，中繼器（中心化的、可審查的第三方，通常在需要時離線）會透過贊助提款交易來彌補這一缺陷。

EIP-8141改變了經濟機制。幀交易的VERIFY幀以STATICCALL方式運作：唯讀，不進行狀態修改。如果在付款獲得批准之前VERIFY發生回滾，則該交易在協議層面無效，永遠不會被打包進區塊，也不會向任何人收取 gas 費用。隱私提現變為：

VERIFY幀（ tx.sender = pool ，因此該幀指向池自身的存儲）：從SENDER幀的調用資料中讀取 publicInputs，根據池存儲的歷史記錄驗證 Merkle 根（ SLOAD ），確認空值未花費（ SLOAD ），並針對這些 publicInputs 執行 Groth16 配對檢查。如果一切通過，則呼叫APPROVE 。
SENDER幀：將無效化項標記為已花費，將淨額轉移給接收方，並將費用記入資金池內的贊助商。

至關重要的是，手續費不再需要來自外部贊助商。提現本身即可支付執行費用： SENDER幀可以將一部分提現資金用於支付 gas 費用，從而無需預先註資的發送方或第三方中繼。贊助商的份額將作為內部信用留在資金池中，稍後可領取，因此提現只需進行一次出站轉賬，而不是兩次。

#	模式	子類別	目標	呼叫者	旗幟	數據	角色
0	`VERIFY`	`only_verify`	pool ( `null` → `tx.sender` )	`ENTRY_POINT`	`APPROVE_EXECUTION`	SNARK 證明	從幀 2 呼叫資料讀取`publicInputs` `(root, nullifier, recipient, amount, sponsor, fee)` ， `SLOAD` `acceptedRoots[root]`和`!nullifierHashes[nullifier]` ，驗證證明， `APPROVE(APPROVE_EXECUTION)`
1	`VERIFY`	`pay`	贊助	`ENTRY_POINT`	`APPROVE_PAYMENT`	（空白/贊助商政策數據）	自省幀 2： `target` = 池，選擇器 = `withdraw` ，編碼`sponsor` = 自身，編碼`fee` ≥ `MIN_FEE` `APPROVE(APPROVE_PAYMENT)` — 贊助商的 ETH 在此扣除
2	`SENDER`	`user_op`	pool ( `null` → `tx.sender` )	pool ( `tx.sender` )	`APPROVE_SCOPE_NONE`	`withdraw(publicInputs)`	Mark `nullifierHashes[nullifier] = true` , `ERC20.transfer(recipient, amount − fee)` , `sponsorCredits[sponsor][token] += fee`

對於無效證明（ VERIFY回滾，交易丟棄）和重播證明（無效標記已標記， VERIFY回滾），贊助商的風險為零。無需信任，無需中繼基礎設施，也無需額外的審查。

包容的三道門

以隱私為中心的框架交易要實現抗審查性，需要經過三個獨立的關卡，每個關卡都有其自身的限制：

1號門：公共會員池入口

EIP-8141 的記憶體池規則借鑒了ERC-7562 ，但完全剝離了質押和聲譽機制，定義了哪些內容可以透過公共 P2P 網路傳播：

驗證前綴必須與已識別的模式相符（ self_verify或only_verify + pay ，可選地以deploy開頭）。
SLOAD僅限於tx.sender存儲
VERIFY氣體總量上限為MAX_VERIFY_GAS (100,000)
停用的操作碼： TIMESTAMP 、 NUMBER 、 BLOCKHASH 、 BALANCE 、 SELFBALANCE 、 SSTORE 、 TLOAD 、 TSTORE等。
透過精確的運行時代碼雜湊值識別規範的支付主程序，並進行時間鎖定提款和節點端待處理餘額追蹤。
非規範付款人限制為MAX_PENDING_TXS_USING_NON_CANONICAL_PAYMASTER (1) 個待處理交易

任何違反這些規則的內容都會被公共記憶體池拒絕，但仍然可以透過備用記憶體池或私人頻道到達開發者。

閘門 2：焦點執行

FOCIL保證交易被納入：每個區塊16名IL委員會成員根據他們對待處理交易的理解構建包含清單。驗證者只對包含IL交易的區塊進行投票（或在區塊後狀態中證明其無效）。

對於 EOA，FOCIL 的遺漏檢查是透過post-state進行低成本的nonce / balance查找來實現的。對於FrameTxs ，遺漏檢查需要重播VERIFY前綴。由於交易有效性取決於執行情況，而不僅僅是發送方狀態，因此不存在低成本的代理。 FOCIL -frame-txs 提案透過五個約束定義了資格：

驗證前綴順序： VERIFY幀必須位於DEFAULT / SENDER幀之前
每筆交易VERIFY gas ： verify_gas(tx) <= MAX_VERIFY_GAS_PER_FRAMETX (100,000)
每個 IL 的VERIFY預算：整個 IL 的累積VERIFY gas 上限為MAX_VERIFY_GAS_PER_INCLUSION_LIST (250,000)
基本交易完整性： chain_id 、手續費、無資料區塊
受限狀態存取： VERIFY僅可讀取tx.sender和 payer 帳戶狀態（ balance 、 nonce 、代碼）及其前N儲存槽位（ N = 2-4），與AA-VOPS快取機制一致。任何其他合約的儲存讀取操作都會導致該交易無效。

違反任何約束的FrameTxs可免於 FOCIL 強制執行：不能因此怪罪建構者。

門3：節點驗證能力

術語：
PS = 部分無狀態：持有部分狀態，而非全部狀態
VOPS = 僅驗證 PS：持有足夠的狀態以驗證來自 EOA 的交易
AA-VOPS = VOPS + 每個帳戶若干儲存空間

ZKEVM 之後，節點無需儲存完整狀態。例如， VOPS節點僅儲存約8.4 GB （每個帳戶的nonce 、 balance和codeHash ）。 AA -VOPS在此基礎上擴展，在 trie 樹中為每個帳戶維護前N儲存槽位（因此部分tx.sender和 payer 插槽可用於本地VERIFY重播）。部分狀態 (PS) 節點也會追蹤特定合約的儲存。節點類型決定了它可以本地重播哪些VERIFY幀，進而決定了它可以將哪些交易類別新增到其記憶體池中，並將其來源新增至類似 FOCIL 的包含清單中：

能力	完整節點	PS節點	AA-VOPS	語音操作員
EOA `nonce` / `balance`檢查	是的	是的	是的	是的
AA錢包`VERIFY` （ `tx.sender`儲存）	是的	如果被追蹤	`N`槽子集	不
規範支付主准入（代碼哈希匹配 + 餘額預留）	是的	是的	是的	是的
Canonical 付款人驗證追蹤重播	是的	如果被追蹤	不	不
隱私池儲存（根、無效化器）	是的	如果被追蹤	不	不

無法驗證某種交易類型的節點不能將其保存在其記憶體池中，也不應將其包含在完整性日誌（IL）中。該類交易的抗審查能力會隨著具備驗證能力的節點比例的降低而下降。

有關哪些節點類型可以支援哪些EIP-8141記憶體池策略的詳細分析，請參閱「透過無狀態視角進行幀事務處理」。

為什麼隱私權交易無法通過所有三個關卡的考驗

在預設參數下，隱私權提現操作無法通過所有三個驗證關卡：

門 1（公共記憶體池） ：當tx.sender = pool時， VERIFY幀對池的 Merkle 根歷史記錄和nullifierHashes映射的SLOAD操作滿足tx.sender僅限存儲的限制，但 Groth16 配對檢查超過了EIP-8141 驗證跟踪規則中定義的100k MAX_VERIFY_GAS 。已拒絕。

門禁 2（FOCIL 資格） ：Groth16 配對檢查超過了每筆交易100k的VERIFY gas 預算。即使tx.sender = pool將池的儲存與有界狀態存取規則對齊，僅 gas 上限就足以使該交易不符合資格。因此，該交易不予強制執行。

閘控 3（節點能力） ： VOPS和AA-VOPS節點不持有礦池合約存放。只有追蹤礦池的 PS 節點或全節點才能進行驗證。

交易類型	公共游泳池	符合FOCIL資格	語音操作員	AA-VOPS	PS（追蹤池）
EOA幀tx（ECDSA/P256）	是的	是的	是的	是的	是的
智慧錢包（ `tx.sender`存儲，<= `N`插槽）	是的	是的	不	是的	是的
Canonical 付款人贊助	是的	是的	不	不	如果被追蹤
隱私撤回	不	不	不	不	如果被追蹤

因此，隱私權交易被排除在所有預設的抗審查路徑之外。而最需要抗審查的交易，恰恰是目前設計無法保護的。

這並非不可避免。差距源自於 FOCIL 如何強制執行FrameTxs的納入，而FOCIL-frame-txs 提案則提供了兩種方法，對可強制執行的內容有著截然不同的影響。選擇哪種方法決定了與隱私相關的FrameTxs是否能夠實現抗審查。

焦點強化：兩種方法

這兩種方法都解決了同一個問題：建築商如何證明他們沒有審查符合條件的 IL FrameTx ，以及證明人如何驗證這些聲明。

追加循環方法

預設方法是讓建構器迭代地將排除的符合條件的 IL FrameTxs加入區塊中，直到最終post-state中所有被排除的FrameTx都有效為止。其成本為O(k²) ，即排除的FrameTxs的數量。這種二次方建構器成本迫使使用保守的參數： MAX_VERIFY_GAS_PER_FRAMETX為100_000 ， MAX_VERIFY_GAS_PER_INCLUSION_LIST為250_000 。

假設惡意 IL 委員會佔比 25%（16 名成員中的 4 名，每月大約進行一次，權益份額為 1%），且交易大小約為 100 字節：每個 IL 可以在MAX_BYTES_PER_INCLUSION_LIST （ 8 KiB ）的範圍內容納約 81 筆交易，但 IL VERIFY預算僅允許 21 筆的 21 月 21 筆筆FrameTxs的MAX_VERIFY_GAS_PER_FRAMETX gas 驗證（ 2 * 100k = 200k <= 250k ）。 4 個惡意 IL 會產生k=8無效FrameTxs 。追加循環運行k(k+1)/2 = 36 VERIFY重播： 3.6M gas（約佔區塊的 6%）。測試器工作量： 4 * 250k = 1M gas（約佔 1.7%）。雖然開銷不大，但這些參數使得 FOCIL 對FrameTxs幾乎形同虛設： MAX_VERIFY_GAS_PER_FRAMETX設定為100k 250k ，會排除 Groth16 證明、PQ 簽章以及任何非平凡的驗證FrameTxs ；而MAX_VERIFY_GAS_PER_INCLUSION_LIST一個只能支援 2 個可執行FrameTxs IL 幾乎無法起到任何帳戶抽象的作用。

驗證指數方法

後續操作消除了追加循環。建構者透過發布一個(tx_hash, claimed_index)對來聲明每個被排除的交易，該對聲明了交易失效的區塊索引。驗證者使用區塊存取清單 ( EIP-7928 ) 重建claimed_index處的狀態，並重播VERIFY前綴。如果VERIFY成功，則建構者撒謊，該區塊不符合 IL 條件。建置成本從O(k²)降至O(k) 。但代價是增加了協議的複雜性：索引聲明是額外的網路元件， engine_newPayload需要將其與 IL 交易一起接受，並且 EL 需要相應地驗證它們。

由於建造成本不再是瓶頸， MAX_VERIFY_GAS_PER_INCLUSION_LIST可以提升至2^20 （約 100 萬 gas），並且由於每個被排除的交易只需在其claimed_index處驗證一次，而非迭代驗證，因此每筆交易的 gas 上限不再那麼關鍵。 2 2^20的每 IL 值足以使隱私協議中的交易受益於 FOCIL 的抗審查保證。

同樣是 25% 的對抗場景：每個 IL 現在最多可以預算 10 個FrameTxs每個 FrameTx 消耗100k gas（ 10 * 100k = 1M <= 2^20 ）。四個惡意 IL * 10 = 40 個FrameTxs將被排除。建構器成本是線性的： 40 * 100k = 4M gas（約佔區塊成本的 6.7%）。測試器成本： 4 * 2^20 ≈ 4.2M gas（約佔 7%）。所有 16 個 IL 的最壞情況： 16 * 2^20 = 2^24 ≈ 16.8M gas（約佔 28%）。每個 IL 預算增加約 4 倍，徹底消除了建造器成本的二次方級成長。

節點能力是限制因素

索引方法將公共記憶體池規則與 FOCIL 執行機制分開。公共記憶體池規則必須嚴格，因為交易可能需要在每個區塊之後重新驗證，所以狀態依賴性必須很小且具有確定性。在驗證索引方法下，FOCIL 會在固定的claimed_index處重播一次VERIFY 。由於沒有持續的維護成本，因此它可以支援更廣泛的狀態存取權限和更高的 gas 預算。另一方面：FOCIL 驗證位於測試器的關鍵路徑上（在t=4s驗證截止時間內），而記憶體池驗證是異步運行的。較高的MAX_VERIFY_GAS_PER_INCLUSION_LIST會直接佔用測試器的時間預算。

這意味著 IL 委員會成員可以從替代記憶體池（包括注重隱私的記憶體池）獲取交易，並將其納入自己的 IL 中，即使預設的公共記憶體池不包含這些交易。但要讓隱私交易也能正常運作，需要放寬有界狀態存取規則（讀取權限僅限於tx.sender和 payer 帳戶）。此外，強制執行包含規則的節點需要相應的狀態來驗證這些交易。

AA-VOPS無法彌合這一差距。它為每個帳戶快取N儲存槽位，足以滿足簡單的錢包驗證（所有者金鑰、nonce），但不足以支援隱私協定。與隱私交易相關的VERIFY幀讀取的是池合約儲存（根環緩衝區、無效化映射），而不是發送方儲存。無論N的值如何，都無法解決這個問題：讀取操作的目標完全不同。即使 AA-VOPS 為每個合約快取N插槽，也無濟於事：無效化映射使用雜湊值作為鍵，因此存取的插槽是不可預測的，並且分散在整個儲存樹中。

規範隱私池

最實用的解決方案是規範池模式，類似規範支付者。一個由代碼雜湊識別的規範合約可以作為多個隱私協議的共享註冊表：以統一且可審計的佈局儲存每個池的僅追加 Merkle 根和無效化器集。如果設計得當，這樣的池對於公共記憶體池和 FOCIL 強制執行都是安全的：針對此合約的VERIFY幀恰好讀取兩個儲存槽： acceptedRoots[R]和nullifierHashes[h] ，這兩個儲存槽都使用可從呼叫資料派生的鍵。存取模式是有界的、可預測的且單調的：VERIFY 讀取的每個儲存槽都始終從false → true 。規範註冊表無需節點追蹤 N 個獨立的池合約，而是將問題簡化為一個具有已知儲存佈局的已知位址，從而以最小的成本實現隱私的部分狀態性。

單調狀態是該設計能夠抵禦大規模失效攻擊的關鍵。目前的隱私權協議使用滾動環形緩衝區來儲存最新的默克爾根，每次存款都會移除最舊的條目。根據 EIP-8141 協議，這種移除操作構成了一種大規模失效攻擊途徑：一次存款（或攻擊者的垃圾郵件）就可以輪換移除數十個待處理的讚助提現所依賴的根，從而同時將它們全部從內存池中移除。用僅追加的acceptedRoots映射取代環形緩衝區可以完全消除這種攻擊途徑。針對任何歷史根生成的提現證明將永遠有效；無效化器集已經可以防止雙重支付，因此接受舊根在密碼學上是安全的。唯一可以使待處理提現失效的狀態變更是寫入其特定的nullifierHashes[h]槽，這需要持有該票據的秘密。這種操作是針對每筆交易的，而且是單獨進行的，絕對不會是大規模的。

一個實作細節：目前隱私協定中常用的默克爾根環形緩衝區必須替換為僅追加映射，以避免大規模失效。就大小而言，這不成問題：例如，最常用的 Tornado Cash 合約（1 ETH 池）有 81,881 筆存款。這大約相當於 10.5 MB 的原始鍵值資料（ acceptedRoots和nullifierHashes各 81,881 筆記錄，每筆記錄約 64 位元組），或儲存在狀態 trie 樹中後約為 25-40 MB。追蹤此池的 PS 節點提交的額外狀態遠低於 50 MB，與約 8.4 GB 的 VOPS 基準相比可以忽略不計。

每個槽位有 16 個 IL 委員會成員， FOCIL只需 1/16 的誠實成員即可保證包含。但這裡的「誠實」也意味著「有能力」：如果一個成員想要包含一個隱私交易，但他運行的是VOPS或AA-VOPS節點，那麼他就無法驗證該交易。 1/16 的誠實假設就變成了 1/16 的能力假設。隱私池節點解決了這個問題。它們不需要完整的狀態，只需要它們關心的合約。一個追蹤一個規範隱私池的隱私池節點最多只會增加幾 MB 的空間。基礎設施成本可以忽略不計；問題在於是否有足夠的驗證者選擇這樣做。

另一種替代規範化隱私池的方法是允許交易發送者附加所需的儲存狀態以及針對最新狀態根的梅克爾證明。這種方法有許多不足，其中最重要的是，這些證明在每個區塊產生後都會失效，必須不斷重新計算。

擬議變更

將規範合約例外擴展到隱私池。 EIP -8141 已經允許透過執行時間程式碼雜湊匹配來指定規範支付者，並使其免受嚴格的公共記憶體池規則的約束，因為它們的狀態依賴性是已知的安全機制。
提高規範合約幀的單筆交易VERIFY gas 上限。 MAX_VERIFY_GAS MAX_VERIFY_GAS = 100_000對於 Groth16（約 250k）來說不夠。規範合約具有固定的驗證路徑，因此其最壞情況下的VERIFY成本是程式碼雜湊的靜態屬性。無效證明消耗的 gas 與有效證明相同，並會被丟棄，不會進行任何放大。通用幀保持 100k 的上限；規範合約幀的上限允許為例如約 400k，留出足夠的空間，並限制其在記憶體池中的數量。
採用驗證索引 FOCIL 強制執行，接受增加的協定複雜性（ (tx_hash, claimed_index)映射），以消除二次建構器開銷，從而避免FrameTx的 gas 預算過於保守。
將MAX_VERIFY_GAS_PER_INCLUSION_LIST提高到2^20 (=1M)，使具有更高VERIFY gas 的單一交易（Groth16、PQ 簽章）能夠適應每個 IL 的預算。
放寬規範隱私池合約的有界狀態存取規則，允許 IL 委員會成員從替代記憶體池獲取這些交易，並使運行追蹤這些合約的 PS 節點的證明者能夠強制執行這些合約的納入。

這些措施共同為隱私FrameTxs提供了一條可行的抗審查途徑：在規範合約例外下進行公共記憶體池傳播，由具備 PS 能力的 IL 成員納入，並透過驗證索引方法強制執行 FOCIL，而不會削弱非規範FrameTxs的 DoS 抵抗能力。

類似的論點也適用於後量子交易。後量子簽名規模龐大，驗證成本高昂，10萬VERIFY gas 不足以支付。與隱私協議類似，後量子交易也需要豁免於 gas 上限，可以透過規範化驗證合約或添加規範化的預編譯程序來實現。

目前針對FrameTxs 、VOPS 和 AA-VOPS 的公共記憶體池規則對於隱私協定而言過於僵化。規範化隱私池可以改變這一現狀。透過程式碼雜湊識別隱私池，公共記憶體池可以安全地驗證其VERIFY幀，而追蹤少量高價值合約（隱私池、規範支付者）的 PS 節點可以為它們建立包含列表。這樣做可以為最需要抗審查性的交易提供保障。

附錄

為什麼備用記憶體池會失敗

碎片化並非複合的根源：每個需要更嚴格驗證（隱私、PQ 等）的交易都可能需要創建自己的備用記憶體池。節點業者會挑選出優勝者，支援這些優勝者的節點數量會逐漸減少，而最弱的備用記憶體池則成為所有依賴它的服務的審查載體。由於缺乏內建激勵機制，備用記憶體池只能透過請求志工無私地運作來擴展，這甚至可能要求志工購買更強大、更昂貴的硬體。
匿名集崩潰：匿名集從“所有以太坊節點”降級為“支援隱私記憶體池的節點”，並且對等連接在網路層洩漏。
在網路層很容易被審查：用於單一用途備用記憶體池的引導節點、DNS 記錄和對等清單都是關鍵節點，ISP 或國家可以透過一條規則將其移除。公共記憶體池難以審查，因為它承載著整個網路的負載；而備用記憶體池則不然。隱私流量最終會流經比其所取代的中繼器更容易被離線的基礎設施。
focil 的 1/16 假設不成立：只有當至少有一位 IL 委員會成員與備用記憶體池建立對等連接並能驗證交易時，才能保證及時包含。 “1/16 誠實”的假設變成了“1/16 誠實、已訂閱且有能力”，這遠不如EIP-7805所承諾的保證。如果 IL 建構者被宣傳為低硬體節點，這將尤其成問題。
中繼節點不會消失，它只是移動了位置：Alt-mempool 交易仍然需要到達建置節點。跨越邊界轉送的橋接節點，正是框架交易原本旨在消除的信任和審查機制，只不過這次是在堆疊的下一跳。

幀 tx <> 公共記憶體池決策樹：

框架流 (6) 1040×1000 111 KB

規範隱私池範例

有關規範隱私協議實現的範例（使用偽代碼），請查看此處。