一種狀態保質期和無狀態性的路线圖

以太坊的狀態的規模正迅速增長。當前僅存儲狀態大概是 35 GB，如果加上默克爾證明就是 100 GB 了；而且現在預計每年都要增長這個數字的一半。此外，狀態存儲也是以太坊經濟模型的一個短板：在這個機制中，用戶只需付費一次就可以給共識節點施加永久的負擔。為了保持以太坊的可擴展性和可持續性，我們需要一些解決方案。

有兩種路徑，而且都已經存在很長時間了：“弱無狀態性” 和 “狀態保質期”：

• 狀態保質期：從狀態中移除近期（比如，去年）無人訪問的狀態對象，並要求在復活狀態對象時提供見證數據（witness）。可以將每個節點都需要存儲的狀態數據減少到扁平的約 20 ～ 50 GB。

• 弱無狀態性：僅要求區塊提議者存儲狀態，其他節點都可無狀態驗證區塊。在實踐中，需要把狀態共識形式（從默克爾樹）切換到 “Verkle Tree”，以縮減見證數據的規模。

本文提出了一種多階段的方案，來同時實現這兩種方案。因為，可以證明，這會比按順序實現這兩個（無論什么順序）容易很多。如果不實現 Verkle 樹，狀態保質期方案下就需要非常大的見證數據來證明一個舊狀態；如果不實現狀態保質期，切換到 Verkle 樹就需要一個一步到位的切換流程（例如 EIP 2584），這幾乎跟只實現狀態保質期一樣復雜。如果合二為一，同時進行，它們就解決了彼此面臨的挑战：狀態保質期方案包含了每年創建一棵新狀態樹的機制，因此 Verkle 樹可以分階段逐步建構，而無需一個一步到位的切換流程，而 Verkle 樹也解決了見證數據規模的問題。

鏈接：“狀態保質期” 和 “無狀態性” 概念的歷史

• 無狀態客戶端的概念，於 2017 年始發於 ethresear.ch 論壇：https://ethresear.ch/t/the-stateless-client-concept/172（亦可見 EthHub）

• 狀態租金（狀態保質期的前身），始發於 2015 年：https://github.com/ethereum/EIPs/issues/35

• ReGenesis（Alexey Akhunov 的提議，可以認為是 狀態保質期 + 歷史過期 的一種形式）：https://medium.com/@mandrigin/regenesis-explained-97540f457807 

• Verkle 樹：https://notes.ethereum.org/_N1mutVERDKtqGIEYc-Flw

• （演講）約束見證數據的大小：https://www.youtube.com/watch?v=qQpvkxKso2E

• 一種狀態規模管理理論（2021 年 2 月）：https://hackmd.io/@vbuterin/state_size_management

• 最小化復活衝突的狀態約束方案：https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739

• 實現無狀態性和狀態保質期的路徑：https://hackmd.io/@vbuterin/state_expiry_paths

回顧：狀態保質期如何工作？

這裏所描述的是此提案的機制。

核心想法是，每個周期（比如以一年為一個周期）都會有一棵狀態樹，每當一個周期开始時，就初始化一棵空狀態樹，所有的狀態更新都寫到這顆狀態樹上。在一個周期內，所有的寫入都會發生在最新的狀態樹上（所以新樹和老樹可能會存儲同樣的信息，也可能會發生衝突；那么總是以更新的樹為優先）。

- 注意：我之前曾把這個約長一年的狀態保質期周期稱為 “epoch”，現在都稱為 “period”，以免與信標鏈的術語相混淆 -

兩個關鍵原則是：

• 只能修改最新的那棵樹（也即對應於當前周期的樹）。所有更老的樹都不能再修改；更老的樹上的對象只能在更新的樹上創建副本，而且這些副本會取代更老的副本。

• 可以預期全節點（包括區塊提議者）只會保存最近的兩棵樹，所以只有最近的兩棵樹上的對象才能不需要 witness 就能讀取。讀取更老的對象就需要提供見證數據了。

“見證數據” 就是一個簡短的證據，證明某個值（或者某一組值）存在於某棵樹的某個位置上，而且驗證的一方只需具有樹根即可。舉個例子，可以制作 一個 witness 來證明账戶 0x124f...89ab 的存儲空檔 123 處在某時的狀態下，包含的值為 50；任何人都只需要這棵狀態樹的根值就可以驗證這個證據。

狀態保質期產生了一種混合的狀態機制：共識節點需要保存最近被人訪問和修改過的狀態，但可以使用基於見證消息的無狀態客戶端方法來驗證更老的狀態。也就是說，也可以維護一個 “歸檔節點”，存儲所有歷史狀態樹，或者 一個完全無狀態的節點，使用見證數據來驗證哪怕是最新的狀態。不過，gas 消耗量的結構和默認的網絡格式，都要圍繞 “節點會存儲最近的兩棵狀態樹” 來开發。

路线圖

遷移將按階段來實現：

• 周期 1 硬分叉：需要一個硬分叉來开啓第一個周期（此前的則都算是第 0 個周期）。分叉之後，就會出現兩棵狀態樹：十六叉的帕特裏夏樹（已凍結，不可再編輯）以及一棵新的 Verkle 樹（包含所有新的狀態 編輯/增加，還有舊狀態的副本）

• EIP 草案：https://notes.ethereum.org/@vbuterin/verkle_tree_eip

• 地址擴張周期：地址從 20 字節擴充到 32 字節，而新地址的格式包含一個 “地址周期” 的概念（曾用名 “地址空間（address space）”）。這樣新合約就可以無需提供見證數據而直接寫入新的存儲空檔。這一步什么時候做都可以，只需要在最終狀態保質期轉型完成之前就可以了，在周期 1 分叉之前或之後都可以。

• VB 的方案 ：https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485

• Ipsilon 團隊的方案：https://notes.ethereum.org/@ipsilon/address-space-extension-exploration

• 周期 2 硬分叉：需要一個硬分叉來开啓周期 2，並安排未來周期的時點。周期 0 的十六叉的帕特裏夏樹將被一棵 Verkle 樹替換，客戶端僅存儲其狀態根。從這時开始，周期 0 的狀態將需要見證數據來訪問。並且，狀態保質期方案也算是完整實現了。

• EIP 草案：https://notes.ethereum.org/@vbuterin/state_expiry_eip

原文鏈接:

https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal

作者: Vitalik

翻譯: 阿劍

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。