ChatGPT 圖片 2025年4月22日 上午11_26_48 1024×1536 148 KB

介紹

以太坊長期以來一直追求無狀態驗證的目標：使參與者無需存儲整個鏈的狀態即可驗證區塊。無狀態旨在降低硬件要求，促進驗證者節點之間的去中心化，並通過允許構建和驗證更大的區塊而無需所有節點複製完整狀態來解鎖可擴展性。

實現這一願景的一個主要方案是弱無狀態，即只有區塊生產者保留完整狀態，其他節點使用小型狀態證明來驗證區塊。弱無狀態雖然因其簡單高效而頗具吸引力，但也帶來了一個關鍵挑戰：在大多數節點無法獨立驗證交易的世界中，以太坊如何保持其抗審查 (CR) 特性？

在本文中，我們將探討弱無狀態性為何會削弱以太坊的抗審查性保證，並提出一個務實的解決方案：僅驗證部分無狀態性 (VOPS) 。VOPS要求節點存儲僅夠驗證待處理交易的賬戶數據，從而將存儲量減少 25 倍，同時又能保持以太坊的抗審查性。

我們認為：

• 弱無國籍狀態本身並不能保證強大的抵制審查能力。
• 未來的設計必須重新審視強無狀態性，並解決實際問題，例如誰生成這些證明、哪些類型的證明最有效，以及帶寬和證明成本如何影響節點要求。
• 與此同時，僅有效性部分無狀態 (VOPS)提供了一種簡單有效的橋樑：將本地存儲減少25 倍，同時保留功能性、抗審查的公共內存池。
  AA-VOPS擴展了 VOPS 以支持完整的本機帳戶抽象，通過本地緩存和增量更新最大限度地減少見證開銷，提供了實現強無狀態的途徑。

原因

我們首先會解釋，如果我們想通過FOCIL之類的機制為所有交易提供強大的抗審查保障，那麼弱無狀態（即僅依賴區塊生產者持有狀態）為何行不通。在深入探討之前，我們先來快速回顧一下 FOCIL 在有狀態的世界中運作所需的主要要素。我們將展示 FOCIL 當前的設計如何依賴於內存池能夠保留有效交易並剔除無效交易的假設：

• 用戶發送交易，如果有效（即通過隨機數和餘額檢查），則會在節點之間廣播，並在公共內存池中保持待處理狀態。
  注意：在本文中，我們使用術語“節點”通過其執行層客戶端來指代內存池維護者。
• 包含者：每個時隙，16 個包含者觀察待處理的內存池交易，將它們添加到包含列表（IL），並在 CL P2P 網絡上廣播這些 IL。
• 區塊生產者必須在其區塊中包含所有 IL 有效交易的並集。只有當 IL 交易無效或區塊已滿（即條件屬性）時，才能將其從區塊中排除。
• 證明者會驗證所有 IL 交易是否都已包含在區塊中。如果已包含，則證明者會投票支持該區塊。否則，他們會評估區塊是否已滿，或缺失的交易是否有效，以確定排除交易是否合理，或者該區塊是否存在審查行為。

現在，假設該協議只要求區塊生產者持有狀態。這意味著用戶、維護內存池的節點、包含者和證明者無法自行確定交易是否根據preStateRoot有效。事實上，他們將無法訪問關鍵驗證檢查所需的完整、最新的狀態信息，包括確認發送者是否擁有足夠的balance以及交易的nonce是否正確。需要注意的是，目前 dApp 已經提供了任何智能合約條件或狀態相關邏輯（例如，Uniswap 池的當前狀態），以幫助用戶避免回滾。

因此，在一個弱無國籍的世界裡：

