狀態樹

加密貨幣中的狀態樹是什麼？

狀態樹是一種加密資料結構，用於儲存區塊鏈目前狀態，並可有效更新、驗證，以及透過單一根雜湊值進行摘要。

在 Ethereum 類型的區塊鏈中，狀態樹會將帳戶地址對應至帳戶資料，例如餘額、nonce、智能合約儲存根、程式碼雜湊值。

官方 Ethereum Merkle Patricia Trie 文件指出，Ethereum 具有一個全域狀態樹，且每當用戶端處理區塊時都會更新。

此全域狀態樹是 Ethereum 執行層最重要的組成之一，因為它代表交易套用後網路的即時狀態。

狀態樹並不等同於歷史交易清單。

交易描述發生過什麼事；狀態樹則描述這些交易變更餘額、合約儲存空間與帳戶資料後，區塊鏈目前的樣貌。

例如，使用者將 ETH 從一個帳戶轉至另一個帳戶時，交易會記錄在區塊中，但兩個帳戶餘額更新也會使狀態樹改變。

若使用者呼叫智能合約，交易同樣記錄於區塊中；但合約儲存空間、餘額與帳戶 nonce 可能更新，因此狀態樹也可能改變。

簡單來說，狀態樹是區塊鏈目前帳戶狀態的經驗證資料庫。

狀態樹為何重要

狀態樹很重要，因為區塊鏈需要安全方式來證明目前狀態。

區塊鏈狀態可包含數百萬個帳戶、智能合約、餘額、儲存項目及其他數值。

節點必須就該狀態達成共識，才能判斷新交易是否有效。

若發送者餘額不足，交易應失敗。

若合約儲存槽具有特定數值，智能合約呼叫的行為可能不同。

若 nonce 已被使用，重放交易不應被接受。

狀態樹為用戶端提供確定性的結構，以儲存及檢查這些數值。

它也會產生可置於區塊標頭中的單一狀態根。

若兩個用戶端處理相同區塊並得到相同狀態根，便有強力證據顯示兩者同意所得狀態。

因此，狀態樹是區塊鏈共識、驗證、輕量用戶端證明、節點同步、智能合約執行及資料完整性的核心。

狀態樹與狀態根

狀態根是區塊內所有交易處理後，狀態樹的根雜湊值。

Ethereum 區塊標頭包含 stateRoot，代表該區塊的完整全域狀態承諾。

Ethereum Merkle Patricia Trie 文件說明，Ethereum 執行層區塊標頭包含狀態樹、交易樹與收據樹的根。

狀態根很重要，因為它是對龐大資料庫所作的精簡加密承諾。

若有有效證明，使用者無須下載每個帳戶與合約儲存數值，即可驗證特定主張。

使用者可改為驗證某數值是否屬於狀態根承諾的狀態。

若任何帳戶餘額、合約儲存根、nonce 或程式碼雜湊值變更，通往根的雜湊路徑也會改變。

這表示不同狀態應產生不同狀態根。

因此，狀態根是特定區塊完整區塊鏈狀態的指紋。

它將龐大的狀態資料庫轉化為單一可驗證數值。

狀態樹如何運作

Ethereum 狀態樹使用經修改的 Merkle Patricia Trie。

Merkle Patricia Trie 結合 Merkle 樹、基數樹與 Patricia 樹的概念。

Trie 是類似樹狀的鍵值結構，樹中的路徑取決於鍵。

Patricia Trie 會壓縮路徑，避免樹在冗長的空節點鏈上浪費空間。

Merkle 樹加入加密雜湊值，使資料能透過雜湊路徑驗證。

Ethereum 結合這些特性，讓用戶端能儲存帳戶狀態、有效更新，並以根雜湊值及 Merkle 證明驗證。

在 Ethereum 的狀態樹中，路徑基於帳戶地址的 Keccak-256 雜湊值。

該路徑儲存的值為經 RLP 編碼的帳戶物件。

官方 Ethereum 文件指出，Ethereum 帳戶物件是包含 nonce、balance、storageRoot 與 codeHash 的四項陣列。

