优币志 / 知识读本 · 基础设施 · 2 分钟阅读
一个哈希可以承诺某份数据没有被更改，却不能让不知道内容的人凭空恢复数据。区块链扩容讨论中的数据可用性，关心的是参与者能否获得验证或重建状态所需要的数据。它与计算正确性相关，但解决的是不同问题。
证明正确不等于能重建账本
状态承诺像一份文件的指纹，能够帮助验证内容是否一致。若文件根本没有公开，用户拿到指纹也无法知道各账户余额。有效性证明可以约束某种状态转换正确，却不自动保证所有用户都能获得退出所需的信息。
因此，研究扩容方案时应分别追问执行在哪里发生、状态如何证明、交易数据在哪里发布，以及发生停机时谁能获取数据。只展示一个被主网接受的状态根，不能回答全部问题。
算例：运营者消失之后
假设某系统处理了一千笔转账，只向主网提交新状态的哈希。如果运营者随后失联，普通用户可能不知道怎样构造自己最新余额的证明。若必要交易数据已经公开，独立参与者则可能重放规则、重建状态并帮助用户退出。
这个对比说明数据发布不仅服务审计，也影响故障恢复。具体系统可能采用压缩数据、状态差分或其他编码，是否足够重建需要依据协议规则判断，而不是要求所有方案都保存同一种原始格式。
发布、采样与长期归档
数据可用性采样通过抽样等机制帮助判断数据是否发布，需要相应编码和网络假设支持。它不是随便下载几个字节就能证明全部内容存在。外部数据层或委员会方案也有自己的安全与可用性依赖。
数据在共识要求的时间窗口内可获得，与多年后仍有归档者保存，是不同承诺。临时数据载体可以降低成本，但长期查询可能需要额外归档服务。研究者应区分协议保证和生态参与者提供的长期保存能力。
以退出需求检验设计
先确定用户恢复资产所需的最小信息，再沿链路检查这些信息如何编码、发布、发现和保留。如果依赖某个私有接口提供证明，应验证是否存在开放实现和替代运营者，而不仅仅是文档中声称可重建。
成本比较也要完整：把数据移出底层可能降低费用，却同时改变安全假设。面对“同样安全但更便宜”的宣传，应要求说明数据失联情景，以及此时用户能否独立行动、需要等待多久。
实用检查清单
- 分开检查状态正确性证明与数据可获得性。
- 核实数据发布层、有效窗口和长期归档安排。
- 根据退出所需信息测试独立重建路径。
常见问题
把数据哈希放上主网就足够了吗？
哈希可以承诺内容，却不提供内容本身。是否足够，要看用户还从哪里取得恢复状态需要的数据，以及这种取得方式依赖谁。
数据可用性就是永久存储吗？
不是。协议可能只要求某段时间的数据可获取。长期历史保存是另一项职责，需要明确归档者、接口和保留安排。
