狀態到期:協議內 vs. 協議外

本文為機器翻譯
展示原文

狀態到期:協議內 vs. 協議外

狀態增長仍然是主要的性能和去中心化瓶頸。它會導致節點同步時間延長,從而降低區塊執行性能並增加存儲需求。這與歷史增長(舊區塊/收據)不同,EIP-4444 允許客戶端進行修剪。最近對狀態訪問模式的實證分析表明,狀態使用情況高度不均衡——大多數交易只涉及一小部分熱狀態,因此移除冷狀態有助於顯著減輕節點負擔。

狀態過期機制的主要目的是減緩狀態的增長速度(甚至保持恆定)。它建議將冷狀態從活躍集合中移除,並在再次訪問時要求提供復活證明。到目前為止,有兩個阻礙因素導致我們無法順利推出狀態過期機制:

  1. 用戶體驗:用戶如何檢索復活的證據。
  2. 對過期狀態對象進行廉價、強大的標記

隨著我們邁向實時證明和無狀態世界,狀態到期機制究竟該如何運作尚不明確。因此,本文做了兩件事:

  • 繪製真正需要狀態的地圖以及狀態到期如何幫助實現當今和未來可行的路線圖。
  • 通過具體的權衡比較協議內協議外的狀態到期情況。

誰掌管國家?

今天(2025年)

TL;DR:大多數節點必須保持狀態。

  1. 驗證器:根據活動狀態構建、執行並驗證區塊。實際操作仍假設區塊處於完整狀態。
  2. 建造者:協議外。少數實體構建了大部分區塊(參見“誰贏得了區塊建造拍賣? ”中的集中討論)。它們維護狀態以進行模擬和構建區塊。
  3. RPC 節點:通常運行全節點。有些節點可能使用跟隨者模式(例如Besu 的艦隊模式),其中較輕的節點從受信任的全節點檢索狀態增量。

如果我們現在發佈協議內狀態到期:每個人都會從中受益——執行的活動狀態更小、同步速度更快、狀態讀/寫延遲更低、增加 gas 限制時的風險更小。

長期(ePBS + 無國籍)

TL;DR:只有構建器必須保持狀態,而其他構建器可以是無狀態的。

假設已確立的 PBS( EIP-7732 )和抗審查機制(例如FOCIL ),加上無狀態性,即(a)區塊中的 Verkle/Binary trie 見證或(b)區塊執行 ZK 證明:

  1. 提議者/證明者——通過見證或證明進行驗證。無需全局狀態。理想情況下,僅有效性部分無狀態(VOPS)可確保公共內存池的健康。
  2. 建造者:需要狀態才能建造區塊。使用 FOCIL(無需攜帶見證的交易),建造者預計可以訪問完整的狀態。
  3. 證明者:需要國家訪問權限來檢索用於生成證明的證人。
  4. RPC 節點:趨向於部分無狀態( 本地節點優先),其中每個節點僅存儲其關心的狀態,但理想情況下仍為 VOPS。

在這個世界中,狀態到期主要惠及構建者,他們承擔了狀態增長的大部分成本。如果沒有到期,構建者必須提供越來越重的硬件,從而進一步加劇構建者的中心化。

如果證明者與構建者不同,那麼它們可以是無狀態的。但無狀態證明者仍然需要從持有完整狀態的節點檢索狀態見證,因此狀態過期機制也能在實時證明的世界中降低成本並提高效率。

進還是出?

協議內狀態到期

“協議內”是指到期規則在共識機制下生效。狀態對象僅攜帶少量元數據,這些元數據會在狀態訪問(讀取、寫入或兩者兼有)時更新。如果對象在訪問時已過期,則必須將其恢復(通常通過交易)並附加見證信息。EIP -7736 (Verkle/二叉樹的葉級到期)就是一個例子。

為什麼它很好

1. 明確責任邊界
如果您的狀態已過期,有責任查找並提供證明。無需擔心“我的舊狀態由誰託管?”的問題。

2. 保持本地建設的可能
在無狀態的世界裡,較小的活躍狀態能夠保持本地構建者的活力,並抑制構建者的集中度。然而,不可否認的是,在目前的現狀下,少數構建者生產了以太坊的大部分區塊。

3. 剩餘有狀態節點的優勢
在一個無狀態證明者的世界裡,如果大多數參與者都是無狀態的,那麼同步完整狀態將極具挑戰性,甚至完全不可能。因此,我們仍然應該預期一些節點會持有完整狀態並以利他主義的方式提供服務(例如快照同步)。協議內到期規則可以減輕他們的負擔。然而,這種對利他主義的依賴可以通過去中心化狀態網絡(例如Portal 網絡)來緩解,該網絡無需依賴利他主義的有狀態節點即可保存和服務狀態。儘管 Portal 本身就是一個利他主義系統。

4.可預測的用戶體驗界面
錢包可以針對單一到期規則,而不是拼湊的構建器策略。