此設計使每個帳戶都能透過確定性的加密路徑被存取。

狀態樹儲存哪些資料？

狀態樹儲存帳戶物件，而不是直接在主要全域樹中儲存每一項合約儲存數值。

每個 Ethereum 帳戶物件都包含 nonce、餘額、storageRoot 及 codeHash。

nonce 有助於防止交易重放並追蹤帳戶活動。

餘額記錄帳戶持有的原生幣數量。

storageRoot 指向另一棵儲存該帳戶智能合約資料的樹。

codeHash 承諾與合約帳戶相關的智能合約位元組碼。

外部擁有帳戶通常具有空白程式碼與空白合約儲存空間。

智能合約帳戶則可具有影響其執行方式的程式碼與儲存空間。

狀態樹與儲存樹

狀態樹與儲存樹相關，但兩者不同。

狀態樹是將帳戶地址對應至帳戶物件的全域結構。

儲存樹則是特定智能合約帳戶所使用的獨立儲存樹。

Ethereum 文件指出，每個具有合約儲存空間的帳戶都有個別儲存樹。

狀態樹中的帳戶物件會儲存 storageRoot，即該帳戶儲存樹的根。

因此，全域狀態樹不會直接包含每份合約的所有儲存槽。

它包含帳戶物件，而每個合約帳戶可指向自己的儲存樹。

例如，代幣合約可在自身的合約儲存樹中記錄使用者餘額。

全域狀態樹儲存代幣合約帳戶物件，該物件則指向代幣合約的儲存根。

此分層設計有助於區分帳戶層級狀態與合約層級儲存空間。

狀態樹與交易樹

狀態樹不同於交易樹。

狀態樹儲存交易執行後產生的帳戶狀態；交易樹則儲存特定區塊包含的交易。

每個區塊都有自己的交易樹。

交易樹不會像全域狀態樹一樣持續跨區塊更新。

隨著交易改變帳戶餘額與合約儲存空間，狀態樹會逐區塊演變。

交易可理解為指令；狀態樹則可理解為套用指令後的結果。

這項區分很重要，因為區塊鏈不只是依序排列的交易紀錄。

它也是狀態機，每筆有效交易都會將系統從一個狀態移至下一個狀態。

狀態樹與收據樹

狀態樹也不同於收據樹。

收據樹儲存區塊的交易收據。

收據記錄狀態、已使用 Gas、日誌與事件資料等執行結果。

狀態樹則記錄執行後最終帳戶狀態。

收據協助應用程式了解交易執行時發生的事情；狀態樹協助用戶端驗證執行後區塊鏈成為何種狀態。

例如，智能合約交易可發出記錄在收據中的事件，也可能透過狀態樹與儲存樹變更合約儲存空間。

兩種結構都重要，但回答的問題不同：收據樹回答交易產生什麼結果，狀態樹回答鏈目前的狀態。

Merkle Patricia Trie 節點

Ethereum 經修改的 Merkle Patricia Trie 使用多種節點類型。

官方 Ethereum 文件描述分支節點、葉節點、擴展節點與空節點。

分支節點最多可指向 16 條子路徑，也可能保存一個值。

葉節點儲存最終編碼路徑和值。

擴展節點會壓縮共用路徑片段，讓 Trie 避免形成冗長的稀疏節點鏈。

此設計很有用，因為 Ethereum 鍵很長且稀疏。

若沒有路徑壓縮，許多查詢會浪費步驟於空白或無分支路徑。

透過擴展節點與葉節點，Ethereum 使 Trie 比基本基數樹更精簡；透過雜湊值，則使 Trie 可受加密驗證。

這種組合正是其稱為經修改 Merkle Patricia Trie 的原因。

RLP 編碼與雜湊

Ethereum 使用遞迴長度前綴編碼（Recursive Length Prefix，通常稱為 RLP）序列化執行層的許多資料結構。

在狀態樹中，帳戶物件會先經 RLP 編碼，再作為值放入樹中；Trie 節點也會在雜湊或儲存前進行編碼。

