狀態承諾

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

狀態承諾是一種加密學摘要，用於承諾區塊鏈在特定時間點的目前狀態。

簡單來說，它是一大組區塊鏈資料的精簡指紋。

依區塊鏈設計而定，這些較龐大的資料可包括帳戶餘額、智能合約儲存空間、Nonce、驗證者紀錄、代幣餘額、物件所有權、UTXO 或其他狀態值。

狀態承諾讓節點、錢包、跨鏈橋、輕客戶端、Rollup 和應用程式無須下載完整資料庫，也無須盲目信任資料庫，即可驗證與區塊鏈狀態相關的主張。

在 Ethereum 上，最常見的狀態承諾是儲存在區塊標頭中的狀態根。

官方Ethereum Merkle Patricia Trie 文件說明，Ethereum 使用全域狀態 Trie，客戶端處理區塊時會更新此 Trie，而產生的狀態根可透過加密學方式驗證。

若兩個節點處理相同的有效區塊並得到相同的狀態承諾，便有力地證明它們對最終狀態達成一致。

若某個帳戶餘額或合約儲存值發生變化，狀態承諾也應隨之改變。

這正是狀態承諾對區塊鏈共識、狀態證明、詐欺證明、有效性證明、輕客戶端驗證及跨鏈訊息至關重要的原因。

在加密貨幣詞彙表的語境中，State Commitment 指以精簡且可驗證形式表示區塊鏈目前狀態的加密學根或承諾。

為什麼狀態承諾很重要

狀態承諾之所以重要，是因為區塊鏈是由許多獨立參與者維護的共享資料庫。

任何使用者都不應必須信任單一伺服器所回報的餘額、合約值或帳戶狀態正確無誤。

狀態承諾讓網路能就一個代表龐大狀態的單一精簡數值達成共識。

這使得狀態可透過證明檢查，而非仰賴盲目信任。

例如，輕客戶端可能不會儲存完整 Ethereum 狀態，但可依據可信任的狀態根驗證狀態證明。

跨鏈橋可能需要證明某則訊息或提領紀錄存在於另一條鏈的狀態中。

Rollup 可發布狀態根，以彙總大量鏈下或 Layer 2 交易的結果。

錢包可能仰賴節點提供餘額資料；而更嚴謹的系統則可透過證明驗證節點是否提供不實資訊。

狀態承諾也讓區塊鏈執行結果可供稽核。

每個區塊都包含其最終狀態的承諾，因此使用者可驗證鏈是否依協議規則從一個有效狀態轉移至下一個有效狀態。

狀態承諾與區塊鏈狀態

區塊鏈狀態是處理新交易所需的完整即時資料集合。

狀態承諾僅是該狀態的精簡加密學表示。

此差異很重要，因為狀態承諾並不直接包含每筆餘額或每個儲存槽位。

它只透過加密學資料結構承諾這些值。

例如，Ethereum 的狀態根不會在區塊標頭中列出所有帳戶餘額。

相反地，它承諾儲存帳戶物件並指向合約儲存 Trie 的全域狀態 Trie。

若有人想證明特定數值，便需提供將該數值連結至承諾的證明路徑。

驗證者會根據已知承諾檢查該證明。

若證明有效，驗證者便可相信該數值屬於已承諾的狀態。

因此，狀態承諾就像覆蓋於即時區塊鏈資料庫上的防竄改封條。

狀態承諾與狀態根

狀態根是常見的一種狀態承諾。

在 Ethereum 中，狀態根是區塊執行後全域狀態 Trie 的根雜湊值。

官方Ethereum 區塊文件將區塊描述為包含執行承載資料資訊，其中包括承諾重要執行層資料的根。

狀態根是一個特定欄位，而狀態承諾則是更廣泛的概念。

其他區塊鏈系統可能使用 app hash、state hash、world state root、global root、ledger commitment、accumulator root 或 commitment root 等不同名稱。

確切名稱取決於協議。

但核心概念相同。

龐大的狀態會由一個小型數值摘要；若底層狀態改變，該數值也會改變。

對於 Ethereum 類型的鏈而言，狀態根是使用者與開發者最常見的實務用語。

在區塊鏈理論中，狀態承諾則是更通用的概念。

狀態承諾如何運作

狀態承諾通常從一個結構化的狀態值資料庫開始。

區塊鏈會將這些值整理至 Merkle tree、Merkle Patricia Trie、稀疏 Merkle tree、向量承諾樹或其他已驗證資料結構等加密學資料結構中。

每個值都會以確定性方式進行雜湊或承諾。

這些雜湊值會向上組合，直到產生單一頂層根。

此頂層根即為狀態承諾。

若一個葉節點值改變，其路徑上的雜湊值也會改變。

這項變化會一路向上傳遞，直到根值改變。

因此可偵測竄改，因為除非攻擊者能破解底層密碼學，否則偽造值不應與原始承諾相符。

狀態承諾十分實用，因為它讓龐大資料庫可透過一個小型根值與證明進行驗證。

證明不需要包含整個資料庫，只需包含檢查某項主張所需的路徑與支援資料。

Ethereum 中的狀態承諾

Ethereum 使用修改版 Merkle Patricia Trie 承諾其執行層狀態。

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

Ethereum 帳戶物件包括 nonce、balance、storageRoot 和 codeHash。

