---
title: "狀態根（State Root）"
description: "狀態根是以太坊對區塊執行後世界狀態的精簡承諾。本文說明節點如何計算狀態根、帳戶與儲存證明能證實什麼，以及狀態根無法保證什麼。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 狀態根（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 資料必須另行取得。
- **狀態根相同就證明兩個節點的資料庫完全相同。** 它們承諾的是協議規則下相同的邏輯世界狀態，但用戶端可以採用不同的儲存、索引、修剪或快取方式。
- **狀態根不同就能指出哪筆交易出錯。** 它只能顯示最終承諾狀態存在分歧，不能定位分歧從何處開始；用戶端必須追蹤執行過程才能診斷。
- **有效的帳戶證明同時證明最終性與安全性。** 它只證明資料與某一個根一致。鏈選擇、最終性、資料新鮮度、合約行為和經濟風險仍是獨立問題。
## 相關主題
- [帳戶模型](/zh-tw/crypto/account-based-model/)
- [Merkle 樹](/zh-tw/crypto/merkle-tree/)
- [全節點](/zh-tw/crypto/full-node/)
- [輕量用戶端](/zh-tw/crypto/light-client/)
- [區塊確認](/zh-tw/crypto/block-confirmation/)
## 來源
- [Ethereum Execution Specifications: Block Header](https://ethereum.github.io/execution-specs/src/ethereum/forks/frontier/blocks.py.html) - Ethereum Foundation（查閱日期：2026-08-21）
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) - Ethereum Foundation（查閱日期：2026-08-21）
- [EIP-1186: RPC-Method to get Merkle Proofs](https://eips.ethereum.org/EIPS/eip-1186) - Ethereum Improvement Proposals（查閱日期：2026-08-21）
Source: https://wiki.fcontext.com/zh-tw/crypto/state-root/index.mdx