Ethereum Merkle Patricia Trie 文件說明，當節點引用另一節點時，引用可能是 RLP 編碼節點的 Keccak-256 雜湊值，取決於編碼長度。

這很重要，因為每個節點都必須以確定方式編碼。

若兩個用戶端以不同方式編碼相同狀態，可能計算出不同根並無法達成共識。

因此，確定性編碼是共識關鍵細節。

雜湊也讓竄改可被察覺，因為變更數值會改變節點雜湊值及回到根的雜湊路徑。

結果是可驗證的鍵值資料庫，其中一個根雜湊值承諾所有包含的數值，也是狀態證明的加密基礎。

狀態證明

狀態證明是加密證明，用於證明特定帳戶或儲存數值存在於某個狀態根承諾的狀態中。

EIP-1186 eth_getProof 提案說明，Ethereum 以 Merkle 樹為基礎的狀態可透過 Merkle 證明驗證帳戶及儲存數值。

證明通常包含從目標數值重建至狀態根路徑所需的節點。

若重建的雜湊值符合受信任的狀態根，無須完全信任資料提供者即可驗證該數值。

這對輕量用戶端、跨鏈橋、跨鏈應用程式、行動錢包、稽核人員，以及需要驗證外部狀態的智能合約系統很有用。

例如，證明可顯示某帳戶在某區塊時具有特定餘額，或某合約儲存槽在特定區塊具有特定數值。

狀態證明允許選擇性驗證，而不是下載完整狀態資料庫，因此非常強大。

狀態樹使這些證明成為可能。若沒有經驗證的狀態結構，使用者將必須更信任 RPC 提供者與索引服務。

eth_getProof

eth_getProof 是 Ethereum JSON-RPC 方法，旨在回傳帳戶與儲存數值及其 Merkle 證明。

EIP-1186 將 eth_getProof 定義為回傳指定帳戶的帳戶數值、儲存數值與證明資料的方法。

證明可包含遵循狀態根路徑的 accountProof 資料，以及遵循合約儲存根路徑的 storageProof 資料。

當應用程式需要證據，而非僅需原始 RPC 回應時，此方法相當有用。

例如，錢包或跨鏈橋可能希望依據區塊狀態根驗證儲存槽。

一般餘額查詢僅回報數值；證明查詢則回報數值及檢查所需的加密資料。

這項區別很重要，因為 RPC 提供者可能錯誤、遭審查、出現漏洞或具有惡意。

Merkle 證明讓使用者可透過受信任區塊標頭檢查證明，降低對提供者的信任需求。

狀態樹與完整節點

完整節點需要目前狀態來驗證新區塊與交易。

官方 Ethereum 封存節點文件指出，每個帳戶與合約的全域資料儲存在名為 state 的 Trie 資料庫。

完整節點追蹤網路最新狀態，以驗證傳入區塊及交易。

完整節點通常不會永久保留每個歷史狀態，而是保留最新狀態及足以處理鏈重組與一般網路運作的近期狀態資料。

較舊的歷史狀態通常可被修剪，因為標準驗證最新鏈端並不需要它們。

這也是為什麼一般完整節點可能難以查詢舊餘額或舊合約儲存資料。

目前狀態是網路運作所必需；所有歷史中間狀態雖對分析及證明有用，卻需要更多儲存空間。

因此，狀態樹會影響節點硬體、同步、儲存與去中心化。

狀態樹與封存節點

封存節點會儲存歷史狀態，而非僅保留目前及近期狀態。

Ethereum 封存節點文件說明，封存節點會儲存每個區塊後建立的所有歷史狀態，以更大的磁碟需求換取快速歷史查詢。

這對區塊鏈瀏覽器、稽核人員、研究者、安全團隊、稅務工具、分析服務商與 dApp 開發者很重要。

例如，使用者可能想知道某帳戶數年前某個區塊時的餘額。

完整節點可能需要重新執行歷史交易來重建該狀態；封存節點通常可直接從磁碟存取歷史狀態。

