闪电通道的链上手续费谁说了算：update_fee 的单声道规则

一、费率在通道开张那天就写进了合同

闪电通道的每一方手里都攥着一份承诺交易，谁需要终止合作，谁就能把它 broadcast 上链，按当前余额分配结算双方份额。这份交易将来要花多少链上手续费，不是等到真出事再临时凑——开通道时的 open_channel 与 accept_channel 协商里就携带了 feerate_per_kw 字段，含义是每 1000 个权重单位支付多少聪，承诺交易与 HTLC 交易都按它定价。麻烦在于这个数字会随着链上手续费市场水涨船高而失效：通道安静运行半年后，当初合适的费率可能已经让承诺交易在内存池里躺上好几天。

二、改价是单声道：只有付钱的人能开口

BOLT 2 为这条更新链路定下的规则像一部只有播音员的电话：负责支付比特币手续费的一方——通常是开通道时出资的 funder——应该持续发送 update_fee 消息，保证承诺交易以足够的边际及时进块；不负责出钱的另一方则被明确禁止发送 update_fee。有人把这读成双方地位不平等，其实它只是把责任钉死：谁付这笔钱，谁负责报价，估错价的后果也由谁承担。接受方虽然不能直接改数字，但可以在下次开通道时通过参数协商表达偏好，那是另一条链路的事。

三、对面报了一个离谱数字怎么办

收方对 update_fee 手握两条否决线，都写在协议文本里：如果新费率低到难以及时处理，或者高得没有道理，接收节点都应该让通道失败。前半条保护通道整体的可用性——承诺交易迟迟进不了块，HTLC 超时与强制关闭的连锁反应远比调一次费率麻烦；后半条防的是失控的费率估算器或恶意实现，把本该留给双方的余额烧给矿工。实现层面的排障记录里，fee too high 与 fee too low 是两类常见断通道原因，看到它们先对照当日的链上费率再看通道状态。

四、单位陷阱：每千权重不是每千虚拟字节

feerate_per_kw 的单位是每 1000 权重单位（weight），而权重是虚拟字节的四倍，所以这个字段里的数字恰好等于大众熟悉的每千虚拟字节费率的四分之一。把一个普通的手续费估算器的输出原样塞进这个字段，等于把承诺交易费率无声地抬高四倍：轻则白付矿费，重则触发对面那条约费率高得没有道理的否决线，通道直接报废。闪电生态大量付款与通道故障帖的根源，就是这一处换算被想当然。

五、它管不到开通道那笔钱，也管不到关通道

update_fee 的作用域要划清楚：它只更新双方手里承诺交易与 HTLC 交易的费率设定。开通道那笔出资交易的费用在广播前就已由 funder 定死，不在这条更新链路上，费用不足要靠对开通道交易做费用爬坡；协商关闭时的共同关闭交易也有单独的费用谈判回合。厘清边界之后，一个常见困惑就有了解释：为什么我给通道加了费、开通道交易还是卡在内存池——因为它们压根不是同一笔待确认交易。

本文只讲协议机制，不构成投资建议；涉及通道参数的任何调整，请先在小额通道上完整演练一遍。

六、从消息语义到排障现场

把协议条文翻译成实现层面的动作，能省掉很多来回。收方在收到 update_fee 时并不立即采用新数字：它要把新费率折进下一轮承诺交易的重新协商，确认这笔费率足以覆盖未来的 HTLC 交易，再在 revoke_and_ack 与 commitment_signed 的交替中把新状态定下来；发方在确认对面接受前，也不能单方面认定这笔钱已经谈妥。所以调一次费率的实质，是双方各自重排一整套未来可能上链的交易，不是改一个配置项。理解这一点，才能看懂排障记录里那条规律：update_fee 引发的通道故障往往不是当场出现，而是延后到对方重启、补状态或者链上费率剧烈波动之后才爆发。另一条实践常识是把它和锚定输出机制对照着记：老式通道的承诺交易费用靠 update_fee 单独维持，采用锚定输出的通道则把费用留给链上阶段临时追加，两条路线解决的是同一个问题——通道开得太久，签约那天估的费率迟早过时。