• 對於證明者來說，一切都很順利：他們根本不需要存儲任何東西，因為區塊生產者會生成區塊級見證。這些見證可以採用聚合 Merkle/Verkle 證明（例如IPA 多重證明）甚至 SNARK（稍後將對此進行詳細介紹）的形式，它們表明區塊中包含的交易進行的所有狀態訪問對於preStateRoot都是有效的。換句話說，它們證明了為區塊執行提供的數據存在於前一個區塊狀態根中。重要的是，區塊生產者還必須為他們排除的任何 IL 交易附加見證（使用與 IL 一起提交的見證或通過重建它們），以便證明者可以重新執行區塊並驗證每個遺漏是否合理。
• 對於維護內存池和包含器的節點來說，如果我們希望它們無狀態，就會存在一個根本問題。當用戶將交易發送到公共內存池時，節點無法知道這些交易是否符合preStateRoot有效性，因為它們無法執行常規的nonce和balance檢查來確定是否應該重新廣播交易或將其從本地內存池中刪除：
  • 攻擊者可以利用這一漏洞，用無效交易淹沒內存池和 IL ，從而有效地抵消 FOCIL 的好處，並審查那些原本可以從納入 IL 中受益的交易。
  • 缺乏nonce和balance檢查作為第一道防線，會形成一種新的 DoS 攻擊向量：它允許任何人都向內存池或 IL 提交無效交易，從而降低內存池的質量，並使有效交易更難浮出水面。這會產生與包含者對抗並用垃圾填充 IL 時相同的破壞。關鍵區別在於，如今只有驗證者（擁有 32 ETH）才能成為包含者，而如果沒有基本的過濾機制，任何參與者都可以降低內存池質量並干擾包含列表的有效性——這降低了攻擊門檻，並在實踐中削弱了抗審查能力。

怎麼辦？

在下一節中，我們將探討克服弱無國籍方法所帶來的挑戰的潛在選擇。

選項 1：強無國籍

一種看似簡單的方法是要求用戶交易與針對preStateRoot完整狀態訪問（例如，Merkle 或 Verkle 證明）捆綁在一起，這通常被稱為強無狀態。我們甚至可以放寬強無狀態的嚴格定義，要求每個先前的區塊生產者為每筆交易附加狀態見證，以便節點可以按需獲取它們。理論上，這將允許任何節點（包括包含者和證明者）獨立驗證交易的狀態訪問是否與preStateRoot一致，而無需訪問完整的當前狀態。這種機制對於有效管理內存池很有用：節點不必每個 slot 都排除和包含交易，而是可以保留不受後續區塊影響的交易，並修剪那些 nonce 或餘額已更改的交易。

但在實踐中，它需要在節點和當前區塊生產者之間建立實時傳輸通道，從而引入強信任假設和新的審查向量：區塊生產者可以延遲或選擇性地保留交易級證明，將目標交易排除在每個內存池和包含列表中，悄悄地將其排除在外，同時仍然生成一個看似有效的區塊。此外，對於新交易，僅依賴前一個區塊的狀態是不夠的。用戶需要訪問更新的實時狀態見證，其中包括交易實際觸及的賬戶和存儲槽，以及重建這些條目路徑所需的狀態 trie 的任何其他部分——這是由於 trie 結構連接狀態的方式所致。持續獲取這些證明不僅會增加帶寬使用量和延遲——從而降低用戶體驗——而且還提出了一個關鍵問題：誰應該充當提供證明的節點？錢包？dApp？Portal 網絡？超級節點（即質押2048 ETH的驗證者）？還是以上所有？

如果我們希望見證者和包含者節點完全無狀態並在智能手錶上運行，強無狀態可能是最終目標，但進一步的研究仍需解答這一問題，並通過評估以下兩方面所需的成本和硬件要求來確定哪些參與者最適合履行這一職責： (1)存儲完整狀態； (2)生成並廣播與用戶交易相關的見證和證明。需要注意的是，這種方法只需要 N 選 1 的誠實假設——理論上，一個能夠生成有效證明的誠實參與者就足夠了。然而，在實踐中，僅依賴一個或極少數參與者可能會導致諸如租金抽取（例如承諾攻擊、審查制度和壟斷定價）等問題。

選項 2：僅有效的部分無國籍狀態

一種務實的短期方法是依賴部分無狀態機制，僅存儲驗證交易有效性所需的最少數據。在 VOPS 下，每個節點每個 EOA 僅維護四個字段—— address （20 B）、 nonce （8 B）、 balance （12 B）和一個 1 位的codeFlag而不是完整的狀態。

當交易到達時，節點會檢查codeFlag ：