這種速度的代價是更大的儲存需求。

狀態樹歷史很有價值但成本高，因此許多使用者依賴基礎設施提供者查詢歷史狀態；不過，依賴提供者可能增加信任、可用性及審查風險。

狀態樹與智能合約

智能合約高度依賴狀態樹與儲存樹。

合約帳戶物件位於全域狀態樹中；合約程式碼透過 codeHash 承諾，持久儲存空間則透過 storageRoot 承諾。

智能合約執行時可能讀取及寫入儲存槽，這些變更會更新合約儲存樹。

合約的新 storageRoot 會更新全域狀態樹中的帳戶物件，更新後的帳戶物件又會改變全域狀態根。

因此，即使只是小型合約儲存更新，也可能改變區塊最終狀態根。

狀態樹是智能合約結果如何成為共識可見資料的一部分。

狀態樹與代幣餘額

許多代幣餘額儲存在智能合約儲存空間內，而不是直接存在全域狀態樹。

例如，同質化代幣合約可儲存從使用者地址至代幣餘額的映射，此映射位於代幣合約的儲存樹中。

全域狀態樹則儲存代幣合約帳戶物件，包括該合約的 storageRoot。

這表示原生幣餘額與代幣餘額的儲存方式不同。

原生幣餘額是全域狀態樹帳戶物件的一部分；代幣餘額通常是特定代幣合約儲存樹內的儲存值。

這項差異對證明與稽核很重要。

要證明原生幣餘額，帳戶證明通常已足夠；要證明代幣餘額，可能同時需要代幣合約的帳戶證明及相關餘額槽的儲存證明。

狀態樹與輕量用戶端

輕量用戶端可驗證區塊鏈資料，卻不儲存完整狀態。

狀態樹可透過與區塊標頭相連的精簡證明協助輕量用戶端。

輕量用戶端可信任或驗證區塊標頭，再使用 Merkle 證明檢查特定狀態數值，成本遠低於本機儲存完整狀態。

例如，行動錢包可能希望在不執行完整執行節點的情況下，驗證某個合約儲存數值。

跨鏈橋則可能希望驗證另一條鏈狀態中是否包含提領事件或帳戶狀態。

狀態樹提供此類工作流程所需的經驗證結構。

不過，證明大小與產生證明的成本仍可能相當高。

這是 Ethereum 研究人員探索 Verkle 樹等替代方案的原因之一，目標是隨時間讓狀態驗證更輕量且更具擴展性。

狀態樹與無狀態用戶端

無狀態用戶端是長期區塊鏈擴容構想，讓驗證者或使用者無須在本機儲存完整狀態即可驗證區塊。

與其讓每個驗證者儲存所有狀態，區塊或交易會包含可證明其觸及狀態的見證資料。

狀態樹與此相關，因為目前 Merkle Patricia Trie 的見證資料可能很大。

大型見證資料可能使無狀態驗證效率不佳。

Ethereum Foundation 的 Verkle tree structure 文章說明，Verkle 樹與 Merkle 樹類似，但可透過向量承諾產生更小的見證資料。

因此，Verkle 樹被研究作為 Ethereum 目前狀態承諾結構的可能替代方案。

目前狀態樹安全且久經驗證，但並非為最小的無狀態見證資料而設計。

無狀態研究部分目標在於降低狀態樹為節點帶來的負擔。

對使用者而言，實際重點是狀態資料結構設計會影響未來擴展性；對開發者而言，隨協議研究進展，狀態存取模式與證明系統可能演變。

狀態樹與 Verkle 樹

Verkle 樹是提議中的狀態承諾結構，使用向量承諾而非僅使用雜湊連結。

Ethereum.org 表示，Ethereum 計畫未來遷移至 Verkle Tree 結構，但協議時程與實作細節可能改變。

Verkle 樹旨在使證明比 Merkle Patricia Trie 證明更小。

Ethereum Foundation 文章指出，Verkle 樹設計也會以不同布局合併帳戶與儲存樹。

