跳到正文
Financial Context Wiki

狀態根（State Root）

狀態根是以太坊對區塊執行後世界狀態的精簡承諾。本文說明節點如何計算狀態根、帳戶與儲存證明能證實什麼，以及狀態根無法保證什麼。

更新於

僅供教育參考，不構成投資建議；投資可能產生損失。

直接答案

狀態根是以太坊區塊標頭中的一個 32 位元組密碼學承諾，對應區塊處理完成後的世界狀態。世界狀態把位址映射到帳戶。每個帳戶承諾其 nonce、餘額、儲存根和程式碼雜湊；每個合約的儲存根又承諾該帳戶的各個儲存槽。

狀態根是摘要，不是可下載的快照。節點可用它比較各自獨立計算的結果，驗證者也可依據可信區塊核驗帳戶或儲存證明。僅憑狀態根無法重建狀態、證明狀態資料可用、確認區塊已最終確定，也無法表明合約在經濟上安全。

「狀態根」取決於具體協議。以太坊目前使用修改版 Merkle-Patricia trie 承諾執行層狀態。其他網路可能採用不同的狀態模型、編碼、雜湊函數或認證資料結構，因此名稱相同不代表其根或證明可以互換。

運作原理

執行用戶端從父區塊狀態開始，依照目前生效的協議規則驗證並執行新區塊，再套用由此產生的帳戶與儲存變更。可概括為：

S_n = Υ(S_(n-1), B_n)

其中 S_(n-1) 是父狀態，B_n 是新區塊規定的全部協議處理，S_n 是結果狀態。用戶端以確定性方式把狀態編碼進狀態樹並計算根雜湊。有效區塊標頭必須包含相同結果；若不一致，該用戶端就必須判定區塊無效。

在以太坊狀態樹中，帳戶路徑由位址衍生，編碼後的帳戶包含 nonce、餘額、儲存根和程式碼雜湊。合約程式碼透過其雜湊引用，每個合約另有一棵儲存樹。這種巢狀關係表示一個儲存槽變更可依序改變合約儲存根、編碼後的帳戶，最終改變全域狀態根。

狀態根不同於同一區塊標頭中的交易根和收據根。交易根承諾依序排列的交易資料，收據根承諾執行收據，三者不能彼此取代。

EIP-1186 定義了 eth_getProof，可傳回指定區塊的帳戶證明與所要求的儲存證明。驗證者仍須取得經認證的區塊雜湊或狀態根，使用正確的 trie 與編碼規則，並採用適當的確認或最終性策略。

範例

假設一筆交易把 ETH 從 Alice 轉給 Bob。正確執行可能改變 Alice 的 nonce 和餘額、Bob 的餘額以及手續費接收方的餘額。若交易呼叫合約，儲存槽和合約儲存根也可能改變。即使絕大多數帳戶未被觸及，這些更新仍會產生新的全域狀態根。

兩個誠實用戶端若從同一父狀態出發，並依照相同規則處理同一有效區塊，應計算出相同的根。若某個用戶端計入錯誤金額或使用錯誤的 trie 編碼，其結果會與區塊標頭不同；它必須拒絕該區塊，不能默默接受本機狀態。

若要在不下載整個世界狀態的情況下核驗 Bob 的餘額，驗證者可取得區塊標頭和帳戶證明。重新計算證明路徑，可以判斷編碼後的帳戶是否與該標頭的狀態根一致。這不能證明所選標頭屬於規範鏈或已最終確定；這些結論來自驗證者的鏈選擇與最終性檢查。

風險

  • 不可信的根： 針對攻擊者選擇或過時的根，即使證明有效，也只是證明錯誤的參照點。應把根綁定至已驗證的區塊雜湊、鏈 ID 和區塊高度。
  • 重組與最終性： 證明可能正確對應一個後來脫離規範鏈的區塊。確認深度或最終性要求應與應用程式的損失承受能力相符。
  • 編碼錯誤： 位址雜湊、RLP 編碼、nibble 路徑、內嵌節點和儲存鍵處理必須嚴格遵循協議規則。通用二元 Merkle 證明函式庫並不足夠。
  • 資料缺失： 根承諾狀態，卻不會讓 trie 節點、歷史狀態或證明產生服務自動可用。經過修剪的節點可能無法提供舊證明。
  • 誇大保證： 根一致能發現執行結果不一致，但不會稽核合約邏輯、認證預言機輸入、保護 RPC 端點、保證資產價值，也不能阻止金鑰外洩後授權的交易。

常見誤解

  • 狀態根存放每個帳戶的餘額。 它只是對編碼後 trie 的定長承諾，底層 trie 資料必須另行取得。
  • 狀態根相同就證明兩個節點的資料庫完全相同。 它們承諾的是協議規則下相同的邏輯世界狀態，但用戶端可以採用不同的儲存、索引、修剪或快取方式。
  • 狀態根不同就能指出哪筆交易出錯。 它只能顯示最終承諾狀態存在分歧，不能定位分歧從何處開始；用戶端必須追蹤執行過程才能診斷。
  • 有效的帳戶證明同時證明最終性與安全性。 它只證明資料與某一個根一致。鏈選擇、最終性、資料新鮮度、合約行為和經濟風險仍是獨立問題。

相關主題

來源

導覽

搜尋知識庫...