全域狀態 Trie 會將帳戶地址對應至這些帳戶物件。

每個智能合約帳戶也可擁有自己的儲存 Trie，其根值會儲存在帳戶物件中。

這表示 Ethereum 的狀態承諾具有分層結構。

全域狀態根承諾帳戶資料。

每個合約帳戶的 storageRoot 則承諾該合約的持久化儲存資料。

若代幣合約更新合約儲存空間中的使用者餘額，該合約的儲存根會改變，全域狀態根也可能改變。

這就是智能合約執行如何成為已承諾區塊鏈狀態一部分的方式。

狀態承諾與 Merkle Patricia Trie

Merkle Patricia Trie 是 Ethereum 目前執行層使用的一種已驗證鍵值資料結構。

它結合 Trie 類型的金鑰路徑、Patricia 路徑壓縮及 Merkle 雜湊。

Trie 部分讓系統可依據金鑰，透過確定性路徑找到數值。

Patricia 部分會壓縮較長路徑，以減少冗餘結構。

Merkle 部分讓結構可透過加密學方式驗證。

官方 Ethereum 文件指出，Merkle Patricia Trie 具有確定性且可透過加密學驗證，意即可透過比對根值與證明路徑來證明相同的狀態。

這正是狀態承諾所需的特性。

它需要確定性的建構方式，讓誠實節點能計算出相同根值。

它需要加密學完整性，讓遭修改的資料改變承諾。

它需要證明支援，使特定數值無須下載所有資料即可驗證。

狀態承諾與 Merkle 證明

Merkle 證明可作為特定數值屬於某個根所承諾狀態的證據。

EIP-1186 eth_getProof 規格說明一種 JSON-RPC 方法，可連同 Merkle 證明資料回傳帳戶與儲存數值。

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

若重建的根值與可信任狀態承諾相符，該數值即獲驗證。

這讓驗證者可確認帳戶在特定區塊時具有某個餘額，或合約儲存槽位具有某個數值。

Merkle 證明相當重要，因為它們可降低對 RPC 供應商、索引器及第三方 API 的信任需求。

一般 RPC 回應僅說明伺服器宣稱的狀態。

有證明支持的回應則可顯示該主張為何與狀態承諾相符。

這項差異對錢包、跨鏈橋、稽核、跨鏈系統及高價值應用程式十分重要。

狀態承諾讓這些證明具有意義，因為證明需要可信任的根值作為驗證基準。

狀態承諾與區塊標頭

區塊標頭是許多區塊鏈儲存大型區塊資料精簡承諾的位置。

Ethereum 區塊標頭包括與狀態、交易及收據相關的根值。

狀態根承諾最終的世界狀態。

交易根承諾區塊中的交易清單。

收據根承諾交易收據與日誌。

這些承諾具有不同用途。

狀態承諾回答區塊鏈在執行後成為何種狀態。

交易承諾回答包含了哪些交易。

收據承諾回答產生了哪些執行輸出與日誌。

這些根值共同讓客戶端不必將所有完整資料直接放入標頭，即可驗證區塊資料的重要部分。

狀態承諾與交易承諾

狀態承諾與交易承諾並不相同。

交易承諾承諾區塊中包含的交易。

狀態承諾則承諾這些交易執行後產生的最終狀態。

例如，一個區塊可包含將資產從某帳戶轉移至另一帳戶的交易。

交易承諾可證明該交易已被包含。

若提供相關狀態證明，狀態承諾可證明由此產生的餘額變化。

此區別對建構跨鏈橋或證明的開發者至關重要。

證明交易被包含，並不一定等同於證明最終狀態。

交易可能已被包含，但執行失敗。

狀態證明可顯示執行後鏈上實際形成的狀態。

狀態承諾與收據承諾

收據承諾也不同於狀態承諾。

收據可顯示執行狀態、已使用的 Gas、日誌與事件。

狀態承諾則顯示執行後的最終狀態資料庫。

事件可用於索引與應用程式邏輯，但事件並不等同於合約儲存資料。

合約可在不改變狀態的情況下發出事件。

合約也可能改變狀態，卻不發出有用事件。

因此，部分高安全性系統偏好儲存證明，而不是只依賴事件的假設。

收據很有價值，但它回答的問題不同於狀態承諾。

收據承諾有助於證明交易回報了什麼。

狀態承諾有助於證明區塊鏈狀態實際包含什麼。

Rollup 中的狀態承諾

Rollup 高度依賴狀態承諾。

Rollup 會在基礎鏈之外或獨立執行環境中處理交易，接著將承諾、資料或證明發布回結算層。

Rollup 狀態根彙總目前的 Layer 2 狀態。

使用者可使用該承諾追蹤 Rollup 內的餘額、提領、訊息與應用程式狀態。

官方Ethereum zk-rollup 文件說明，零知識 Rollup 會發布有效性證明，以證明狀態轉移正確。

在 Optimistic Rollup 中，若有人認為轉移無效，可在爭議期間挑戰狀態承諾。

在有效性 Rollup 中，系統使用證明來顯示已承諾的新狀態符合規則。

在兩種情況下，狀態承諾都是對 Rollup 狀態的精簡主張。

若沒有狀態承諾，Rollup 將無法有效彙總及結算大量 Layer 2 執行作業。