這將是重大改變，因為目前 Ethereum 使用全域狀態樹加上每帳戶儲存樹。

基於 Verkle 的狀態模型可能使無狀態用戶端更實用。

不過，從長期運作的狀態樹遷移至新的承諾結構十分複雜，會影響用戶端、證明、錢包、節點、執行規則、儲存布局及開發者假設。

因此，狀態樹既是目前基礎，也是持續進行協議研究的重要領域。了解狀態樹有助於理解 Verkle 研究的重要性。

狀態樹與狀態膨脹

狀態膨脹是指區塊鏈的活躍狀態變得更大、更難維護。

更多帳戶、合約、儲存槽與應用程式資料持續保持活躍時，狀態樹便會成長。

大型狀態會增加磁碟使用量、同步時間、資料庫工作負載與硬體需求。

若節點執行成本過高，能獨立驗證網路的使用者將減少，進而削弱去中心化。

狀態膨脹不同於區塊鏈歷史成長，因為活躍狀態是處理新交易所需的資料。

歷史交易很重要，但舊中間狀態有時可被修剪或重新產生；目前狀態則必須可供驗證。

這使狀態成長成為智能合約區塊鏈最棘手的擴容問題之一，而狀態樹正是用戶端可見此成長的資料結構。

狀態樹與 Gas 成本

Gas 成本的部分設計目的，是為運算與狀態存取定價。

寫入持久儲存空間成本高，因為會增加或變更節點必須維護的狀態。

讀取狀態也可能產生成本，因為狀態存取影響執行效能。

智能合約建立新儲存資料時，儲存樹與全域狀態根可能需要更新。

智能合約刪除儲存資料時，依現行協議規則，Gas 規則可能提供退款或獎勵。

這些 Gas 機制與狀態樹有關，因為持久狀態是全網共享資源。

若儲存寫入過於便宜，應用程式可能以低價值資料使狀態樹膨脹；若過於昂貴，有用的應用程式可能更難建置。

協議設計者必須平衡可用性、安全性與狀態永續性，狀態樹正位於此經濟權衡的中心。

狀態樹與 RPC 提供者

RPC 提供者提供讓錢包與應用程式讀取區塊鏈狀態的方法。

常見狀態方法包括餘額、儲存、程式碼、交易計數查詢與合約呼叫。

官方 Ethereum JSON-RPC 文件將狀態方法描述為回報帳戶餘額、合約資料及 Gas 估算等目前儲存資料的方法。

錢包查詢帳戶餘額時，RPC 提供者會從節點讀取狀態資料；dApp 查詢合約數值時，提供者可能讀取儲存槽，或根據目前狀態模擬呼叫。

使用者經常依賴 RPC 提供者，卻未察覺回應背後的狀態樹。

不過，狀態樹使這些數值可成為可驗證區塊鏈狀態的一部分。

對高信任需求的應用程式而言，原始 RPC 回應可能不足；在支援且妥善驗證時，狀態證明可提供更高保障，這對跨鏈橋、稽核、合規工具與跨鏈系統很重要。

狀態樹與區塊鏈瀏覽器

區塊鏈瀏覽器使用狀態資料來顯示餘額、代幣持有量、合約儲存空間、交易影響及歷史帳戶資訊。

瀏覽器通常依賴已索引資料，而非僅直接查詢狀態樹。索引可加快搜尋並簡化使用者介面建置。

不過，索引資料最終仍來自區塊鏈狀態、交易、日誌、收據及執行結果。

若瀏覽器顯示某帳戶在特定區塊的餘額，該資訊便與該區塊的狀態相關。

若瀏覽器顯示代幣餘額，通常是從合約儲存變更及事件導出。

封存節點可協助瀏覽器快速回答歷史狀態問題；若無歷史狀態存取能力，瀏覽器可能需由交易歷史重建較舊狀態。

一般瀏覽器使用者通常看不到狀態樹，但它仍是讓瀏覽器資料可在協議層級驗證的核心結構。

狀態樹與跨鏈橋

