闪电通道一旦开成，链上手续费的定价权就落到了出资方手里：无论谁发起付款，单方面兑现用的承诺交易都由出资方签名并支付比特币网络费。链上费率涨了，出资方就需要一条合法通道告诉对手“以后兑现按新费率算”，这条消息就是 update_fee。它简单到只有一个编号加一个四字节数字，却牵着一段规范亲自标注的竞态。
谁有资格发这条消息
规范划定的权责非常清楚：负责支付比特币手续费的节点应该发送 update_fee，并且要确保当前费率“留有可观余量”地覆盖承诺交易的及时确认；不负责支付的另一方则被明令禁止发送。换句话说，非出资方永远没有调费权——它不能替别人决定给矿工多少钱。如果双方协商了零费承诺特性（zero_fee_commitments），这条消息干脆全面禁用，兑现费用改由锚定输出和付款时的附加输入承担，另一套机制接管。
数字字段叫 feerate_per_kw，单位是每千字重的聪。承诺交易的大小可以事先估算，于是费率乘估算权重就得出该笔兑现付多少费。
一次调费怎么走完
update_fee 和发放 HTLC 一样是一条“更新”：先进对方视角的承诺交易，被对方对等地确认后再生效。区别在于生命周期——HTLC 有发放、兑现、超时三种终局，而调费永不关闭，旧的费率直接被新的替换。实现通常的做法是持续监控链上费率，跨过阈值就发一次新的更新。
规范没有给“该调到多少”的公式，只要求覆盖及时确认并留余量，具体水位留给实现。但给出了一个防御性约束：在未协商锚定输出的老式通道里，如果调高费率会让我方或对方的尘埃 HTLC 敞口超过上限，发送方可以选择不发甚至判通道失败——因为高费率会把更多小额 HTLC 推过尘埃线，堆积出单方面兑现时付不起的结构性风险。
规范点名的竞态
调费消息在途的窗口里存在一个时序缝隙：接收方在没收到新费率时照常继续发放 HTLC，等它终于确认了这条调费，出资方一方的承诺交易可能已经因为新费率抬高而付不起这么多 HTLC 了。规范的处理方式是承认它：此时该承诺交易的实际费率就低于目标值，费用如何摊按 BOLT 3 的费用支付一节执行。工程上的启示是，调费不是一锤定音的瞬时开关，钱包和节点在这条缝隙里要按最坏情况管理自己的敞口。
一个容易被忽视的不对称
调费的义务结构决定了通道的费用生态：非出资方付了小费让路由优先送达，却管不了兑现那一步链上费够不够；出资方平时不收款也睡不安稳，因为兑现权在别人手里，费率估计陈旧的一方可能在自家承诺交易上吃亏。多数实现因此把调费做成了随链上费率联动的后台任务，而不是等兑现失败再补课的应急动作——这也是闪电节点对比特币费率估算模块有依赖的原因。
快速问答
问：不出资的一方想加急自己的付款，能让对方调费吗？
答：不能靠 update_fee，它只能由出资方发。非出资方想加速兑现，用的是付款时自带的附加费率（付款路径上的 fee 参数或锚定输出方案），两回事。
问：调费会不会打断在途付款？
答：不会撤掉任何已确认的 HTLC，新旧费率的差异只作用于之后各自兑现时手续费的计算。
常见误区
一是把 update_fee 当报价或路由费用消息，它只管链上手续费，与给路由节点的小费无关；二是以为双方都能调费，规范上非出资方发送即违规；三是忽略尘埃敞口检查，在老式通道里无脑拉高费率可能换来对方断链。
风险提示：本文为协议机制科普，不构成任何投资建议；通道费用配置请以实现文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。