這讓狀態承諾成為現代區塊鏈擴充的核心要素。

狀態承諾與詐欺證明

詐欺證明是用於顯示某項宣稱的狀態轉移無效的挑戰。

詐欺證明系統通常與 Optimistic Rollup 設計一併討論。

Rollup 營運者執行交易後，可能發布新的狀態承諾。

若承諾有誤，其他參與者可透過證明舊狀態至新狀態的轉移無效來挑戰它。

爭議程序需要清楚承諾舊狀態、交易資料及宣稱的新狀態。

因此，狀態承諾是詐欺證明證據結構的一部分。

詐欺證明不只是指出某件事有錯。

它必須將主張連結至已承諾資料與執行規則。

這也是資料可用性對詐欺證明同樣重要的原因。

若重新計算轉移所需資料無法取得，挑戰者可能無法證明詐欺。

狀態承諾與有效性證明

有效性證明是證明某項狀態轉移已正確執行的加密學證據。

有效性證明常用於零知識 Rollup 與其他以證明為基礎的系統。

證明者從舊狀態承諾開始，依規則套用交易，並證明新狀態承諾正確。

若證明系統健全，且滿足必要資料假設，驗證者不需要完整重新執行每筆交易。

這可使驗證成本遠低於執行成本。

狀態承諾居於核心，因為證明需要明確的起始與結束承諾。

該證明實質上表示，系統已從一個已承諾狀態有效地轉移至另一個已承諾狀態。

這使狀態承諾成為可擴充驗證的錨點。

有效性證明可支援 Rollup、跨鏈橋、私密應用程式及壓縮執行系統。

承諾界定正在證明哪個狀態。

狀態承諾與輕客戶端

輕客戶端使用承諾與證明驗證區塊鏈資訊，無須儲存完整狀態。

輕客戶端可能追蹤區塊標頭，並依據其中的根值驗證證明。

若要驗證狀態值，輕客戶端需要可信任的狀態承諾與有效狀態證明。

這讓行動錢包、嵌入式裝置與低資源系統能以較少儲存空間及頻寬驗證特定事實。

因此，狀態承諾是最小化信任錢包設計的重要部分。

沒有它們，輕客戶端便必須更大程度信任遠端伺服器。

遠端伺服器可回報餘額，但證明讓客戶端能依據已承諾狀態檢查該餘額。

輕客戶端驗證不一定簡單，因為客戶端還需要可信任的標頭與最終性假設。

不過，狀態承諾原則上讓輕量化驗證成為可能。

這是已驗證狀態最重要的面向使用者優勢之一。

狀態承諾與跨鏈橋

跨鏈橋經常需要驗證來自另一條區塊鏈或 Layer 2 網路的狀態。

跨鏈橋可能需要證明已入金、提領已完成最終確認，或某則訊息存在於已承諾狀態中。

狀態承諾有助於跨鏈橋更安全地驗證這些主張。

例如，跨鏈橋合約可依據另一系統的已知狀態根驗證證明。

若證明有效，跨鏈橋便可釋放資金或傳遞訊息。

然而，即使使用狀態承諾，跨鏈橋仍具有風險。

跨鏈橋還必須驗證來源鏈的共識、最終性、資料可用性、證明格式與訊息規則。

正確的狀態證明僅是跨鏈橋安全性的一部分。

設計不良的跨鏈橋仍可能因驗證者薄弱、轉發者有問題、智能合約漏洞、重放攻擊或錯誤最終性假設而失敗。

狀態承諾有助於降低信任需求，但不會自動讓每座跨鏈橋安全。

狀態承諾與資料可用性

資料可用性是指驗證或重建狀態轉移所需資料可公開取得。

單靠狀態承諾並不保證使用者能檢查狀態如何產生。

惡意行為者可發布新承諾，同時隱藏驗證轉移所需資料。

因此，資料可用性是 Rollup、分片及模組化區塊鏈系統的重要議題。

官方Ethereum 資料可用性文件說明，資料可用性關乎交易資料是否已發布，讓參與者得以驗證或重建狀態。

狀態承諾與資料可用性相互配合。

承諾指出被宣稱的狀態為何。

可取得的資料讓其他人檢查通往該狀態的轉移是否有效。

沒有資料的承諾可能成為黑箱。

可擴充的區塊鏈同時需要精簡承諾與可存取資料。

狀態承諾與無狀態客戶端

無狀態客戶端是一項長期擴充構想，讓節點不必在本地儲存完整狀態也能驗證區塊。

不再由每個節點保留整個狀態資料庫，而是由區塊生產者或對等節點提供見證資料，以證明區塊所存取的狀態值。

官方Ethereum 無狀態化文件說明，無狀態化旨在讓節點使用見證資料而非大型本地狀態資料庫來驗證區塊。

狀態承諾是此設計的核心，因為見證資料必須依據承諾驗證。

若見證資料證明所有已存取數值均與前一狀態承諾相符，且最終數值產生新承諾，驗證者便能以較少本地狀態檢查區塊。

這可能隨時間讓節點營運更容易。

不過，目前 Merkle Patricia Trie 的見證資料可能很大。

這也是 Ethereum 研究聚焦於 Verkle tree 與更小見證結構的原因之一。