跨鏈橋通常需要驗證另一個區塊鏈環境的狀態或事件，狀態樹與 Merkle 證明可支援此驗證。

例如，跨鏈橋可能需要證明訊息、儲存數值或帳戶狀態在特定區塊存在。

若跨鏈橋可信任區塊標頭並驗證證明，便可降低對集中式資料提供者的依賴。

這也是 EIP-1186 指出 Merkle 證明對 Layer 2 技術很重要的原因。

狀態證明可協助系統驗證餘額、儲存槽及合約狀態相關主張。

但跨鏈橋安全性不只取決於證明結構，也取決於標頭驗證、最終性假設、詐欺證明、有效性證明、多簽控制、智能合約安全性及營運設計。

正確的狀態樹證明很強大，但只是跨鏈橋安全性的其中一部分。使用者不應僅因跨鏈橋提及 Merkle 證明便假定其安全。

狀態樹與 Layer 2 網路

Layer 2 網路通常使用狀態根、證明與承諾結構，摘要鏈下或獨立鏈執行。

Layer 2 可將狀態根發布至 Layer 1 鏈，並使用詐欺證明、有效性證明或資料可用性機制，證明狀態轉換有效。

實際設計取決於 Layer 2 架構。

Ethereum 狀態樹提供重要背景，說明區塊鏈如何透過精簡根值承諾大型狀態。

Layer 2 系統可能使用不同資料結構，但概念相似：大型執行狀態由承諾值摘要，使用者與合約再針對該承諾驗證主張。

因此，狀態樹不只是低階用戶端議題，也與擴容、Rollup 設計及跨鏈驗證有關。

狀態樹與安全性

狀態樹讓狀態竄改可被偵測，從而提升安全性。

若節點未依有效交易規則變更帳戶餘額，所得狀態根將不符合已接受的區塊標頭。

若提供者謊報儲存數值，有效 Merkle 證明應無法通過受信任狀態根的驗證。

若兩個用戶端對狀態轉換規則存在分歧，可能計算不同狀態根並拒絕彼此的區塊。

這使狀態樹成為共識關鍵組成。

狀態樹實作漏洞可能很嚴重，因為可能導致用戶端分歧或錯誤狀態驗證。

因此，執行用戶端必須謹慎實作 Trie 邏輯、編碼、雜湊與狀態更新。

狀態樹安全性也依賴加密雜湊抗性。

若攻擊者可建立具有相同根的兩種不同狀態，便可能破壞證明完整性。

現代區塊鏈狀態樹依賴加密假設，在目前條件下，使此類攻擊在實務上不可行。

狀態樹與用戶端實作

不同 Ethereum 執行用戶端實作相同狀態規則，但可使用不同內部資料庫及最佳化方式。

共識關鍵結果必須是相同狀態根。

用戶端在磁碟上儲存 Trie 節點、快取狀態、修剪舊狀態及提供歷史查詢的方式都可能不同。

因此，狀態樹既是協議概念，也是實作挑戰。

在協議層，用戶端必須就根與轉換規則達成共識；在資料庫層，用戶端團隊可最佳化儲存布局、存取速度、修剪、快照與同步行為。

使用者通常會透過節點效能、磁碟使用量、同步時間及 RPC 可靠性體驗到這些差異。

狀態樹與開發者偵錯

開發者經常透過儲存槽、帳戶證明與歷史狀態查詢間接接觸狀態樹。

智能合約開發者可能需要了解映射如何儲存在合約儲存空間；安全研究者可能需證明儲存槽於某區塊具有特定值。

跨鏈橋開發者可能需驗證另一個環境的合約狀態值；錢包開發者可能需解釋餘額查詢為何取決於 latest 或 finalized 等區塊標籤。

dApp 開發者在偵錯舊合約狀態時可能需要封存節點。

了解狀態樹有助於開發者正確理解這些問題，並避免混淆交易歷史與目前狀態。

許多漏洞源於假定事件、儲存空間、餘額與帳戶狀態是同一件事；狀態樹可釐清每項資料所在位置。

狀態樹與一般使用者體驗