• codeFlag = 0 （純 EOA，無委託指示器 - 意味著帳戶不能將執行委託給自定義代碼）：
  • 驗證簽名、隨機數、餘額與費用以及 gas 限制。
  • 允許每個地址進行多個正在進行的交易。
• codeFlag = 1 （任何能夠使用 23 字節EIP-7702委託指示符運行代碼的地址）：
  • 每個地址最多執行一項待處理交易。
  • 由於委託代碼可能會不可預測地改變狀態，因此可防止隨機數/餘額衝突。

在每個新塊上，節點都會使用所有修改過的四元組更新其表，刪除任何因陳舊隨機數或餘額不足而無效的交易，每當帳戶的codeFlag從0翻轉為1 時，刪除除最高優先級待處理交易之外的所有交易，並且當標誌從1翻轉回0時，提升任何排隊的 EOA 交易，其隨機數現在匹配。

由於每個帳戶條目只有20 + 8 + 12 + 0.125 ≈ 40.125 bytes ，因此維護約 2.41 億個帳戶需要：

與目前~233 GiB全狀態大小相比，這減少了25 倍以上 (h/t Guillaume)，但仍然能讓 VOPS 節點有效地維護內存池。需要注意的是， 8.4 GiB數據是未壓縮的，因此這只是對 VOPS 所能節省的存儲空間的保守估計。

Verkle 的 VOPS

為了使 VOPS 理念具體化，我們首先在Verkle設置中錨定該提案。

區塊頭字段

讓我們回顧一下在那種情況下誰做了什麼：

• 用戶將交易廣播到公共內存池。在 VOPS 下，部分無狀態節點每個帳戶僅保留四個字段—— address 、 nonce 、 balance和codeFlag ——足以決定每個待處理交易是保留還是刪除。

• 包含者：每個 slot，16 個包含者會觀察內存池中待處理的交易，將其添加到包含列表 (IL)，並在 CL P2P 網絡上廣播這些 IL。如果包含者也維護內存池（就像現在的情況一樣），則在將交易包含到 IL 之前無需進行額外檢查，因為針對preStateRoot （例如， nonce 、 balance和codeFlag ）的有效性檢查已作為內存池維護的一部分執行。但是，如果將來包含者被拆分成獨立角色（例如，輕量級的“智能手錶”包含者），則它們需要在將交易包含到 IL 之前獨立執行交易有效性檢查。

• 區塊生產者掌握著完整的以太坊狀態。他們必須在其提議的區塊中包含所有 IL 交易的有效交易並集。只有當 IL 交易無效或區塊已滿（即滿足條件屬性）時，才能將其排除。

  在 Verkle 的VOPS世界中，區塊生產者負責生成和提交以下內容：

  • 區塊級見證（例如，Verkle 樹上的IPA 多重證明）：這證明了區塊執行所提供的數據存在於前一個區塊狀態根中。
  • 後狀態根 (post-state root) ：執行所有交易後，區塊生產者計算並提交生成的postStateRoot到區塊頭中。這作為執行的輸出，必須由證明者驗證。這已經是區塊生產者目前的做法，在 VOPS 世界中並非新要求。

• 證明者通過執行以下步驟來驗證區塊：

  1. 驗證區塊級見證：確認所有提供的狀態（通過 IPA 多重證明證明）對preStateRoot有效。

  2. 在本地重新執行區塊：使用提供的交易，證明者從預狀態（從見證重建）開始獨立重新執行區塊，以重新計算postStateRoot 。

  3. 檢查postStateRoot ：確保本地重新計算的postStateRoot與塊中提交的 postStateRoot 匹配。

  4. 驗證 IL 條件

  • 包含 IL 交易
    • 在從重建的預狀態進行本地重新執行期間，可以觀察到與塊中存在的 IL 交易相對應的所有狀態變化。
  • 排除的IL交易
    • 執行完塊中包含的所有交易後，嘗試執行每個排除的 IL 交易：
      • 如果交易無法通過隨機數或餘額檢查，或者區塊已滿，則排除是合理的。
      • 否則，區塊生產者正在進行審查，並且該區塊不應該獲得投票。

  如果所有檢查（狀態訪問的有效性、執行的正確性以及 IL 條件的滿足性）都通過，則證明者將投票支持該區塊。通過在步驟 2中重新執行區塊，並在步驟 3中同時更新其本地四元組表，VOPS 節點無需存儲完整的 Verkle 樹，即可保持其部分狀態完美同步。

