引言

在區塊鏈中，節點在處理交易時所保存和引用的資料稱爲“狀態”（State）。在以太坊中，狀態是促成節點達成共識的關鍵元素。每一個完整節點都必須在每一個有效區塊周期中，存儲並更新狀態數據。雖然狀態對區塊鏈至關重要，但也帶來顯著缺點：它會隨時間而持續增長。這種增長對像以太坊和比特幣這樣的區塊鏈構成了挑戰，因爲數據體積越大，對節點硬件的要求就越高。一旦硬件門檻過高，就會有部分節點被“淘汰”，從而加劇網絡中心化的風險。爲了解決這個問題，EIP-2935 提出了一個邁向無狀態化的解決方案：將最近 8192 個區塊的哈希值存儲於狀態中，並爲無狀態執行提供服務，從而減輕節點在數據存儲方面的負擔。

以太坊當前架構概覽

區塊

以太坊的區塊由一批交易組成，並包含對前一個區塊的引用（即區塊哈希）。這些哈希值是通過加密算法從區塊數據中得出。通過這種方式，各個區塊被串聯成鏈。同時，將交易打包執行意味着網絡中所有參與者會同時對狀態進行同步和更新。

Alt：以太坊的狀態變化

一旦新區塊被驗證者處理並廣播至網絡，其他節點會將其加入本地存儲並更新全局狀態。每個區塊的驗證者由 RANDAO（隨機去中心化自治組織）機制隨機選出。區塊的結構遵循嚴格的順序，以太坊在權益證明機制（PoS）下定義了區塊的創建和共識流程。

一個區塊由塊頭（header）和主體（body）組成。塊頭包含 slot、proposer_index、parent_root、state_root 等字段，而主體包含 randao_reveal、eth1_data、graffiti、proposer_slashings、attester_slashings、attestations、deposits、voluntary_exits、sync_aggregate 和 execution_payload 等字段。每個字段都有不同的參數，並處理不同的需求。

以太坊每 12 秒創建一個區塊（稱爲 slot），這是爲了給予網絡足夠時間同步新區塊並完成共識。在此期間：

1. 區塊提議者隨機選擇一個驗證者；
2. 驗證者打包並執行交易，得出新的全局狀態；
3. 將這些信息寫入新區塊，並通過 gossip 協議廣播；
4. 其他驗證者重新執行交易，驗證其合法性並同步狀態；
5. 驗證者確認有效後，將區塊添加至本地存儲。

區塊的“終局性”意味着它一旦被確認，就不能被篡改，除非犧牲巨額 ETH。以太坊採用“檢查點區塊”（Checkpoint Blocks）機制來管理終局性：每個紀元的第一個區塊被默認視爲該紀元的檢查點。若三分之二的質押 ETH 對該對檢查點投票確認，它們就被升級爲“已證明”。前一個已證明檢查點在下一個被確認後會被視爲“最終確認”。要撤銷一個最終確認的區塊，攻擊者必須銷毀至少三分之一的質押 ETH。此外，還有“非活躍懲罰機制”，用於懲罰因大規模驗證者失效導致無法達成共識的情況，從而恢復網絡的終局性。

處理區塊時，以太坊使用哈希函數將區塊數據轉化爲唯一字符串。每個哈希輸入會對應唯一輸出，因此區塊中的哈希值是不可更改的（除非銷毀三分之一的質押 ETH）。哈希值是通過遞歸計算 Merkle Trie 中的數據得出，最終以 blockHash 參數輸出，涵蓋區塊的全部信息。以太坊使用 Merkle Trie（Merkle 樹）結構來存儲這些哈希及其它關鍵參數。其中，使用的是改良版——Merkle Patricia Trie（MPT）。

Merkle Trie 與 Merkle Patricia Trie

Trie結構，尤其是 Merkle Trie，是區塊鏈存儲的核心。沒有 Trie，區塊鏈將退化爲無法高效處理的“獨立區塊集合”。通過 Merkle Trie 或類似架構，區塊鏈能將數據結構化，便於低性能設備參與。Merkle Trie 是一種對大量數據塊進行哈希並分層組織的方式。Merkle 化過程中，數據成對組合並哈希，遞歸執行直至生成單一的根哈希。