多數加密貨幣使用者不會直接與狀態樹互動，而是使用錢包、dApp、區塊鏈瀏覽器及 RPC 提供者。

錢包顯示餘額時是在讀取狀態；dApp 檢查使用者是否核准代幣時是在讀取合約儲存狀態。

智能合約呼叫成功或失敗取決於目前狀態；瀏覽器顯示某區塊的合約數值則取決於狀態存取或由狀態導出的索引資料。

狀態樹是隱藏基礎設施，但每天都會影響一般使用者活動。

若狀態存取緩慢，dApp 可能顯得緩慢；若 RPC 提供者提供錯誤狀態，使用者可能看到錯誤餘額或交易失敗。

若歷史狀態無法取得，使用者可能難以稽核舊活動。

關於狀態樹的常見誤解

一項常見誤解是狀態樹儲存每筆交易。狀態樹儲存目前帳戶狀態，交易則獨立儲存在區塊及交易樹中。

另一項誤解是智能合約儲存空間直接存於全域狀態樹。全域狀態樹儲存帳戶物件，合約儲存空間則存於 storageRoot 引用的獨立儲存樹。

第三項誤解是完整節點一律儲存所有歷史狀態。許多完整節點會保留目前及近期狀態，同時修剪較舊中間狀態。

第四項誤解是狀態根就是狀態本身。狀態根是對狀態的精簡加密承諾，不是完整狀態資料庫。

第五項誤解是 Merkle 證明可證明合約的一切事實。Merkle 證明是針對特定根證明特定帳戶或儲存數值，而非證明該數值完整的商業意義。

狀態樹的優點

狀態樹的第一項優點是可驗證性。使用者與用戶端可透過連結狀態根的證明驗證狀態數值。

第二項優點是確定性。處理同一有效區塊的用戶端應得到相同狀態根。

第三項優點是有效查詢。Trie 路徑讓用戶端可透過確定性鍵尋找帳戶與儲存資料。

第四項優點是竄改可見性。變更一個數值便會改變雜湊路徑與最終根。

第五項優點是支援輕量用戶端。選擇性證明可在不下載完整狀態下驗證資料。

第六項優點是清楚的狀態轉換結構。每個區塊會將先前狀態變更為具有新根的新狀態。

這些優點使狀態樹成為以帳戶為基礎的智能合約區塊鏈之基礎。

狀態樹的限制

第一項限制是儲存成長。隨著更多帳戶與合約儲存數值累積，節點維護狀態的負擔加重。

第二項限制是證明大小。對無狀態用戶端與大規模驗證而言，Merkle Patricia Trie 證明可能比所期望的更大。

第三項限制是實作複雜度。Trie 編碼、雜湊、修剪、快取及資料庫儲存都難以正確實作。

第四項限制是歷史狀態成本。保存所有歷史狀態所需磁碟空間遠大於一般完整節點運作需求。

第五項限制是開發者混淆。許多開發者不理解狀態、儲存空間、交易、收據、日誌與索引資料的差異。

這些限制說明為何狀態管理仍是活躍的研究與工程領域。狀態樹能運作，但也帶來實際的擴容及可用性挑戰。

開發者最佳實務

建置基於證明的系統前，應了解帳戶狀態與合約儲存空間的差異。

學習 Merkle Patricia Trie 機制時，請使用官方 Ethereum 文件。

建置需要帳戶或儲存證明的系統時，請謹慎使用 eth_getProof。

應針對受信任區塊標頭驗證證明，而不是盲目信任 RPC 回應。

請記得代幣餘額通常位於合約儲存空間，而不是直接位於全域狀態樹。

需要快速存取舊歷史狀態時，請使用封存節點或封存資料提供者。

設計智能合約時應盡量減少不必要的持久儲存空間。

寫入儲存空間時應考量 Gas 成本，因為持久狀態成本高。

若系統高度依賴狀態證明，請追蹤 Verkle 樹等協議研究。

請勿假定目前的證明格式在未來協議升級後將永遠不變。