無狀態化不僅是儲存技巧。

它仰賴能支援高效率證明的狀態承諾。

狀態承諾與 Verkle tree

Verkle tree 是一項擬議升級路徑，旨在讓 Ethereum 狀態證明更小、更有效率。

官方Ethereum Verkle tree 文件將 Verkle tree 描述為一種資料結構，可協助 Ethereum 節點不再儲存大量狀態資料，同時保留驗證區塊的能力。

Verkle tree 結合樹狀結構與向量承諾。

Verkle 名稱來自 vector commitment 與 Merkle tree。

相較於目前的 Merkle Patricia Trie 證明，對於許多狀態存取模式，Verkle 證明可以小得多。

較小的見證資料對無狀態客戶端與未來擴充相當重要。

Verkle tree 不會消除狀態承諾的需求。

它改變的是用於表示與證明狀態的承諾結構。

這顯示狀態承諾是一個可透過不同加密學資料結構實作的廣泛概念。

承諾方法可以演進，但對狀態進行承諾的需求仍是基礎。

狀態承諾與向量承諾

向量承諾是對一個數值清單或向量的加密學承諾，可支援與個別位置有關的高效率證明。

向量承諾可用於區塊鏈狀態，因為相較於某些雜湊樹方法，它可縮小證明大小。

Verkle tree 在樹狀結構中使用向量承諾。

這不同於傳統 Merkle tree；傳統 Merkle tree 使用兄弟節點雜湊值驗證路徑。

向量承諾可讓證明更精簡，但也可能引入不同的加密學假設與實作複雜度。

對使用者而言，重點不在數學細節。

重點是較新的狀態承諾系統旨在降低證明狀態的成本。

較小的證明可協助輕客戶端、無狀態客戶端、Rollup、跨鏈橋及隱私保護系統。

不過，新的承諾機制在用於保護大型公開網路前，必須經過審慎測試。

狀態承諾設計始終是在證明大小、驗證成本、更新成本、安全性假設與實作風險間取得平衡。

狀態承諾與稀疏 Merkle tree

稀疏 Merkle tree 是加密貨幣系統中另一種常見的狀態承諾結構。

當金鑰位於極大的固定金鑰空間時，常會使用此結構。

每個可能金鑰在樹中都有位置，但多數位置可能是空的。

依實作方式而定，空分支可被壓縮或有效表示。

稀疏 Merkle tree 很有用，因為它支援明確的存在與不存在證明。

部分 Layer 2 系統、跨鏈橋、錢包及應用專用區塊鏈會使用稀疏 Merkle tree 或其變體進行狀態承諾。

它們並不等同於 Ethereum 目前的 Merkle Patricia Trie。

它們是解決相同基本問題的另一種方式。

這個問題是如何承諾龐大的鍵值狀態並有效證明個別數值。

這種多樣性表明，狀態承諾是一種設計類別，而非單一資料結構。

狀態承諾與 Bitcoin

Bitcoin 通常不會以 Ethereum 類型的全域帳戶狀態承諾來描述。

Bitcoin 區塊透過區塊標頭中的 Merkle 根承諾交易。

Bitcoin 的即時可花費狀態是 UTXO 集合，該集合由交易歷史衍生而來。

官方Bitcoin 區塊鏈開發者指南說明，區塊標頭包含該區塊交易的 Merkle 根。

這表示 Bitcoin 擁有強大的交易包含承諾。

不過，Bitcoin 的區塊標頭不會直接承諾整個目前 UTXO 集合，這不同於 Ethereum 為帳戶狀態加入狀態根的方式。

部分研究與提案曾探討 UTXO 承諾，因為直接承諾可花費狀態可協助輕客戶端與驗證模型。

這項比較很有用，因為它顯示不同區塊鏈承諾的資料不同。

Ethereum 類型的智能合約系統需要明確狀態承諾，因為應用程式高度依賴目前帳戶與合約狀態。

Bitcoin 的模型則更直接聚焦於交易歷史及由其衍生的 UTXO 集合。

狀態承諾與帳戶型區塊鏈

帳戶型區塊鏈通常需要明確的狀態承諾，因為帳戶餘額與合約儲存資料是執行的核心。

交易執行時，可能更新帳戶餘額、Nonce、智能合約儲存資料、質押紀錄及應用程式資料。

最終狀態必須受到承諾，使其他節點可驗證確切結果。

這就是狀態根常見於智能合約平台的原因。

它們讓網路擁有一個對廣泛狀態資料庫的單一承諾。

若沒有可靠狀態承諾，要證明合約儲存值正確將更困難。

建立依賴帳戶或儲存證明的跨鏈橋、Rollup 及輕客戶端也會更加困難。

帳戶型鏈的狀態通常比簡單支付系統更複雜。

此複雜性使狀態承諾設計特別重要。

鏈的可程式化程度越高，已驗證狀態就越有價值。

狀態承諾與物件型區塊鏈

部分區塊鏈使用物件型狀態模型，而非簡單帳戶型狀態。

在物件型系統中，資產、合約與資料可表示為具有擁有者、欄位及權限的物件。

這些系統仍需要狀態承諾。

承諾可彙總物件所有權、物件內容、版本號碼、套件資料或執行結果。

確切結構與 Ethereum 的全域帳戶 Trie 不同。