以太坊採用的是 Merkle Patricia Trie，這是一種將 Merkle Trie 與 Patricia Trie（實用信息檢索算法）結合的結構。用於基礎數據處理時，會使用更簡單的二進制 Trie，而在更復雜的場景（如狀態管理）中，則使用 Merkle Patricia Trie。狀態 Trie 中，Ethereum 使用鍵值對（key-value）映射來表示帳戶數據。鍵爲地址，值爲帳戶狀態。此結構比二叉 Trie 更具動態性——可以頻繁新增/刪除帳戶，不需要重算整個數據集。Trie 根哈希僅由數據內容決定，與數據插入順序無關。以不同的順序更新數據不會改變根本身。

Alt：二進制 Merkle Trie

以太坊使用的是一種修改版的 Merkle Patricia Trie，結合了 PATRICIA（實用算法用於檢索信息編碼爲字母數字）和 Merkle Trie 的一些特點，並在此基礎上進行了修改。這種架構是確定性的，並且具有加密驗證性。在這種結構中，生成狀態根的唯一方法是通過計算每個單獨狀態的值。兩個相同的狀態可以通過比較根哈希和其生成過程中的哈希值來輕鬆證明。

最終，修改狀態值是不可能的，因爲這會導致不同的狀態根哈希。以太坊執行層中的所有Trie結構都使用 Merkle Patricia Trie。網絡中有三個 Trie：State Trie、Storage Trie 和 Transaction Trie。此外，每個區塊都有自己的 Receipts Trie。盡管 Merkle Patricia Trie 在許多方面都很高效，但以太坊正在努力用 Verkle Tries 來替代它們，以實現無狀態化。

Alt: Merkle Patricia Trie

Gas

Gas 是 EVM 執行所需的屬性。由於 EVM 在執行時需要計算資源，因此這些計算的回報通過 gas 支付，以確保 EVM 的安全性。Gas 費用是根據所需 gas 量乘以每單位的成本來計算的。它是一個動態值，取決於操作的類型。

Alt: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

EIP-1559 對交易費用機制做出了重大改動。過去，支付 gas 以將交易包含到區塊中是通過類似拍賣的方式進行的。而 EIP-1559 引入了一個名爲“基本費用”（base fee）的最低限額，以及一個叫做“優先費用”（priority fee）的附加費用。區塊將從具有最高優先費用的交易開始提議。經過區塊處理後，基本費用將被銷毀，而優先費用則用來激勵驗證者。

狀態

區塊鏈狀態可以定義爲一組在特定時間點描述某個系統的數據（或變量）。互聯網幾乎從一開始就存在狀態，但這些狀態是存儲在單一服務器上的。隨着 Web3 的出現，全球狀態得以在一個開放且分布式的網絡上通過去中心化的方式得以維護。任何人都可以隨時查看和驗證這個分布式網絡的狀態。

以太坊的全球狀態包括帳戶、餘額、部署的智能合約以及相關的存儲。隨着這些參數的增加和變化，以太坊的狀態也在不斷增長。當托管全節點的硬件成本變得難以承受時，狀態的增長就成爲一個問題。針對這些挑戰，Vitalik Buterin 在 2017 年提出了無狀態以太坊的概念。爲了解決以太坊狀態增長的問題，提出了數據過期和狀態過期的解決方案。

數據過期與狀態過期的區別

數據過期

數據或歷史過期意味着在一定時間後，客戶端會剔除不需要的數據。通過“弱主觀性檢查點”，客戶端可以通過從創世區塊開始同步，並剔除歷史廢棄數據來找到正確的同步路徑。

“主觀性”指的是網絡節點依賴社交信息來就當前狀態達成共識。在這種背景下，弱主觀性指的是鏈可以在某些初始信息種子的幫助下客觀地推進。然而，弱主觀性檢查點意味着所有負責共識的網絡節點都應屬於規範鏈。弱主觀性檢查點幫助以太坊的 PoS（權益證明）從可信來源同步到最近的狀態（弱主觀性檢查點）。