zkVM 的 VOPS

基於 Verkle 風格的 VOPS，我們可以用零知識虛擬機 ( zkVM)取代區塊級狀態證明和本地重新執行。每個區塊都附帶一個SNARK證明，允許每個驗證者通過運行單次毫秒級驗證來檢查整個轉換過程以及所有 IL 條件。

• 區塊生產者必須證明什麼：
  • 狀態有效性：交易讀取的每個鍵/值都經過preStateRoot驗證。
  • 執行正確性：在重建的預狀態下執行有序交易會產生已提交的postStateRoot 。
  • 差異正確性：將正確的完整狀態差異應用於preStateRoot會產生postStateRoot ，並且差異與標題中嵌入的差異匹配。

區塊頭字段

兩點說明：

• 在 VOPS 和 AA-VOPS 下，節點依賴於接收每個區塊的完整stateDiff來更新其本地狀態。EIP -7928 區塊級訪問列表 (BAL)正是提供這種機制：以可驗證的方式強制發佈所有已修改的賬戶、存儲密鑰、餘額和隨機數。
• VOPS 節點使用其更新的四元組表和收到的stateDiff在本地檢查 IL 合規性——這裡沒有額外的證明義務（有關每個帳戶證明與包含列表規則的關係，請參閱 AA-VOPS）。

VOPS 節點的逐塊例程

1. 驗證execProof 。確認狀態有效性， 執行正確性，以及差異正確性。
2. 提取四元組。從已驗證的完整stateDiff中，提取每個已修改賬戶的(address, nonce, balance, codeFlag)並更新本地表。
3. 執行IL規則。使用刷新後的四元組表，在本地重新檢查包含列表條件。IL的執行可以通過使用存儲的VOPS四元組字段進行本地檢查來實現。
4. 修剪內存池。刪除任何因新的四元組值而無效的待處理交易。

資源概況

底線。

憑藉約 8.4 GiB 的本地狀態、不變的內存池規則以及每個區塊的單一簡潔證明，zkVM VOPS 保留了以太坊的抗審查性，同時將驗證器硬件要求保持在消費級限制範圍內。

VOPS 同步

首先要強調一點。在目前的Verkle和二叉樹提案中，賬戶和存儲槽位是交錯排列的，沒有明確區分。與當前的 Merkle Patricia 樹不同，在 Merkle Patricia 樹中，賬戶構成一個獨立的子樹，這意味著 VOPS 節點不能簡單地下載快照來重建其本地賬戶表。相反，它必須重新執行創世區塊中的所有區塊。未來的統一樹設計可以添加最小語義（例如，位域）來區分賬戶和存儲，從而實現高效的快照同步。

目前，賬戶 trie 大約佔總狀態大小的1/6 。假設採用 Snap 同步方法，僅下載賬戶 trie 即可使同步速度比下載完整狀態快五到六倍，這考慮到了修復階段。修復階段所需的時間仍與現在相同，並且許多下載的數據最終會被丟棄，但同步可以從任何完整節點進行，就像現在一樣。

引導 VOPS 節點僅需要帳戶狀態（無存儲嘗試或代碼塊）以及通常的塊頭：

1. 標頭下載和驗證

   • 獲取並驗證從創世點（或受信任的檢查點）到最新頭的塊頭。

2. 逐塊更新

   對於每個新塊：

   • 取回：
     • Verkle-tree：標題+IPA 多重證明+完整交易列表
     • zkVM：頭文件 + SNARK execProof + 緊湊的stateDiff sidecar
   • 驗證並提取：
     • Verkle 樹：檢查多重證明，提取所有受影響的賬戶條目，然後根據重建的初始狀態，按順序重新執行每筆交易。記錄每個更改(address, nonce, balance, codeFlag) 。
     • zkVM：驗證 SNARK（狀態讀取、執行和 IL 規則）並解析更新的四元組的stateDiff sidecar 列表。
   • 應用：使用每個修改的帳戶條目更新本地表。