但目標仍是讓目前狀態可驗證。

若物件變更所有權，狀態承諾應反映該變化。

若物件內容變更，承諾也應反映該更新。

這表示狀態承諾並不限於 Ethereum 類型的帳戶模型。

任何維護即時狀態的區塊鏈，都需要某種方式安全地承諾該狀態。

狀態承諾與智能合約儲存資料

智能合約儲存資料是狀態承諾複雜的主要原因之一。

智能合約可儲存餘額、核准、倉位、委託單、投票、設定值及許多其他紀錄。

這些數值可能會在每筆交易後發生變化。

狀態承諾必須準確反映這些變化。

在 Ethereum 上，每個合約的儲存 trie 都有自己的根，而合約帳戶會將該根儲存在全域狀態 trie 中。

這可為特定合約儲存槽提供證明。

例如，證明可顯示某個代幣餘額映射在特定區塊具有特定數值。

這對稽核、跨鏈橋、治理、Rollup 及跨鏈驗證都很有用。

智能合約儲存讓狀態承諾更強大，但也會使其負擔更重，因為狀態可能變得非常龐大。

這也是儲存成本、狀態膨脹與證明大小成為主要擴容考量的原因。

狀態承諾與代幣餘額

代幣餘額通常儲存在智能合約儲存空間中，而非直接儲存在基礎帳戶狀態中。

這表示，要證明代幣餘額可能需要代幣合約的儲存證明。

原生幣餘額可從帳戶物件證明。

代幣餘額可能需要證明代幣合約帳戶，以及該合約儲存根內相關的儲存槽。

這項區別對跨鏈橋與空投很重要。

需要驗證代幣所有權的系統，應了解該所有權儲存在哪裡。

系統不應假設每筆餘額都屬於同一個狀態欄位。

狀態承諾可同時支援原生幣與代幣證明，但證明路徑可能不同。

開發者在建立證明系統前，應了解代幣標準與儲存配置。

只有在驗證者確切知道正在證明何種數值時，狀態承諾才有用。

狀態承諾與 NFT

NFT 所有權也可以透過狀態承諾表示。

NFT 合約通常會儲存每個代幣 ID 的所有權資料。

NFT 所有權證明可能需要驗證特定區塊中相關合約儲存數值。

這可用於跨鏈 NFT 橋、快照投票、權限控管存取、獎勵及歷史所有權查核。

不過，NFT 中繼資料不一定完全由區塊鏈狀態承諾。

部分 NFT 中繼資料儲存在鏈下，或透過外部連結引用。

狀態承諾可以證明鏈上所有權，但不一定能證明鏈下圖片或中繼資料檔案會永遠可用。

對於認為狀態證明能證明 NFT 一切資訊的使用者而言，這項區別很重要。

狀態證明通常僅證明正在查驗的鏈上狀態數值。

狀態承諾功能強大，但不會自動驗證鏈下資料的永久可用性。

狀態承諾與歷史狀態

狀態承諾與鏈上歷史中的特定區塊或時間點相關聯。

目前的狀態承諾可證明目前狀態。

如果驗證者擁有舊區塊標頭與正確的證明，舊狀態承諾可證明歷史狀態。

這對稽核、快照、法律紀錄、治理及歷史申領很有用。

不過，儲存歷史狀態資料的成本可能很高。

許多全節點會保留目前與近期狀態，但會修剪較舊的中間狀態。

封存節點會保留更多歷史狀態，因此可更快回應舊查詢。

官方 Ethereum 封存節點文件說明，封存節點會儲存每個歷史狀態，適合快速進行歷史查詢。

這表示歷史狀態承諾可能存在於舊區塊標頭中，但為舊狀態產生證明，可能需要存取歷史狀態資料庫。

狀態承諾可保留可驗證性，但仍須有人持有建立證明所需的資料。

狀態承諾與封存節點

封存節點很重要，因為狀態承諾本身不會儲存完整狀態資料。

區塊標頭可能包含數年前的狀態根。

若要針對該舊根產生證明，節點需要存取相關歷史 trie 節點或狀態資料。

一般全節點可能無法立即取得該舊狀態。

封存節點旨在保留歷史狀態，以供快速存取。

因此，區塊鏈瀏覽器、分析公司、稽核人員與基礎設施供應商經常依賴封存節點。

對使用者而言，若證明資料不易取得，舊狀態可能比目前狀態更難驗證。

對開發者而言，這表示歷史證明系統需要審慎規劃資料儲存。

狀態承諾是精簡的錨點，但證明仍需要輔助資料。

封存基礎設施可彌補歷史驗證的這項落差。

狀態承諾與狀態膨脹

當活躍的區塊鏈狀態變得過於龐大時，就會發生狀態膨脹。

每個新帳戶、合約、儲存槽、代幣餘額、委託單與倉位，都可能增加必須承諾及維護的狀態量。

更大的狀態可能增加節點儲存空間、同步時間、資料庫工作負載與證明複雜度。

狀態承諾不會消除狀態成本。

它們僅對狀態進行摘要與驗證。

若底層狀態過度膨脹，節點仍必須儲存、更新或證明該狀態的部分內容。

因此，狀態承諾研究與狀態到期、儲存租金、修剪、無狀態化及 Verkle 樹有關。