為什麼很難

1. 復活用戶體驗
錢包需要強大的多對象恢復流程(例如批量證明),以避免狀態恢復過程中的多次跳躍。方案越精細(例如插槽級別 vs. 賬戶級別),用戶體驗就越難。

2. 誰託管過期狀態?
狀態過期並不意味著狀態對象永遠消失。我們仍然需要狀態服務基礎設施——理想情況下是去中心化的。依賴可信證明提供者在短期內或許是可以接受的,前提是該方案能夠真正精簡對約 99.99% 用戶無用的狀態。然而,這樣做的代價是,較少的冷狀態往往會被精簡。

3. 複雜性和 DoS 攻擊
必須存儲到期元數據,這會增加存儲開銷。到期方案越細粒度,此開銷就越高。恢復的複雜性也取決於方案:例如,多樹到期方法中的恢復比EIP-7736等葉級設計更復雜。用戶還需要承擔恢復過期狀態的額外成本。

超出協議狀態到期

協議外意味著共識不會改變。節點可以採用社會協調的到期策略(例如鏈上或鏈下注冊表)。節點可以丟棄狀態,並期望用戶提供自己的證明——但鏈不會強制執行。

為什麼它很好

1. 降低以太坊協議的複雜性
構建者可以靈活地確定到期規則並快速迭代。策略可以通過社交或鏈上配置進行協調。這可能比分叉更容易。

2. 更快的迭代和可逆性
構建者可以更有創意地測試不同的修剪方案。如果策略適得其反,回滾將立即在本地進行。錯誤的到期設置會降低構建者的服務質量(例如,錯過 MEV、延遲增加),而不是造成全局共識風險或全鏈 DoS 攻擊。

3. 生態系統可堆肥性
為去中心化狀態網絡和商業見證服務創造了明確的需求。兩者可以在延遲、覆蓋範圍和價格方面展開競爭,而無需協議耦合。提供有效見證的協議外費用可以作為側邊市場進行試點。

4. 過渡到協議內
實際使用情況可能會影響最終的協議內到期時間(如果需要)。這也比從一開始就進行協議內操作更容易。

5.統一訪問層(當DA較強時)
如果存在一個快速、無需許可的狀態網絡,那麼協議外方案就顯得尤為重要。任何無狀態或部分無狀態節點都可以按需獲取見證信息。節點無需分叉即可獲得大部分到期收益,而錢包則使用一條簡單的、以證明為中心的訪問路徑。

為什麼很難

1. 用戶體驗和數據可用性不一致
不持有特定狀態的構建器會要求用戶提供見證。這反映了協議內的用戶體驗負擔,但無法保證任何構建器仍然持有您的狀態。如果策略基於社會共識,應用工具必須跟蹤多條規則,這會使用戶體驗更加複雜。

2. 誰託管過期狀態?
與協議內狀態過期問題相同。然而,在協議內的情況下,所有權定義明確(即你的狀態由你負責)。而在協議外的情況下,所有權定義不太明確,因此數據永久丟失的可能性更高。

3. 審查向量
如果“我們不控制你的狀態”是一項可接受的政策,那麼外部壓力可以將其武器化以排除特定的合同,從而有效地將其轉變為審查攻擊。

4. Builders + FOCIL 細微差別
如果納入列表中的交易不包含見證,構建者實際上需要訪問完整狀態,因此協議外到期的動機就會降低。如果證明性能更佳,構建者可以採用熱冷狀態隔離。

如果包含列表中的交易確實帶有見證,則構建器可以是部分無狀態的,但這會成為另一條協議內規則,從而降低用戶體驗,因為現在所有交易都必須帶有見證(又稱強無狀態)。

5.同步狀態
當操作員進行協議外修剪時,狀態可用性在對等點之間是不一致的。同步完整狀態可能會更加困難,甚至不可能。

國家復興的挑戰

一般來說,任何形式的狀態過期(無論是進入還是退出)都必須處理恢復問題。以下是一些挑戰:

復活跳躍

假設你想向一個長期閒置的賬戶發送 1 個ETH和一些Dai 。首先,賬戶查詢顯示該賬戶已過期,因此交易失敗。你需要獲取一個證明並恢復該賬戶。接下來, Dai轉賬會觸及代幣的存儲,而這些存儲也已過期。你必須獲取額外的證明並恢復這些存儲。這種反覆的交互就是“復活跳躍”問題。

協議內過期的情況更糟,因為每次復活通常都需要提交一筆交易。一筆交易涉及的過期對象越多,跳數和費用就越高。協議外過期也面臨同樣的發現/獲取循環,但跳數是在鏈下(沒有額外的交易),但仍然會增加額外的延遲。