3. 內存池修剪

   • 每次更新表時，刪除任何待處理的交易，其發送者現在具有陳舊的隨機數、餘額不足或codeFlag從 0→1 翻轉（僅保留該地址的最高優先級待處理交易）。
   • 處理完所有塊之後，表格就完全是當前的了，並且內存池會像實時操作一樣強制執行有效的准入/修剪。

VOPS 和原生賬戶抽象 (AA-VOPS)

原生賬戶抽象（AA，參見EIP-7701 ）帶來了重大的範式轉變：賬戶不再是具有固定驗證規則的簡單對象，而是可以運行任意代碼的可編程實體。這種靈活性打破了僅檢查nonce 、 balance和codeFlag就足以驗證交易的假設。因此，VOPS 需要升級： AA-VOPS 。

AA-VOPS 擴展了 VOPS，使其能夠支持原生 AA，同時通過避免完全的全局狀態複製來保持節點的輕量級。每個節點不再需要跟蹤每個賬戶，而是隻跟蹤其主動關注的賬戶（針對其自身的 EOA 或與其交互的賬戶），並維護一個小型本地緩存，該緩存會隨著時間的推移逐步更新。

原生 AA 釋放了強大的新功能，同時也迫使生態系統更接近強無狀態設計，即交易必須攜帶明確的見證信息。當我們擴展 VOPS 以支持 AA-VOPS 時，我們應該仔細權衡完全原生 AA 的優勢是否值得增加這種複雜性，或者堅持更簡單的 VOPS 模型是否更能保持去中心化和效率。

AA-VOPS 與強無狀態

強無狀態性要求用戶在每筆交易中附加完整的狀態見證，涵蓋所有涉及的賬戶和存儲槽。

相比之下， AA-VOPS允許節點僅為與其自身 EOA 綁定的特定賬戶維護最新的證明。這些證明在多個區塊中保持有效，除非賬戶發生變更，並使用每個區塊中包含的輕量級stateDiffs進行刷新。

這樣就避免了每筆交易都需要大量的見證，將帶寬和存儲要求保持在最低限度，同時保持抗審查性和交易有效性。

AA-VOPS 的工作原理

本地緩存和見證維護

節點（或代表其行事的錢包或 dApp 後端）保留：

• 它自己的帳戶葉： nonce ， balance ， storageRoot和codeHash 。
• 帳戶的 AA 邏輯所需的任何額外存儲槽。
• Merkle 或 Verkle 路徑見證根據最近的stateRoot驗證這些字段。

見證一直有效，直到後續區塊修改任何所涵蓋的字段。

引導見證人：

• 節點使用來自任何完整節點或 RPC 提供程序的eth_getProof獲取初始葉和路徑一次（在 Reth 中，現在可以通過單個 RPC 調用獲取所有見證）。

增量更新：

每個區塊都提供

1. 緊湊、完整的stateDiff （如 VOPS-with-zkVM 中一樣）。
2. IL 承諾（例如，16 個 IL 簽名的集合）。此承諾允許證明者驗證區塊生產者是否已承諾遵守其在本地觀察到的所有 IL。
3. 將transactions 、 stateDiff和 IL 合規規則綁定在一起的區塊級證明（例如 SNARK）。

當一個區塊到達時，節點：

1. 驗證區塊級證明，以確保：

   • stateDiff正確編碼了從preStateRoot到postStateRoot的轉換。
   • 所有包含的交易均已正確執行。
   • IL 集中的每個交易要麼被包含，要麼被有效排除（因為塊已滿，或者交易在之前執行後變得無效）。

   （可選優化：區塊生產者可以為每個被排除的 IL 交易附加一個“失敗提示”，指出執行中失敗的索引，從而減少證明者的工作量。）

2. 如果需要，修補其見證：

   VOPS 節點（或跟蹤其自身 EOA 的錢包/dapp）檢查其任何賬戶是否出現在stateDiff中。

   • 如果存在，它會更新緩存的葉子並重新計算受影響的 Merkle/Verkle 路徑。
   • 如果不存在，緩存的見證對於新的stateRoot仍然有效。

