闪电节点的功能协商表（BOLT #9）里，option_data_loss_protect 占着 0 号与 1 号这一对最早的位，表里的状态栏只写了四个字：ASSUMED。含义是它普及到所有实现默认对方支持，init 位图里列不列都不改变语义。而这个”默认在”的位管的事一点不小：它是防止通道一侧失忆重启、被对手拿旧账收割的协议级止损开关。本文把这位 ASSUMED 特性和它的保护边界讲清。
ASSUMED 是什么状态
规范原文对这一族状态的解释是：有些特性推出后已经普及到可以假定所有节点都具备，可以在协商表里安全地忽略，其语义只在早期版本的规范里定义。功能位按对分配，0 号是 compulsory（强制位，对方缺失就该拒连），1 号是 optional（可选位）；0/1 这一对在当年的意义是”我在 channel_reestablish 里会带下一承诺序号、下一撤销序号和上份撤销密钥这几个字段”。今天主流实现早就全部支持，于是它升入 ASSUMED 行列——和它同列的还有 8/9 的变长洋葱载荷、12/13 的静态远程密钥、14/15 的付款密钥、44/45 的通道类型。抓包看不到这一对被协商，不等于对方的实现不执行它的行为。
它到底防什么
防的是”失忆重启”。设想节点 A 从一份过期备份恢复：它的承诺序号落后于对手 B。协议的行为是 B 在重连对账时发现 A 的序号与自己记录不符，按 BOLT #2 的规则发 error 让通道进入失败流程——它拒绝在一个可能签发旧承诺的状态上继续做更新，因为带着不一致的本地状态继续交易，等于双方手里各存在一套账，任何一套被拿上链都是事故。反方向同理：当自己收到的重连消息显示对方序号更超前、且对方交出的本节点历史撤销密钥能验证通过，规范禁止失忆方广播自己的旧承诺交易，只许发 error 按对方的较新状态了结通道——想拿旧账多占的口子在协议层被焊死。也就是说这个特性不是数据恢复工具，而是止损开关：它把”失忆方悄悄回到旧状态继续做生意”从隐蔽的资金风险，降级为”通道强制关闭、双方按链上事实对账”。
与备份、watchtower 的分工
三层机制解决同一事故的不同环节：本地通道数据库是主账本，备份的全部意义是让恢复后序号尽量不落后；数据丢失保护是重连对账网，兜住”恢复晚了、忘了说”的情形；替你监控链上旧状态并代播惩罚交易的 watchtower 才解决”你长期离线”的场景——而这类服务属于信任外包，部署前要想清楚对手方假设。运维上最实用的一条：每一次 HTLC 更新都是一次状态变化，两次备份之间的任何更新都可能让恢复后的节点正好落在断连分支里，备份频率要覆盖通道最活跃的更新节奏。
边界
它保护的是双向对账一致性，不防对手恶意：对手始终诚实、你单方失忆，结果是通道关闭、你按当前链上共识找回自己的份额，等待期取决于开通道时约定的 to_self_delay 延迟。它也不防备份被投毒——如果你的旧备份和对手的旧状态同出一源，对账只会一起过期。还有一条容易忽略的：对账保护的前提是双方都按规则走重连流程，如果落后方重连前就抢先单方面把旧承诺交易广播上链，那已进入 BOLT #5 的链上惩罚领域，靠的是对方用撤销密钥构造惩罚交易的机制，而不是这一位的重连检查。机制文本以 lightning/bolts 仓库 BOLT #2 与 BOLT #9 当前文本为准，各实现可能有更严的本地策略。本文只讨论自托管运维与协议，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。