闪电开通道的报文接力里，最后一步常被忽略：双方把资金交易的签名都换完之后，通道并没有立刻能用。每个节点还要盯着链上那笔资金交易，等它攒够自己认可的确认数，然后向对方发一条 channel_ready；两边都发完，通道才宣布进入正常工作模式。这条消息在旧版规范里叫 funding_locked，改名不是美化，是因为它顺带捎了一件新东西。
开门前先确认钥匙没被熔掉
等待是必要的。资金交易哪怕已经出现在某个区块里，仍可能因区块重组而回滚——尤其是深度只有零到一格的区块。如果一方在交易还可能消失时就开始发放 HTLC，之后对方单方面把没上链的资金状态拿出来兑现，另一边就成了冤大头。所以规范的措辞很谨慎：节点只有在资金交易获得足够确认之后才发送 channel_ready，而实现通常把“足够”做成可配置策略，公共节点和钱包的默认耐心并不一样。
反过来，收不到这条消息的一侧也有明确的等待姿势：开通道报文交换完毕、自己这边确认数已经攒够，通道就进入等对方就绪的状态；久等不来，说明对方的判断和自己不同，或者干脆掉线了，此时通道保持冻结而不是自动作废。
别名：同一条通道的本地门牌
channel_ready 的 TLV 扩展里可以携带 alias 字段：发送方提议一个只在这条连接上使用的短通道编号。它的用途在路由隐私和内部编号管理上——你的节点可以对外用一套与资金交易位置无关的编号，链上分析和图谱工具就少了一个对齐锚点。规范允许同一连接上发送多条带不同别名的 channel_ready，也规定双方各自记自己的提议，互不覆盖。
名字为什么从funding_locked改成channel_ready
早期规范里这条消息叫 funding_locked，语义是“我看到资金交易锁进链了”。后来 TLV 扩展和别名进来，消息的功能从“报告链上事件”扩展成“宣告通道可用”，BOLT 2 于是改名 channel_ready，并注明旧名。读老实现源码和旧日志时，两个名字指同一类型号的消息；新代码里再写 funding_locked 只是历史残留。
别名下的一致性
在没有协商别名的连接上，双方日常用由资金交易位置推出的短通道编号通信，这个编号人人可从链上复算，把节点行为锚定在出点上。别名机制则允许同一条物理通道在不同连接上顶着不同编号说话，图谱工具跨连接对齐节点行为的把手就少了一个。也正因为别名只在连接内生效，规范才放心让它随便提议——链上数据与图谱公告里出现的永远只有标准短通道编号，两套编号的分工从设计之初就没打算合并。
实现之间的一点差异
各家节点软件对“足够确认”的默认值做过不同取舍，公共大节点为对冲重组损失常设得偏保守，钱包端为提升开通道体验趋向更小数值；链上拥挤时这种差异会显形为一方迟迟不就绪、另一方反复重连。遇到通道卡在等待就绪的状态，检查两边确认配置的差值往往比重启网络模块更快见效，它是这个环节里最常见的非故障性原因。
快速问答
问：等确认期间通道算什么状态？钱在哪？
答：资金交易在链上，双方谁也没法单方面花它；此刻任何一方都可以合作关闭，但没有任何 HTLC 能发放，因为通道尚未进入运行态。
问：只收到对方的就绪消息能开始付款吗？
答：不能。规范要求双方都发过之后通道才正常运作，单侧就绪只说明对方已准备好，己方还要等自己的确认数与状态机走完。
常见误区
一是把资金交易上链当成通道可用，跳过确认等待的实现在重组里丢过钱；二是以为就绪消息带金额或余额，它只携带通道编号和可选别名，余额早就在承诺交易里定好了；三是把别名当全网生效的编号，它只在这条 TCP 连接上有意义。
风险提示：本文为协议机制科普，不构成任何投资建议；通道开关涉及真实资金，请遵循所用实现的官方指引。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。