链探 / 知識讀本 · 擴容與跨鏈 · 2 分鐘閱讀
知道某個狀態轉換符合規則，與取得重建狀態所需資料，是兩個不同問題。資料可用性決定其他參與者是否真的有能力驗證、接手與退出。
運作原理
區塊或批次可以公布資料承諾，讓人確認之後取得的資料是否相符；但一個雜湊本身不會把原始內容還原出來。若發布者只公布承諾卻藏起資料，其他人可能知道有一份承諾存在，卻無法檢查完整內容或重建所需狀態。
對樂觀式系統，缺資料可能阻止挑戰者重新執行並提出錯誤證明；對使用有效性證明的系統，資料仍可能是使用者重建餘額及製作提款所必需。正確性、可用性與長期保存各自解決不同問題，不能用其中一個名詞取代全部。
假設案例：把數字放回流程
假設某系統公布新狀態根及有效性證明，但把帳戶更新資料只放在單一伺服器。證明能顯示轉換遵守規則，伺服器停機後，新的使用者卻可能無法取得生成提款所需的狀態資料。此情境用來說明設計風險，並非聲稱任何特定專案一定會因此無法退出；實際結果取決於備援與退出規則。
判讀與實務
資料可用性抽樣讓參與者透過取得部分資料來增加對整體可用性的信心，通常配合編碼與網路分發設計。它提供的是在特定假設下的統計保障，不代表每個使用者都永久持有全部資料，也不直接取代長期封存服務。
限期保存的資料發布機制可以降低節點負擔，但研究者必須問清楚保存期後誰負責歷史資料。當期可下載與多年後可恢復是不同需求；錢包重建、索引服務與研究分析可能需要額外的封存安排。
比較方案時，列出資料放在基礎鏈、另一條資料鏈、委員會或中心化服務的哪一處，以及誰能拒絕提供。若安全描述只說「資料經過驗證」，仍要追問驗證了存在、完整性、可取得性，還是只驗證了一個承諾。這些字眼相近，實際保障可能相差很大。
對一般使用者，最直接的檢驗問題是：主要營運方消失後，我能從哪些公開資料恢復狀態、找誰廣播退出，以及需要什麼工具。若答案只能依靠未來計畫，就應把這項依賴納入現在的風險，而非當作已經解決。
操作前檢查清單
- 畫出資料發布位置、取得路徑與保存責任。
- 區分完整性、正確性、當期可用性與長期保存。
- 核對營運方失聯時的狀態重建及退出條件。
常見問題
有區塊雜湊就能恢復所有交易嗎？
不能。雜湊主要提供內容承諾與完整性檢查，不能從短短的結果直接還原任意長的原始資料。
資料越久不刪就一定越安全嗎？
長期保存很有價值，但還要看是否能被取得、驗證及由多方提供。只有一份不可讀取的副本，不能滿足可靠恢復需求。