如果節點保持在線並處理每個區塊，則它在引導後無需再次進行存檔查詢。如果節點落後，它可以通過eth_getProof重放缺失的差異或重新播種其見證數據。

交易打包

提交交易時：

• 對於 EOA 和EIP-7702賬戶，無需額外的見證。賬戶字段的最小值可在本地獲取。
• 對於EIP-7701智能賬戶，附有簡潔的單賬戶有效性證明（例如 SNARK），顯示賬戶葉的包含和正確的VALIDATE邏輯執行。

未來 AA 兼容性

如果未來的 AA 標準允許VALIDATE讀取賬戶外部數據，則發送者可以擴展附加見證，以覆蓋這些額外的存儲槽。該模型可以自然擴展。

內存池入場

接收節點使用其緩存的stateDiffs檢查更新，根據引用的stateRoot驗證見證或證明：

• 如果差異顯示賬戶沒有變化，則交易被接受。
• 如果差異表明帳戶已更改，則見證已過時，並且節點會請求更新的證明。

實際上，節點還可以維護最近 stateDiffs 的滑動窗口（例如，最後 ~N 個塊），以允許在不重新查詢的情況下進行交易驗證。

AA-VOPS 為何引人注目

• 無全局複製：

  每個節點僅存儲幾千字節，而不是 8 GiB（VOPS）或約 233 GiB（完整狀態）。區塊生產者和 RPC 提供者仍然需要完整狀態。

• AA兼容性：

  目前可與EIP-7701配合使用，並且如果驗證邏輯稍後讀取外部存儲，則可以進行調整。

• 按需引導：

  為了跟蹤新的 EOA，節點會獲取一次單個eth_getProof並通過差異保持其最新狀態。

權衡

1. 更高的P2P帶寬：

   每筆交易都帶有自己的見證或簡潔證明，平均交易大小不斷增加（Verkle 約為 736 字節，二叉樹約為 1024 字節）。

2. 用戶端證明或獲取：

   節點必須通過跟蹤差異或查詢完整節點來保持證明的最新狀態，這很容易受到集中化向量的影響。

3. 引導依賴完整節點：

   與 VOPS 不同，AA-VOPS 依賴於全節點或 RPC 提供商來初始獲取賬戶證明。如果缺少差異，節點必須通過eth_getProof重新播種，如果只有少數提供商佔據主導地位，則可能會帶來中心化風險。

結論和要點

僅驗證部分無狀態( VOPS ) 將節點的本地存儲需求減少到未壓縮的大約 8.4 GiB——僅包含(address, nonce, balance, codeFlag)四元組——同時保留了以太坊的抗審查特性。這種方法利用了賬戶和存儲槽增長之間的不對稱性：只要存儲繼續主導新的狀態條目，節省的成本仍然可觀；如果賬戶創建速度超過存儲增長速度，相對優勢就會相應減弱。

VOPS 的原始版本有兩個主要優勢：首先是無見證內存池：由於每個節點都存儲每個 EOA (address, nonce, balance, codeFlag)的四元組，因此內存池無需每筆交易都提供 Merkle 或 Verkle 證明。區塊級證明（例如 zkEVM 中的 SNARK）仍然能夠保證完全正確性，同時只會在每個區塊的傳播過程中增加幾百字節的數據。其次是真正的點對點同步：由於每個節點都維護所有 EOA 的最小狀態，因此您可以從任何對等節點引導或恢復，而無需額外的證明或單獨的帳戶數據，從而消除了對完整節點或存檔節點的依賴。

但支持原生無狀態證明 (AA) 會迫使我們做出一系列不同的權衡。AA-VOPS 通過在每筆交易中附加一個小的、最新的證明，將本地存儲空間縮減至幾千字節，但其缺點是 P2P 負載更高，並且每當您開始追蹤新賬戶、啟動節點或離線後重新上線時，都需要偶爾調用全節點或專用服務。隨著證明技術和 SNARK 的不斷改進，AA-VOPS 或將成為邁向完全無狀態的長期且面向未來的途徑。相比之下，原始的 VOPS 則脫穎而出，成為一種務實的短期解決方案，通過避免交易級見證來保持無縫的用戶體驗。