EIP-4444 爲通過弱主觀性@hBXHLw_9Qq2va4pRtI4bIA/ryzBaf7fJx?ref=ghost-2077.arvensis.systems”>實現數據過期提供了可行路徑。該提案並不打算改變以太坊節點如何處理狀態數據，而是修改了訪問歷史數據的方式。

狀態過期

狀態過期旨在消除那些長時間未被訪問的節點狀態。狀態過期可以通過租賃或時間來實現。通過租賃過期意味着對存儲狀態的帳戶收取額外費用。另一種方式是通過時間過期，即如果帳戶在一段時間內未被激活，則將其標記爲非活動帳戶。

數據過期和狀態過期都是開放的研究領域。目前實現這些提議的方法通常是通過中心化網絡或提供商。到目前爲止，弱無狀態性和狀態過期在以太坊中已部分實現。

無狀態以太坊

無狀態性簡介與無狀態以太坊

無狀態以太坊引入了新的核心協議概念。理想的無狀態性並不意味着狀態不存在，而是意味着客戶端可選擇他們想要維持的狀態。當客戶端接收到經過驗證的區塊時，他們還會接收到該區塊的相應見證。每個區塊的見證包含執行該區塊中所有交易所需的所有數據。

EIP-161 提出了首個減少狀態的方案。以太坊曾遭受拒絕服務攻擊（DoS），該漏洞使得它能夠創建空帳戶，從而增加以太坊的全球狀態。EIP-161 提議通過低成本移除這些空帳戶來減少狀態。該提案已被執行，導致狀態回滾。

另一個向無狀態性邁進的努力通過 EIP-4788 的提議。該提案旨在將信標鏈塊的根暴露到 EVM 中。與 Eth1-Eth2 橋連接信標鏈（共識層）和執行層類似，該提案允許 EVM 與共識層之間的信任最小化訪問。由於每個執行塊都包含父信標塊的根，錯過的插槽事件不需要改變前一個塊的根。因此，執行的前提條件簡化爲在每個執行塊中爲一個信任最小化的預言機保留一個小空間。該提案建議在根合約中存儲小量的塊根歷史，以提高預言機的效率。

以太坊中的無狀態性可以是弱無狀態性或強無狀態性。

弱無狀態性

弱無狀態性並不會消除所有節點存儲狀態數據的需要。它的不同之處在於節點驗證以太坊狀態變化的方式。它將狀態存儲的責任交給區塊提議者，要求其他節點在不存儲完整狀態數據的情況下驗證區塊。

區塊提議者需要存儲完整的狀態數據。然而，驗證節點無需在網絡上存儲狀態數據。相反，它們可以存儲狀態根（即整個狀態的哈希）。弱無狀態性要求區塊提議者與構建者分離（Proposer-Builder Separation，PBS）並實施 Verkle Tries。

提議者使用狀態數據創建見證，以證明狀態變化，驗證節點根據狀態根哈希驗證這些證明。

強無狀態性

強無狀態性消除了任何節點存儲狀態數據的需求。它通過結合區塊提議者聚合的已發送交易和見證來實現。區塊提議者只需存儲它們正在處理的狀態，爲相關帳戶生成見證。該提案仍需進一步開發，包含像訪問列表或 EIP-2930 等要求。

然而，通過一些改變和特性，可以實現無狀態性。EIP-2935 提議通過從狀態中提供歷史塊哈希來實現無狀態執行。

EIP-2935 簡介

EIP-2935 旨在將歷史塊哈希存儲在區塊鏈的狀態中，使用特殊的存儲槽稱爲 HISTORY_STORAGE_ADDRESS。這個過程通過便捷地訪問無狀態客戶端所需的歷史信息，來實現無狀態執行。

EIP-2935 提議將最後 8192 個歷史塊哈希存儲在一個系統合約中，作爲區塊處理邏輯的一部分。這個提案試圖解決的問題是 EVM 假設客戶端有最近的塊哈希的前提。基於這種假設的做法不適用於未來的以太坊，特別是無狀態客戶端。

