坏编码证明是什么？Celestia 轻节点收到 BEFP 后的停摆与恢复全链路

轻节点的问题：数据真的发布了吗

Celestia 把共识和数据发布拆开：轻节点只下载区块头，靠数据可用性采样确认自己关心的数据碎片可得。采样有一个天然的怀疑论问题——如果出块者发布的扩展数据本身编码错误，比如原始行和纠删码补出的校验碎片对不上，采样看到的碎片可以个个”有效”，整块数据却无法正确重建。轻节点自己发现不了这种情况，需要别人把错误证明送到面前。

坏编码证明由谁生成

按 celestia-node 官方仓库的架构决策记录 ADR-006，这条职责落在全节点上。全节点重构每一个扩展数据方阵，用 Reed-Solomon 解码交叉校验行列承诺；一旦恢复出的数据与其行或列根不匹配，底层库返回拜占庭数据错误，全节点随即把出错那一行或列的碎片连同各自的默克尔证明打包成坏编码欺诈证明（BEFP），通过 pubsub 主题广播给全网。ADR 同时注明当时只实现了 badencoding 这一种证明类型——这套机制防的是”数据编码错误”，不是共识分叉之类的其他故障。

轻节点收到证明之后

其他节点默认订阅该主题并逐条验证：先检查证明里的默克尔证明确实对应所述碎片，再用证明携带的碎片重建整行或整列、重算默克尔根，与区块头数据可用性头里的根比对——根对得上反而说明证明造假，对不上才是真坏编码。验证通过后，全节点与轻节点都会停掉受影响的服务：数据可用性采样、区块同步与交易提交。也就是说，一条被证明编码错误的链不会继续被下游当作可用的数据层，L2 的读取者被强制中止而不是静默出错。

重启不自愈：证明会被持久化

欺诈证明写入本地 datastore 并以区块哈希为键。已经落盘证明的节点重启时直接拒绝启动并报出错误，运维必须显式处理——重置状态或切换到另一条可信链。针对证明出现之后才上线的节点，ADR-006 描述了 FraudSync：轻节点连接新 peers 后主动索取欺诈证明，收到即验证并广播到本地订阅；发来无效证明的 peer 会被拉黑。这条通道保证”停摆信号”能追上离线期间错过了 gossip 的节点。

采样与证明的分工

值得把两件容易混在一起的事分开：日常的采样回答的是”碎片拿得到吗”，欺诈证明回答的是”整块编码对吗”。轻节点每次采样只向 peers 索取少量碎片并核对它们在数据可用性头承诺下的默克尔证明，这个动作计算量极小、可以按高度持续跑；而重算整行整列、做 Reed-Solomon 解码是重构级别的开销，本来就不指望轻节点逐块执行。ADR-006 把重活安排给全节点、把”听坏消息”安排给轻节点，正是按这两类节点的开销预算划的界。也因此，轻节点对数据的信心来自”采样全部通过 且 本地欺诈存储为空”两个条件的合取，缺一个都不成立——监控面板上只看采样成功率会漏掉已经收到证明但采样仍显示正常的状态。

边与界

这套设计值得注意的边界有三个。其一，检测能力依赖至少有人跑全节点重构每个区块，检测是尽力而为而非强制义务。其二，证明传播走 pubsub，恶意 peers 可以压制订阅者的消息送达，FraudSync 与多 peer 连接是对这类 Eclipse 风险的缓解手段之一。其三，机制文档写在仓库 ADR 里，属于实现级描述，随代码演进可能变化；引用具体行为时应对照当时的仓库文档与代码，而不是把 ADR 当永久规格。

本文为机制说明，不构成投资建议；数据可用性故障场景的处置应以项目当前文档为据。