區塊鏈不僅需要安全的承諾，也需要可長期維持的狀態管理。

狀態膨脹是智能合約平台最棘手的長期問題之一。

更好的狀態承諾可能有所幫助，但並非唯一解決方案。

狀態承諾與儲存租金

儲存租金是一種經濟工具，會針對在區塊鏈狀態中保留資料收費或保留價值。

它與狀態承諾有關，因為每一筆持久化資料最終都必須納入已承諾的狀態。

若儲存資料過於便宜，使用者與應用程式可能建立低價值狀態，並在多年內為網路帶來負擔。

若儲存成本過高，有用的應用程式可能更難建立。

狀態承諾使狀態可驗證，但不決定應由誰支付儲存該狀態的費用。

儲存租金、押金、Gas 費與回饋機制有助於處理狀態成長的經濟面問題。

狀態承諾處理的是密碼學面問題。

兩者都是永續區塊鏈設計所必需。

即使區塊鏈具有強健的狀態根，若狀態無限制成長，仍可能面臨問題。

因此，應一併研究狀態承諾與狀態經濟學。

狀態承諾與終局性

當狀態承諾與已終局確定或高度確認的區塊綁定時，會更有用。

若區塊可能被重組，其狀態承諾可能被另一條鏈分支的另一個狀態承諾取代。

這對跨鏈橋、提領、稽核及跨鏈訊息很重要。

跨鏈橋不應依賴可能輕易被回滾的區塊狀態承諾。

輕客戶端應了解其驗證狀態的鏈之終局性模型。

某些鏈採用機率性終局性，信心會隨時間提高。

某些鏈則具有明確的經濟終局性或 BFT 式終局性。

承諾證明的是相對於某個區塊的狀態。

終局性則告訴使用者，該區塊會維持為規範鏈的可信程度。

當底層區塊承諾也依相關共識規則達到終局性時，狀態證明最為可靠。

狀態承諾與共識

共識與狀態承諾共同運作，但兩者並不相同。

共識決定接受哪些區塊及其順序。

狀態轉換函數會執行這些區塊並產生新狀態。

狀態承諾會對新狀態進行摘要。

若共識接受含有錯誤狀態根的區塊，誠實節點應在執行驗證期間拒絕該區塊。

若節點對執行規則意見不一，可能計算出不同的狀態承諾並造成分裂。

因此，客戶端實作必須完全依照協議規則計算狀態承諾。

狀態承諾對共識至關重要，因為它代表執行後已達成共識的結果。

它們不只是資料庫索引或可選的中繼資料。

錯誤的狀態承諾可使區塊無效。

狀態承諾與 RPC 供應商

RPC 供應商是錢包與 dApp 用來讀取及提交區塊鏈資料的服務。

當錢包查詢餘額時，RPC 供應商會從節點讀取狀態。

當 dApp 檢查合約數值時，供應商可能讀取合約儲存空間，或根據目前狀態模擬執行。

不過，一般 RPC 回應不一定是密碼學證明。

它可能只是供應商回報的數值。

當供應商同時提供證明資料時，狀態承諾可支援更強的驗證。

對 Ethereum 而言，EIP-1186 定義了用於帳戶與儲存證明的 eth_getProof。

這表示需要更高保證程度的應用程式，可要求證明資料，而非信任單純的回應。

大多數一般使用者不會手動驗證這些證明。

不過，狀態承諾為可降低對基礎設施供應商信任需求的工具奠定基礎。

狀態承諾與索引器

索引器會整理區塊鏈資料，讓應用程式可快速搜尋。

它們可能追蹤代幣轉帳、NFT 所有權、DeFi 倉位、治理投票或帳戶活動。

索引器很有用，因為原始狀態與日誌可能難以直接查詢。

不過，經索引的資料並不等同於狀態承諾。

索引器可能出錯、落後於區塊鏈，或採用自己的解讀規則。

狀態承諾是協議密碼學驗證系統的一部分。

對高價值或安全敏感的應用程式而言，可能需要將索引資料與已承諾狀態或收據進行核對。

當索引器輸出會觸發金融操作時，這點尤其重要。

索引器提升可用性，狀態承諾則提升可驗證性。

可靠的加密貨幣應用程式應了解兩者差異。

狀態承諾與隱私

狀態承諾可支援保護隱私的系統，但不會自動提供隱私。

在公鏈上，狀態承諾通常概括公開或可公開推導的狀態。

視鏈與工具而定，任何人都可能檢視餘額、合約儲存空間及交易歷史。

保護隱私的系統可能以不同方式使用承諾。

例如，協議可對隱藏數值進行承諾，並使用零知識證明來顯示轉換有效，而不揭露所有細節。

在這類系統中，承諾可隱藏資料，同時支援驗證。

因此，commitment 一詞的涵義比公開狀態根更廣。

依設計而定，狀態承諾可能是透明、私密或部分私密的。

除非協議明確提供隱私功能，使用者不應假設狀態承諾會隱藏資料。

大多數公鏈狀態承諾著重完整性，而非機密性。

狀態承諾與零知識證明

零知識證明通常使用承諾來表示執行前後的狀態。

證明者可顯示從一個狀態承諾轉換至另一個狀態承諾是有效的，無須讓驗證者重新執行所有內容。

