术语表 /闪电网络与 Layer 2
CLTV 到期增量
- CLTV 到期增量是什么？
- CLTV 到期增量是闪电网络节点在转发传入支付前，从该支付的时间锁中减去的区块数，节点会在 gossip 中按通道的每个方向分别公布该数值。
闪电网络路由上的每个转发节点都会收取两项价格：以毫聪计的手续费和以区块计的延迟，CLTV 到期增量就是这项延迟。BOLT 7将其作为16位字段放在 channel_update 消息中，与 fee_base_msat 并列，通道的每一方各自独立公布自己的数值。如果支付卡住，这一叠区块就是您的资金被冻结的时间。
运作方式
CLTV 到期增量由负责转发的节点选定，且只约束该节点的出站方向。
规范的措辞很明确：节点必须把该字段设为它将从传入 HTLC 的 cltv_expiry 中减去的区块数。因此，增量不是截止时间，而是一段差值。节点接受一笔锁定至某个绝对区块高度的支付，自己留下这段增量，再向下一跳提供一笔锁定至该高度减去增量的支付。这段差值就是节点的安全余量：如果下游一跳在最后一刻才结算，节点仍有同样数量的区块可用来向上游索取付款。
每个公开通道带有两个这样的数值，每个方向一个，各自由设定它的节点签名。它们随 channel_update（消息类型258）一起传播，与 htlc_minimum_msat 和两个手续费字段并列。只有将要转发的节点所公布的更新才有意义：在 A 到 B 到 C 到 D 的路由上，付款方使用 B 的更新处理 B 到 C 的一跳，使用 C 的更新处理 C 到 D 的一跳，自己的更新一概不用。
因此，路由是倒推构建的。付款方从目的地出发，以发票要求的最小最终到期值为起点，向回逐跳累加各跳公布的增量，累计总数就成为它交给第一个对等节点的 HTLC 的时间锁。当节点调整价格时，BOLT 7要求它在10分钟内继续接受之前的参数，因为 gossip 不会同时传到每个付款方。
在哪里会遇到它
CLTV 到期增量决定了一笔卡住的闪电网络支付会占用您的余额多久，而 BOLT 7自带的路由示例为两条其他条件相同的路由给出了具体数字。
四个节点构成菱形：A、B、C 和 D，分别公布10、20、30和40个区块，C 要求的最终到期增量为18，规范称之为默认值。A 向 C 发送4,999,999毫聪。经由 B 路由时，A 交给其对等节点5,010,198毫聪，其中10,199是 B 的手续费，第一个 HTLC 在当前区块高度加80时到期：B 这一跳20个区块，C 为18，另有42个区块的填充。经由 D 路由时，同一笔支付的成本为5,020,398毫聪，在当前高度加100时到期。发送方相同，接收方相同，金额相同，风险敞口却多出20个区块。
这42并非随意的冗余。BOLT 7提醒说，如果如实累加各增量来构建路由，中间节点就能推算出自己所处的位置，进而猜出收款对象，因此建议付款方加入一个随机偏移量，其做法是从收款方出发向外遍历图，并累加沿途遇到的增量。规范把这一结果称为 shadow route extension。
除非您运营转发节点，否则这些数值都不由您设定。Phoenix 在本站评测中被称为手机上真正独立的闪电网络节点，它公布的发送价格为0.4%加4聪，而该表定价的是资金，不是区块。
CLTV 到期增量 vs OP_CHECKLOCKTIMEVERIFY
CLTV 到期增量是在 gossip 中公布的路由策略数值，而 OP_CHECKLOCKTIMEVERIFY 是在链上强制执行绝对截止时间的比特币脚本操作码。
两者只共用三个字母，其余几乎毫无相同之处。增量是相对值，完全存在于链下：它不出现在任何脚本中，没有全节点会验证它，设定它的节点可以通过新的 channel_update 修改它。OP_CHECKLOCKTIMEVERIFY 则写入币本身，由每个全节点检查，币一旦存在就无法再编辑。