使用者最佳實務

請使用可信任的錢包與區塊鏈瀏覽器，但請記得其顯示內容來自狀態查詢與索引資料。

比較不同工具中的餘額或合約數值時，請檢查區塊高度。

應了解目前餘額與歷史餘額可能需要不同資料存取方式。

若需要高度保證且工具支援，可使用基於證明的驗證。

不要假定一般 RPC 回應等同於加密證明。

使用聲稱驗證另一條鏈狀態的跨鏈橋或應用程式時請謹慎。

請確認應用程式使用的是目前狀態、歷史狀態、日誌或鏈下索引。

請了解即使代幣轉帳不明顯，智能合約儲存變更仍可能影響應用程式行為。

請記住，區塊鏈透明度依賴狀態樹等資料結構。狀態樹雖對多數使用者不可見，卻有助於使公鏈資料可被驗證。

FAQ

狀態樹是什麼意思？

狀態樹是一種加密鍵值樹，用於儲存目前區塊鏈狀態，並產生承諾該狀態的根雜湊值。

Ethereum 狀態樹是什麼？

Ethereum 狀態樹是全域的經修改 Merkle Patricia Trie，將雜湊後的帳戶地址對應至 RLP 編碼帳戶物件。

Ethereum 帳戶物件儲存什麼？

Ethereum 帳戶物件包含 nonce、balance、storageRoot 與 codeHash。

什麼是狀態根？

狀態根是區塊交易執行後狀態樹的根雜湊值。

狀態樹是否等同於儲存樹？

不是。狀態樹儲存帳戶物件，儲存樹則儲存個別合約帳戶的合約儲存資料。

狀態樹是否等同於交易歷史？

不是。狀態樹儲存目前帳戶狀態，交易歷史則記錄區塊內依序包含的交易。

什麼是 Merkle 證明？

Merkle 證明是一組 Trie 節點，可證明特定數值包含於根雜湊值承諾的狀態中。

什麼是 eth_getProof？

eth_getProof 是 Ethereum JSON-RPC 方法，會回傳帳戶及儲存數值，以及 Merkle 證明資料。

封存節點為何對狀態樹重要？

封存節點會儲存歷史狀態，因此可比一般完整節點更快回覆舊狀態查詢。

Ethereum 是否永遠使用目前狀態樹？

Ethereum 目前在執行層使用 Merkle Patricia Trie，但 Ethereum 研究已探索 Verkle 樹作為未來狀態承諾結構。

結論

狀態樹是以帳戶為基礎的智能合約區塊鏈背後的核心資料結構之一。

它儲存帳戶目前狀態，並讓用戶端以單一加密根摘要該狀態。

在 Ethereum 中，全域狀態樹將雜湊帳戶地址對應至包含 nonce、balance、storageRoot 與 codeHash 的帳戶物件。

每個合約可擁有自己的儲存樹，其根儲存在合約帳戶物件中。

每個區塊標頭內的狀態根承諾該區塊所有交易處理後的完整結果狀態。

這使狀態樹成為共識、驗證、輕量用戶端、證明、節點同步、智能合約執行與區塊鏈資料完整性的必要組成。

狀態樹也帶來挑戰，因為活躍狀態成長會增加節點儲存、證明大小、同步複雜度與歷史資料成本。

這些挑戰說明封存節點、狀態修剪、Gas 成本、儲存設計、eth_getProof 與 Verkle 樹研究為何彼此相關。

對使用者而言，狀態樹大多隱藏於錢包、區塊鏈瀏覽器與 dApp 背後；對開發者及基礎設施團隊而言，它是了解餘額、合約儲存空間、證明、歷史查詢及擴容限制的關鍵概念。

在加密貨幣詞彙脈絡中，State Trie 指的是記錄目前帳戶狀態，並產生用於驗證該狀態之狀態根的經驗證區塊鏈狀態資料庫。

重點在於，狀態樹將龐大且持續變化的區塊鏈狀態，轉化為節點、應用程式與使用者可透過加密根與證明信任的可驗證結構。