將前一個塊哈希包含在狀態中，將允許將這些哈希與哈希函數捆綁在見證的視圖中。隨後，見證將提供給無狀態客戶端以驗證執行並實現無狀態執行。這個提案被稱爲 pre-Verkle 規範化，因爲它可以在核心協議適應 Verkle tries 之前實現，並促進部分無狀態性。

將 blockHash 的範圍擴展到 8192 個塊，將有助於向執行方法的平滑過渡。Rollup 可以通過直接查詢這個合約來受益，因爲 blockHash 數據存儲在該合約中。此外，這個 EIP 將促進驗證與 8192 個塊的 HISTORY_SERVE_WINDOW 相關的證明與當前狀態的一致性。

了解 EIP-2935

EIP-2935 允許以太坊客戶端，特別是無狀態客戶端，輕鬆訪問最近的塊哈希。爲使其生效，提出了四個新的參數：

• BLOCKHASH_SERVE_WINDOW：告訴客戶端應該保留多少個過去的塊哈希。默認值爲 256。
• HISTORY_SERVE_WINDOW：定義存儲多少個塊的哈希。默認值爲 8191。
• SYSTEM_ADDRESS：一個特殊地址（最初在 EIP-4788 中引入），作爲“調用者”將塊哈希寫入存儲。
• HISTORY_STORAGE_ADDRESS：這些塊哈希存儲的合約地址。

該提案的規範指示將最後 HISTORY_SERVE_WINDOW 個塊哈希存儲在一個長度爲HISTORY_SERVE_WINDOW 的環形緩衝存儲中。

環形緩衝區

EIP-2935 使用了一個名爲環形緩衝區的附加功能用於臨時存儲。環形緩衝區是一種允許網絡重用相同存儲位置存儲不同數據的屬性。在 EIP-2935 中，環形緩衝區僅用於提供必要的 HISTORY_SERVE_WINDOW，因爲 EIP-4788 和信標狀態累加器允許對任何祖先進行證明。

分叉選擇規則與規範

在網絡分叉之後，當網絡啓動時，考慮到這些 EIP，HISTORY_STORAGE_ADDRESS 參數將被稱爲 SYSTEM_ADDRESS，並接受 block.parent.hash 輸入（默認 32 字節），gas 限制爲30,000,000，值爲 0。這個過程將觸發歷史合約的 set() 函數。

提案後的分叉過程與常規的分叉過程有所不同。這個 set() 操作是一個通用的系統操作，但它遵循以下約定：

• 必須執行完畢
• 不計入區塊的 gas 限制
• 不遵循 EIP-1559 的銷毀機制
• 如果 HISTORY_STORAGE_ADDRESS 處沒有代碼，調用必須失敗，但不導致致命錯誤

這個過程必須填充區塊周期 HISTORY_SERVE_WINDOW，以滿足環形緩衝區的觸發周期。歷史合約將只包含分叉區塊的父哈希，作爲參考哈希和新的哈希起始點。

區塊哈希歷史合約將有兩個操作：get() 和 set()。當合約的調用者在交易中等於通過 EIP-4788 引入的 SYSTEM_ADDRESS 時，將激活 set() 操作。如果調用者與 SYSTEM_ADDRESS 不相等或不滿足條件，將激活 get() 操作。

get() 操作用於 EVM 中定位區塊哈希。它允許調用者提供他們查詢的區塊號，如果 calldata 輸入不是 32 字節（即有效的 block.parent.hash），或者請求超出了範圍（[block.number - HISTORY_SERVE_WINDOW, block.number - 1]），則事務會被回滾。

set() 在調用合約的交易中接收 block.parent.hash 作爲 calldata 輸入。它還將存儲值設定爲 calldata[0:32]，存儲位置爲 block.number-1 % HISTORY_SERVE_WINDOW。

HISTORY_STORAGE_ADDRESS 將通過 EIP-4788 部署，正如上述所提到的，通過共識層直接訪問 EVM 中的區塊哈希。HISTORY_STORAGE_ADDRESS 將具有 nonce 值爲 1，並且不受 EIP-161 的零 nonce 清理標準的限制。

BLOCKHASH 轉換邏輯

與該 EIP 相關的一個問題是，如何在分叉之後最佳地過渡 BLOCKHASH 解析邏輯。正在考慮兩種主要方法：