這常見於有效性 Rollup、隱私系統與壓縮執行模型。

證明可表示，新狀態承諾是由舊狀態承諾及一組有效操作所產生。

依系統而定，部分資料可能公開，部分資料則可能維持隱藏。

這讓承諾成為精簡驗證與複雜計算之間的橋梁。

狀態承諾定義正在證明的內容。

零知識證明定義為何應接受該轉換。

兩者結合後，可讓系統在保有可驗證正確性的同時擴容或保護隱私。

這是現代加密貨幣基礎設施中，狀態承諾最重要的進階用途之一。

狀態承諾與不存在證明

不存在證明可顯示某個金鑰或數值不存在於已承諾狀態中。

存在證明顯示某項內容存在。

不存在證明顯示某項內容不存在。

這對帳戶建立、nullifier 檢查、稀疏 Merkle 樹、身分系統與空投申領可能很重要。

例如，隱私系統可能需要證明某個 nullifier 尚未被使用。

跨鏈橋可能需要證明某則訊息尚未被消費。

登錄系統可能需要證明某個名稱或金鑰仍未分配。

某些承諾結構比其他結構更容易產生不存在證明。

這也是狀態承諾設計的重要性不僅限於簡單餘額證明的原因之一。

良好的狀態承諾系統應支援協議實際所需的證明類型。

狀態承諾與安全假設

狀態承諾依賴密碼學假設。

基於雜湊的承諾依賴雜湊函數的抗碰撞性與抗原像性。

向量承諾可能依方案而定，仰賴不同的數學假設。

若底層密碼學遭到破解，承諾可能不再可信。

實作安全性同樣重要。

即使承諾方案正確，若客戶端軟體錯誤編碼數值或不當驗證證明，仍可能造成危險。

對共識至關重要的程式碼必須精確處理邊界情況。

不同客戶端必須從相同狀態計算出相同承諾。

因此，重大區塊鏈升級會審慎處理狀態承諾變更。

改變承諾結構，就是改變區塊鏈安全模型的深層部分。

狀態承諾與開發者工具

開發者會透過 RPC 方法、證明系統、區塊標頭、Rollup 狀態根、儲存證明及客戶端資料庫接觸狀態承諾。

智能合約開發者可能需要了解代幣餘額的儲存方式，才能產生證明。

跨鏈橋開發者可能需要根據已終局確定的根驗證儲存證明。

Rollup 開發者可能需要在批次處理後計算並發布狀態根。

錢包開發者可能需要決定信任 RPC 數值，或驗證證明。

索引器開發者可能需要協調已索引事件與已承諾狀態。

協議研究人員可能比較 Merkle Patricia Trie、稀疏 Merkle 樹、Verkle 樹及其他累加器。

這些都是不同形式的狀態承諾問題。

理解此概念有助於開發者避免混淆交易納入、事件日誌、收據與實際狀態。

最安全的系統會清楚說明正在驗證哪種承諾，以及正在證明哪個狀態數值。

對狀態承諾的常見誤解

一個常見誤解是，狀態承諾包含完整狀態。

它並不包含完整狀態，因為它只是該狀態的精簡密碼學摘要。

另一個誤解是，交易證明等同於狀態證明。

交易證明可顯示納入情況，狀態證明則可顯示產生的狀態數值。

第三個誤解是，狀態承諾讓資料可用。

承諾可證明完整性，但資料可用性是另一項要求。

第四個誤解是，每條區塊鏈都以相同方式承諾狀態。

不同鏈採用不同的狀態模型與承諾結構。

第五個誤解是，狀態承諾自動代表隱私。

大多數公開狀態承諾提供的是完整性與可驗證性，而非機密性。

狀態承諾的優點

狀態承諾的第一項優點是精簡驗證。

一個小型根值可代表非常龐大的狀態資料庫。

第二項優點是竄改可察覺性。

變更底層狀態會改變承諾。

第三項優點是證明支援。

使用者可透過存在或不存在證明驗證特定數值。

第四項優點是支援輕客戶端。

輕客戶端無須儲存完整狀態，也能查驗選定的狀態數值。

第五項優點是支援擴容。

Rollup 與證明系統使用狀態承諾來概括龐大的執行批次。

第六項優點是跨鏈驗證。

跨鏈橋與訊息系統可依據其他鏈或層的承諾驗證申明。

第七項優點是可稽核性。

狀態承諾有助於顯示每個區塊都產生特定且已達共識的狀態。

狀態承諾的限制

第一項限制是，承諾本身不提供底層資料。

使用者仍需要資料可用性與證明資料來驗證申明。

第二項限制是證明大小。

某些承諾結構產生的證明過大，不利於高效率的輕客戶端或無狀態驗證。

第三項限制是更新成本。

在多個狀態數值變更後更新承諾，可能需要高昂的運算成本。

第四項限制是實作複雜度。

編碼、雜湊、證明產生及證明驗證都必須精確無誤。

第五項限制是歷史存取。

舊承諾可能存在於區塊標頭中，但產生證明可能需要封存節點中的舊狀態資料。

第六項限制是安全假設。

不同承諾方案依賴不同的密碼學保證。

第七項限制是對使用者不可見。

大多數使用者不會直接看到狀態承諾，因此錢包與應用程式必須清楚說明基於證明的安全性。

