闪电节点怎么协商功能？BOLT9 特性位与奇偶规则解读

闪电网络怎么在不强制的前提下升级

闪电没有可以强制全网执行的治理机构，功能怎么在互不知情的节点之间协商出来？答案藏在一个极简的设计里：每个节点用一串比特位宣告能力，协议按奇偶约定新旧软件如何相处。这套机制定义在 BOLT9，几乎所有闪电功能都挂在它的表格里。

比特位怎么宣告

节点在初始化消息里发送一张特性表，每个功能占一对编号，偶数表示必须支持、奇数表示可选支持。同一对的两个位同时声称是不允许的；若对端这么做，按规范该功能应被当作必须处理。功能之间存在依赖：声明某项能力时必须连带声明它依赖的能力，例如基础多部分支付依赖支付私密字段所对应的能力。节点还必须支持变长洋葱这一基础项。特性出现的场合也有区分：有的出现在初始化消息，有的出现在通道公告或发票里，有的用于打开通道时的通道类型协商。

奇数位与偶数位的本质差别

这套机制的精髓是面向未来的容错规则，并同时体现在消息与字段上。收到类型编号为奇数的未知消息，节点必须忽略并继续工作；收到偶数类型的未知消息，必须断开连接，还可以失败通道。TLV 字段同理：遇到未知的奇数类型字段就跳过它的长度所对应的字节，遇到未知的偶数类型字段则整体解析失败。翻译成工程语言：想给旧节点看的新增内容是安全的（奇数），想让旧节点用断链表达我不接受这个要求的就是必选类字段（偶数）。特性位上同理——只声明奇数位是可选能力，双方都能安全忽略；声明偶数位意味着不支持就该拒绝建立通道。

升级是怎么发生的

一个新功能从提案到普及的常见轨迹：先进入 BOLT 文本并分配比特位，实现方以可选模式发布，网络比例上升后，某些通道类型或协议版本把它升级为必选，或在依赖关系上收紧。用户在节点软件里看到的那些开关，最终都映射到这张协商表上——这也是为什么两台都支持某功能的设备，仍可能因为一侧把它关掉而用不了。锚定输出、双出资、拼接更新等功能都走的是这条路径，各自在表里占一对编号，并注明出现在哪些消息与字段中。

对普通用户的意义

钱包提示对端不支持某功能时，本质是双方协商集合的交集为空。排查顺序：确认双方软件版本，检查配置里是否关掉了某项能力，再看当前场景是打开通道、发票还是消息转发所要求的位。不要手工伪造比特位去骗过检查——按规范，伪造声明造成的状态错乱由造假一侧承担断链后果。

边界

特性协商解决功能兼容，不解决实现质量：都声明支持不代表行为一致，选型仍要看实现文档与社区审计记录。细节以 lightning/bolts 仓库 BOLT9 与 BOLT1 当前文本为准。本文只做机制科普，不构成运行或投资建议。

与链上软分叉治理的对照

把这套机制放到比特币的大治理图景里看更有意思：链上软分叉靠矿工用版本位投票、按部署周期生效，节点用查询命令观察部署状态；闪电网络则没有可投票的权重结构，能力协商更接近市场行为——实现方发布、用户升级、比例自然迁移。两者共同点是都追求非破坏性兼容：链上用软分叉，闪电上用奇偶位与 TLV。理解这一点，就不会用主链治理的期待去衡量闪电：没有强制激活时刻，只有渐次的可用性边界。也解释了为什么闪电的某些功能在不同实现间推进速度差异明显：协商表只保证谈得拢，不保证谈得快。