• 等待 HISTORY_SERVE_WINDOW 個區塊，以便整個相關歷史得以保留。
• 在分叉區塊中存儲所有最後 HISTORY_SERVE_WINDOW 個區塊的哈希。

開發者選擇了第一個選項。它更具實用性，因爲它不需要任何臨時更改。

EIP-2935 與類似 EIP 的區別

以前曾提出類似的 EIP，以允許並實現無狀態執行。EIP-2935 與這些先前的提案不同，因爲它解決了以下復雜性：

• Trie 結構方法：EIP-2935 不使用類似 Trie 的多層結構，而是選擇了一個單一列表。相比之下，EIP-4444 提出了在執行客戶端中修剪一年以上的歷史數據。其他具有類似目標的 EIP 需要 Verkle Trie。
• 在 EVM 代碼中編寫 EIP：EIP-2935 不需要改變 EVM。
• 哈希的串行無限制存儲：串行無限制的哈希存儲效率低。該 EIP 通過將哈希進行打包來克服這個問題。

安全性考慮

由於 EIP-2935 使用了智能合約，它可能面臨分支中毒攻擊的風險。然而，狀態根的大小減緩了任何更新嘗試變，大大提高了中毒攻擊的成本。

它能帶來什麼？

• 提高無信任預言機系統的速度：在基於 Uniswap v2 的預言機中，任何具有以太坊節點訪問權限的人都可以生成 Uniswap 存儲的證明，並提交給鏈上驗證。平均價格是在當前區塊和提供的證明區塊之間的價格，已驗證的證明最多爲 256 個區塊，因爲 blockHash 支持最多 256 個區塊。受益於 EIP-2935，該過程可以通過允許訪問更早的區塊哈希來改進，這意味着證明可以在更長的時間內進行驗證。
• 允許合約無信任地考慮過去的狀態斷言：EIP-2935 的改進創造了從 EVM 內部無信任地查看區塊鏈數據的可能性。客戶端可以查詢歷史數據，獲取哈希，並與其他節點進行驗證。這個解決方案可以使輕客戶端更加高效且易於實現。
• L1 <> L2之間的橋接：要驗證來自 L2 的消息，L1 需要了解 L2 的狀態根和區塊哈希。然而，當前 L1 由於 gas 限制和架構約束，無法訪問任意的區塊哈希。EIP-2935 使 L1 能夠驗證任意歷史數據，並能夠探測舊事件的包含證明。這樣可以改善訪問和驗證能力，提升橋接性能。

結語

EIP-2935 代表了實現無狀態以太坊長期目標的重要一步。將最後 8192 個區塊哈希存儲在狀態中的專用合約內，解決了當前設計中的一個根本限制：以太坊假設客戶端天然擁有訪問最近區塊哈希的能力。在無狀態執行的背景下，客戶端不再維護完整的狀態，這一假設已經過時。EIP-2935 通過引入一種輕量、高效、無幹擾的機制，解決了這一問題，使無狀態客戶端能夠在不修改 EVM 或依賴復雜數據結構（如 Verkle Trie）的情況下訪問必要的歷史數據。

除了無狀態執行外，該提案還爲以太坊生態系統帶來了更廣泛的利益。它增強了無信任預言機的能力，擴展了輕客戶端的可用性，並通過使 L1 能夠可靠地驗證較舊的狀態數據，增強了 L1 和 L2 解決方案之間的互操作性。其實現依賴於一個簡潔且 gas 高效的設計，使用環形緩衝存儲和系統級合約，避免了在 EVM 中硬編碼，提供了簡便性和可擴展性。

隨着以太坊朝着更高去中心化、可擴展性和可訪問性發展，EIP-2935 成爲了一個基礎性改進。它彌合了當前有狀態架構和預期的無狀態未來之間的鴻溝，並爲區塊鏈生態系統內更強大、高效和無許可的基礎設施奠定了基礎。

聲明：

1. 本文轉載自 [2077research]。所有版權歸原作者所有 [Yiğit Yektin]。若對本次轉載有異議，請聯系 Gate Learn 團隊，他們會及時處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明，否則禁止復制、分發或抄襲翻譯文章。