闪电静态通道备份 SCB：只存开通道信息，丢了会怎样

从“全丢”到“只剩一条命”

闪电节点最怕的事故不是宕机，是数据目录损坏又没有任何备份：通道状态不在本地，节点连自己“和谁开过通道”都不记得，资金像被冻在空气里。静态通道备份（Static Channel Backup，SCB）就是为这个最坏场景准备的：一个不随通道日常状态变化、只在开/关通道时变化的加密摘要文件。文档对它的定性很直白——灾难发生后，SCB 不能复活通道，只能让你联系上老对手、把通道强制关掉、让资金回到链上。

里面有什么，外面有什么

以 lnd 官方恢复文档描述为准，每条通道对应一份 SCB，内容包含两条核心信息：通道承诺交易的出资点（那条锁资金的上链交易标识）与对端节点的连接信息（地址、身份）。整份备份用本节点私钥加密，配合种子词（aezeed）才能在新装节点上解密使用——SCB 单独泄露不暴露内容，但也不能给任何人用。刻意没存的东西同样关键：没有通道余额，没有 HTLC 历史，没有“最新状态”。这不是实现偷懒，而是设计使然：任何随状态更新而更新的备份，都要你为每次更新做在线动作，等于把备份义务的频率推回高频区间；静态备份把义务降到只有“开新通道/关旧通道后要更新”，配合“备份放远端并同步更新”的低频纪律。

恢复那天实际会发生什么

设想节点彻底重做：装好软件、用种子词和 SCB 文件恢复。此时节点知道了每条通道的对手与出资交易，接下来的路径是：逐一连接对端，请求对方广播其持有的承诺交易（或己方从备份中可用的最新本地状态若存在——注意纯 SCB 场景没有本地状态），你的输出按出资脚本落到你控制的链上地址。要点三条。其一，一切回到链上：通道不再存在，想要继续用闪电网络需要重新开户，手续费在链上按当时费率另付。其二，你的到账金额取决于对手广播的那一版状态——诚实对手按最新余额关，这正是闪电信任模型的既有假设，SCB 本身不改变它；若对手广播旧状态，惩罚窗口机制照常适用，此时你若无最新本地状态可发惩罚交易，就必须依赖监控与看门塔，这属于备份体系之外的另一层。其三，HTLC 等中间态会引入额外延迟与复杂性，恢复期的资金回流以链上确认节奏为准。

纪律清单与高频踩坑

日常纪律按官方提示一句话化：每开一条新通道，立即更新并异地保存 channel.backup；lnd 路径在数据目录的 channel.backup 文件，单通道也可用 lncli exportchanbackup 导出核对。高频踩坑清单：恢复后继续用旧数据目录里的残留数据库——版本错配可能触发数据完整性保护甚至资金损失，恢复文档明确要求不要带旧库进门；把 SCB 当“云同步状态”——它是静态钥匙串，不是状态流水账，指望它记住最新余额是范畴错误；以及只备份 SCB 不备份种子——SCB 的解密依赖节点私钥，而节点私钥依赖 aezeed，缺一即废。还有一类隐性损失：SCB 文件长期不更新时，新开通道在灾难后形同遗失，只能靠对端善意配合才可能关回，这就是“开新通道就更新”被反复强调的原因。把这些纪律排进日程其实很轻：备份更新的触发事件只有开通道与关通道两类，频率天然远低于链上备份的需求；真正难的是坚持每次事件都执行并验证异地副本可读——一次恢复演练胜过十次口头承诺，演练时用一台干净设备走完整流程，看完即销毁临时数据，不留任何联网痕迹。

风险提示：本文为备份机制说明，不构成投资建议；闪电恢复流程涉及链上费用与时序，请结合自身节点实现官方文档演练验证。