通道的账本不在链上，对账就成了重连的第一课
闪电通道里每一笔更新的余额都记录在双方的本地状态里，区块链对中间过程一无所知。节点掉线或重启后，双方各自可能漏发了几条消息，谁也不能假设对方收到了什么。协议因此硬性规定：重连后必须为每一个通道各发送一条 channel_reestablish 消息，且在收到对方的这条消息之前，不得就该通道发送任何其他消息。这条“先对账再干活”的规则，是后续一切安全判断的前提。
四个字段讲清楚“我以为我们聊到哪了”
发送方要在消息里报出四个数字与点：下一个期望收到的承诺编号（即下一份 commitment_signed 应使用的编号）、下一个期望收到的撤销编号、自己当前一次性的承诺点，以及对方上一次交给自己的那个私钥样秘密（首次交互则全零）。对账逻辑就藏在这几组比对里。如果对方的承诺编号与我上一条发出的完全一致，说明它没收到我的那份签名，我按同一编号重发即可；如果撤销编号与我上一条发出的撤销消息对得上，我该补发那条 revoke_and_ack。反过来，一旦编号对不上规范期望的取值，节点应当发出 error 并让通道进入失败流程——数字错位意味着双方对“哪些状态已经作废”存在根本分歧。
数据丢失保护：规则选择保护落后的一方
最容易被忽视也最关键的条款是数据丢失保护。假设一方本地数据库被清空后恢复成了旧备份，它对账时会报出一个偏小的期望编号。协议对此的处置是：当接收方发现对方的期望撤销编号高于自己预期，而对方同时拿出了对该编号而言正确的历史撤销秘密时，接收方绝对不得广播自己的承诺交易，而应通过 error 通知对方进入失败处理。直觉上，这是在说“你的账看起来比我旧，但你能出示只有真对手才有的证据，所以我先不上链”——先广播旧状态在公开链上会把对方置于惩罚风险，先广播新状态则可能让落后者被旧状态夺走资金，协议的默认选择是冻结、留时间核账。
用户端的正确反应
- 节点异常重启后通道若没有立刻恢复：先看日志里对账是否报失配，不要凭焦虑手动强制关闭，错误的强关会把“可修复的落后”变成“真实的损失”。
- 如果软件明确提示检测到数据丢失：保持节点在线等待对手方的保护动作完成，按钱包或节点文档指引提供备份或走公开惩罚流程。
- 日常防御：备份永远在状态变化前完成，遵循节点软件自带的备份机制，不在运行中拷贝数据库。
常见误区
误区一：“重启等于关通道。”绝大多数重连只是一次普通的补发对账，钱不动。误区二：“对方不回消息我就抢先上链。”在对账未完成前广播，等于在裁判读秒时先把球踢进场地。本文只提供防御性处置顺序，不构成投资建议，也不构成对任何具体节点软件版本的描述。
一次典型事故的时间线还原
设想节点宿主机磁盘故障后从昨日备份恢复。重启连回对手时，本节点报出的期望撤销编号比对手账本里的小一，同时“对方上次的秘密”字段来自旧历史。对手一侧逐项核对：编号确实落后，但秘密值能对上落后位置的正确推导——数据丢失保护被触发，对手不上链、只报错挂起通道。此时正确的处置顺序是：确认本节点是否真的丢状态；若确认丢失，本应等待公开协议文档约定的处置路径（多数实现会在对手侧超时或人工介入后允许本节点带惩罚风险强制关闭），整个过程任何“抢先广播”都会破坏保护的前提。实践中绝大多数重启根本走不到这一步——消息补发在几秒内完成，通道重新可用。这条条款真正的价值在于它给最坏情况预设了“不互相伤害”的默认动作：在两个人各持一本对不上的账时，先停手、再对账、最后才有人碰链条。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。