发布过不等于永远查得到：Celestia 数据可检索性与裁剪

一个容易被混用的词

数据可用性（availability）回答的是”这份数据此刻公开了吗”：想重建状态的人现在能不能拿到构建区块所需的全部输入。数据可检索性（retrievability）问的是另一个问题：“我去年发的数据，今天还能不能从某个节点查回来？“Celestia 官方文档在《数据可检索性与裁剪》一页里把这条分界线摆得很清楚：数据可用性层的设计目标是让区块数据可证明地公开发布，从而让应用和 rollup 能确定自己链的状态；但发布之后，这一层本身并不保证历史数据被永久存储。

这不是 Celestia 独有的取舍，官方文档还引用了以太坊开发者对原型 danksharding 常见问题的同源回答——如果数据在三十天后被删除，用户如何访问旧数据，说明模块化 DA 层与以太坊 L1 面对的是同一类追问。

采样窗口与裁剪的具体规则

Celestia 官方文档在《数据可检索性与裁剪》里给出了可核对的当前事实：从 celestia-app 第 6 版本起，celestia-node 按 CIP-36 实现了七天的轻节点采样窗口。CIP-36（状态为 Final）把 Celestia 的信任期（弱主观性周期）压缩到七天，并相应把采样窗口定为七天，同时声明信任期、采样窗口与最低裁剪窗口三者的取值彼此独立。轻节点不再对从创世块起的所有区块采样，而是只对最近七天窗口内的区块做数据可用性采样。窗口之外的数据不再被轻节点存储，这就是引入到 celestia-node 里的裁剪（pruning）：超出新近窗口的数据块在轻节点上默认被清掉，但会继续保存在不裁剪数据的归档节点里。轻节点仍可向公网上还存在的归档节点查询历史命名空间里的数据。

换句话说，“可用性”验证集中在发布后的七天内；七天之后，这份数据还能不能查回来，取决于网络里是否仍有归档节点愿意为它服务。

官方给 rollup 开发者的提醒

文档对架在 Celestia 上的 rollup 写得很直接：数据被证明公开发布之后，rollup 和应用自己负责存历史数据，因为新节点要靠重放历史区块重建最新状态。虽然只要公网还有归档节点，理论上可以继续用 celestia-node 的 GetAll 接口去取历史区块，但文档明确建议不要把这条当作唯一通道——免费的历史数据归档服务并不受保证。文中给出的替代做法包括：使用专业归档节点或数据提供商的付费存档接口（并举例有基础设施商提供含完整历史数据的归档端点）、分享 rollup 节点数据目录快照供新节点直接引导，等等。

不同角色的核对清单

Daniel Park 式的核验视角可以这样拆：如果你是某条架在 Celestia 上的 rollup 用户，关心”历史区块还能不能重放验证”，应该去查该 rollup 官方文档指定的数据来源——它是否运行自己的归档节点或提供快照，而不是默认 DA 层替它保管一切。如果你是轻节点操作者，要理解采样窗口的含义：重新入网的节点只需在七天窗口内采样，初始同步的带宽需求随之下降，代价是这类节点不再为网络回答窗口之外的历史查询，也不再随链龄存储数据。如果你是链上数据研究者，则要注意同一笔历史数据在归档节点查得到、在激进裁剪的轻节点就是查无此据——遇到这种情况先换节点类型再下结论，同名资产与不同层的数据也不能混着查。

边界说明

值得强调两点：其一，“可用性层不永久存数据”不等于”数据会丢”，在归档节点保留期间它完全可检索，风险在于没有任何一方负责时窗口会随时间收窄；其二，裁剪与保留不是 Celestia 专属概念，凡用链外数据加密码学承诺的体系（各类 DA 层、以太坊的 blob 保留期）都要回答同一笔账——谁存、存多久、付费是否覆盖到未来的某一年。窗口长度、默认裁剪配置与检索接口随版本变化，文中数值对应官方文档记载的 celestia-app v6 与 CIP-36 口径，请以当前版本为准。

本文为机制与概念说明，不构成投资建议；依赖外部数据存档的协议存在检索中断风险，涉及资产恢复路径时请以项目官方文档为准自行核实。