可能的緩解措施

  1. 針對全狀態預言機預先模擬交易,以枚舉在提交用戶交易之前必須復活的所有賬戶和存儲槽。
  2. 減少到期粒度(例如,帳戶或合約級別與插槽級別),以消除需要復活的不同對象的數量。
  3. 批量恢復:支持單個捆綁證明,以原子方式恢復多個賬戶/槽位,並設置明確的字節上限以控制 DoS 風險。Blob 可以降低交易成本,但由於它們是瞬態的,因此恢復負載必須永久存儲在其他地方,並向所有人開放。

哪裡可以得到狀態?

  1. RPC 提供程序
    為國家提供證據的第三方基礎設施(商業或公共)。

    • 優點
      • 如今已廣泛普及
      • 可以提供保證數據可用性的服務級別協議 (SLA)
      • 自然地有動機保留完整狀態,以便“出售”對過期狀態的訪問權
    • 缺點
      • 信任與審查風險:RPC 提供商可以選擇或被迫審查某些狀態,從而拒絕狀態復活
      • 用戶付費來檢索狀態(除了協議內狀態到期的復活交易)
  2. 客戶端託管提供商
    EL 客戶端團隊可以託管過期狀態的靜態文件/快照,這些文件在定義的有效期內有效,類似於區塊數據的紀元文件。當規範鏈進入新的過期期限時,這些文件會刷新。Erigon 和 Reth 在其狀態同步架構中使用了類似的快照機制。

    • 優點
      • 提高社區信任度和透明度
      • 可以協調狀態文件和響應格式以最大限度地減少復活延遲
    • 缺點
      • EL 客戶團隊的額外基礎設施和維護負擔
      • 這仍然需要信任團隊持有所有過期狀態。如果狀態不可用,用戶必須回退到 RPC 提供程序或從其他地方獲取。
  3. 利他主義的 snap 同步同伴
    依靠提供狀態塊(Snap 同步)的對等節點來組裝證明所需的賬戶/槽位。這建立在一個假設之上:即使狀態過期,仍然有擁有完整狀態的節點會無私地處理 Snap 請求。

    • 優點
      • 今天已經生效
      • 避免依賴特定的可信提供商
    • 缺點
      • 隨著更多節點修剪過期狀態,假設可能會失敗。也就是說,新創建的節點無法再進行快照同步。
      • 隨著全狀態節點數量的減少,復活的用戶體驗會下降。在最壞的情況下,用戶必須回退到受信任的提供商
  4. 去中心化國家網絡
    無需許可的網絡,存儲完整狀態,並提供狀態證明。Portal 網絡的狀態網絡就是一個這樣的例子。

    • 優點
      • 抗審查
      • 內置複製功能可降低狀態丟失的風險
    • 缺點
      • 截至今天,尚無生產級部署
      • 參與在很大程度上是利他的,沒有激勵措施,這可能會限制負載下的可靠性
  5. 通過彩虹質押激勵節點持有部分狀態
    將狀態服務視為彩虹質押“非捆綁角色”(重度 vs 輕度)中的輕度服務。運營者承諾存儲部分狀態並提供可驗證的見證,而委託人則為這些運營者分配權重。

    • 優點
      • 去中心化
      • 協調激勵措施:持續的、協議原生的獎勵,以保持狀態可用,減少對利他主義的依賴
    • 缺點
      • 目前仍處於研究階段,需要對運營商選擇和獎勵核算進行具體的設計

方案五是最佳的長期方案,但實施起來需要時間。方案二在短期內更為現實。

下一步是什麼?

如果我們重視獨立開發者和可預測的用戶體驗,那麼協議內狀態過期仍然是更安全的長期支撐點。在當今世界,狀態過期顯然有所幫助。但用戶體驗負擔和數據無法恢復的風險使得立即啟用不太可能。

短期內,我們應該嘗試非協議方案。將非協議方案視為解決相同問題且不承擔共識風險的原型,同時探索實際問題(例如狀態可用性)並不斷迭代解決方案。如果非協議到期方案被證明可靠且用戶友好,我們可以考慮在以後將其納入——前提是真正需要它。

結束語

儘早發佈狀態到期信息可帶來立竿見影的益處——更小的活躍狀態、更快的同步速度、更安全的 Gas 空間。在無狀態的未來,這些益處大部分將歸於構建者、證明者和少數有狀態提供者——而這些正是中心化壓力集中的地方。從協議外到期開始,可以快速抓住這些優勢,暴露風險(見證可用性、DoS 攻擊、用戶體驗),並讓我們能夠在沒有共識風險的情況下進行迭代。

最重要的是,服務於狀態的基礎設施至關重要。隨著我們走向無狀態和狀態失效,網絡需要公開、可靠、無需許可的方式來持續檢索狀態和見證信息。

底線:網絡不能允許永久丟失狀態。

進一步閱讀

致謝

特別感謝 Guillaume、Carlos 和 Ignacio 審閱本文。


來源
免責聲明:以上內容僅為作者觀點,不代表Followin的任何立場,不構成與Followin相關的任何投資建議。
喜歡
收藏
評論