公开还是私有:闪电通道靠交换公告签名决定上不上地图 图 1
公开还是私有:闪电通道靠交换公告签名决定上不上地图 · 图 1

闪电网络的付款依赖一张人人都有的通道地图,但地图上的每条边都对应着两个真实的人。问题随之而来:通道是双方私有的金融安排,凭什么广播给全世界?规范给的答案是双重同意——不仅开通道时要表态,公告发生前还要当面交换两份签名,缺任何一份,公告就无法拼出来。

伏笔埋在开通道那一刻

open_channel 消息里有一个 channel_flags,其中一位是 announce_channel。发起开通道时就写好了意愿:置位表示“我同意之后公开”,清零表示“无论发生什么都别公告”。规范在要求里写死了两种命运:标志位没置上、或者通道已经开始关闭流程的一方,禁止发送公告签名消息。个人钱包默认走私有通道,就是靠这个位实现的。

公开还是私有:闪电通道靠交换公告签名决定上不上地图 图 2
公开还是私有:闪电通道靠交换公告签名决定上不上地图 · 图 2

两份签名怎么换

假设双方都愿意公开。通道进入运行态、资金交易攒够防重组的确认后,一方构造出 channel_announcement 的草稿——里面是两个节点的身份键、资金交易的出点、链哈希和短通道编号——然后用自己的节点密钥和比特币密钥分别签好,把两份签名连同短通道编号装进 announcement_signatures 发给对方。这里有个几何细节:公告里的两个节点按压缩公钥的字典序排成 node_id_1 和 node_id_2,谁也不许摆反,签名校验对此零容忍。

收齐对方那份签名后还不算完:规范建议发送方在确认自己与对方都已交换过有效签名、且资金交易至少有六条确认之后,才把组装好的 channel_announcement 排队泛洪给邻居。掉线场景也有补丁:重连后如果发现自己从没收到过对方的签名,应主动补发一次,避免通道永远卡在“双方都想公开、但都在等对方先开口”的僵局。

公告之后发生什么

公告一旦泛洪,这条通道就成为路由节点的候选路径,所有人都能看到两个端点公钥和链上出点,容量却看不见——容量要靠随后两侧的 channel_update 侧写。公开的收益是可路由性和收款入口,代价是资金出点与节点身份被永久绑定进图谱历史。想收回承诺是做不到的:比特币共识里没有撤回公告的指令,规范只能要求节点在通道资金被花掉或检测到关闭后遗忘它;历史版本则会被 gossip 的时间戳淘汰机制慢慢洗掉。

私有通道的收款账

私有不等于收不到款。只要付款方的路线能以任何方式抵达接收节点的某个公开通道入口,最后一段完全可以钻进私有通道完成,只是路由需要接收方配合做路线拼接。这也是闪电付款长期保留接收方参与寻路原因之一。把这条算进来,就能理解为什么对个人钱包来说私有通道的收款更依赖对方善意,而公开通道的吸引力正是在这种结构性弱点面前多了一分自主。

快速问答

问:一方愿意公开另一方不愿意会怎样?

答:签名凑不齐,公告组装不出来,通道继续私有运行,付款功能不受影响,只是外部节点无法把它排进路线。

问:短通道编号是什么的编号?

答:是资金交易所在区块的坐标加上输出序号拼出来的本地无关编号,公告、更新和查询消息都用它指代这条通道,链上出点之外它自己也是检索键。

常见误区

一是以为图谱上的通道都被“允许公开”过一次,其实私有通道的存在解释了为什么所有图谱统计都只是全网真实容量的下界;二是把公告当实时的余额与费率公告,容量信息在公告里根本没有,费率在两侧的更新消息里且可能陈旧;三是觉得公开通道隐私风险为零,它把节点的收款行为、资金规模和在线规律一起暴露给了长期观察者。

风险提示:本文为协议机制科普,不构成任何投资建议;公开与否请结合收款需求与自身隐私模型决定。