如何評估狀態承諾系統

首先確認正在承諾何種狀態。

接著檢查由哪種資料結構建立承諾。

檢視承諾是否支援存在證明。

若應用程式需要，檢視其是否支援不存在證明。

檢查證明大小與驗證成本。

檢查許多狀態數值變動時的更新成本。

檢視承諾方案背後的密碼學假設。

確認目前及歷史狀態的證明資料是否容易取得。

檢視承諾是否已納入終局確定的區塊、Rollup 批次或其他可信錨點。

詢問資料可用性是否已獨立於承諾本身解決。

開發者最佳實務

在實作證明驗證前，應使用官方協議文件。

在設計中將交易納入證明與狀態證明分開處理。

盡可能依據可信且已終局確定的承諾驗證證明。

不要假設事件與日誌等同於已承諾的儲存數值。

在證明代幣餘額、NFT 所有權或治理權力前，先了解合約儲存配置。

若應用程式需要舊狀態快照，應規劃歷史證明產生方式。

除狀態承諾驗證外，也要考量資料可用性。

應仔細稽核證明驗證程式碼，因為微小的編碼錯誤可能成為嚴重漏洞。

若系統高度依賴 Ethereum 狀態證明，請追蹤 Verkle 樹研究等路線圖變更。

記錄應用程式證明的內容、所用承諾及仍存在的假設。

使用者最佳實務

請了解，顯示的餘額可能來自 RPC 供應商或索引器，而非您親自驗證的證明。

使用可信錢包與區塊鏈瀏覽器，但請記住，高價值系統可能需要更強的證明式驗證。

對聲稱驗證另一條鏈狀態的跨鏈橋保持謹慎。

確認跨鏈橋依賴原生證明、驗證者、中繼者、多重簽章或外部委員會中的哪一種機制。

了解狀態承諾不保證所有資料都容易存取。

請記住，若要有效率地證明舊狀態，可能需要封存基礎設施。

不要假設交易被納入就代表最終狀態變更已成功完成。

在依賴狀態承諾進行高價值操作前，請等待充分的終局性。

與依賴跨鏈狀態證明的系統互動時，請使用小額測試交易。

只有在證明確實已依正確承諾完成驗證時，才應將基於證明的申明視為比一般申明更可靠。

常見問題

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

狀態承諾是一種密碼學根或承諾，可用精簡且可驗證的方式表示區塊鏈目前狀態。

狀態承諾與狀態根相同嗎？

狀態根是常見的狀態承諾類型，尤其常見於 Ethereum 類型的區塊鏈。

狀態承諾能證明什麼？

狀態承諾本身不能證明某個數值，但搭配有效狀態證明時，可讓使用者驗證數值。

為何 Ethereum 使用狀態根？

Ethereum 使用狀態根，對每個區塊執行後的全域世界狀態進行承諾。

狀態承諾與交易根有何差異？

狀態承諾代表區塊鏈產生的狀態，交易根則承諾納入區塊的交易。

什麼是 Merkle 證明？

Merkle 證明是輔助資料，讓驗證者可檢查某個數值是否屬於根所承諾的狀態。

Rollup 如何使用狀態承諾？

Rollup 在執行多批交易後，使用狀態承諾概括其 Layer 2 狀態。

狀態承諾能解決資料可用性嗎？

不能。狀態承諾證明完整性，資料可用性則確保驗證或重建狀態轉換所需的資料可存取。

什麼是 Verkle 樹？

Verkle 樹是一種提案中的狀態承諾結構，使用向量承諾來支援更小的見證資料及更有效率的無狀態驗證。

狀態承諾是私密的嗎？

不一定。除非結合保護隱私的密碼學技術，否則大多數公鏈狀態承諾提供的是可驗證性，而非機密性。

結論

狀態承諾是在特定時間點對區塊鏈活躍狀態作出的精簡密碼學承諾。

它讓大量餘額、帳戶、合約儲存空間與應用程式資料，可由小型根或承諾數值表示。

在 Ethereum 中，狀態根是全域執行層狀態的主要狀態承諾。

該根由 Merkle Patricia Trie 產生，並會在底層狀態變動時改變。

狀態承諾對共識、輕客戶端、Merkle 證明、Rollup、跨鏈橋、稽核與無狀態客戶端研究至關重要。

它們讓使用者無須盲目信任資料庫供應商，也能驗證狀態相關申明。

它們也支援詐欺證明、有效性證明與跨鏈訊息等進階系統。

不過，狀態承諾不等同於完整資料可用性、交易納入、收據日誌或隱私。

它必須搭配正確的證明、正確的資料及正確的終局性假設。

隨著區塊鏈持續尋求更小的證明、更快的更新與更低的節點需求，狀態承諾設計也持續演進。

Verkle 樹與無狀態化研究顯示，狀態承諾的未來仍是活躍的工程與密碼學議題。

在加密貨幣詞彙表的語境中，State Commitment 是指一種密碼學錨點，讓區塊鏈無須將完整狀態放入每個區塊標頭，也能證明其狀態內容。

關鍵重點是，狀態承諾將龐大的區塊鏈狀態轉化為可驗證的根，使節點、錢包、Rollup、跨鏈橋及應用程式能進行最小化信任驗證。