Lightning Routing

安娜想付咖啡钱，但她没有与咖啡馆建立通道。她与帕维尔有通道，而帕维尔又与咖啡馆有另一个通道。因此，支付可以经过帕维尔：在第一个通道中，一部分余额从安娜转到帕维尔名下；在第二个通道中，一部分余额从帕维尔转到咖啡馆名下。这并不是同一枚币在通道之间流转，而是各通道的余额发生相互关联的变化。因此，帕维尔在向咖啡馆付款的一侧，必须有自己可用的资金。发送方的钱包或节点选择到达收款人的路径，并为沿途各步准备指令。收款人提供必要的数据及其支持的功能，有时还会提供非公开末段的信息。沿途节点按指令转发支付，而不是各自重新寻找通往终点的完整路径。 [1] [4]

Gossip 是节点之间传播信息的方式。BOLT #7 描述通道公告和分方向的更新，包括基础费用、按金额收取的费用、CLTV 到期差值、最小和最大金额以及可用性标志。已公布的条件并不能证明对方节点此刻在线，也不能证明它有足够资金。这里的 CLTV 指用 Bitcoin 区块高度（区块在链上的位置）表示的期限，而不是钟表上的准确时刻。不同期限之间留出的间隔，让中间节点在转发受阻时有时间作出处理。 [2]

通道的总容量不能说明两端各自现在能发送多少资金。发送方了解自己的通道，对其他通道则依赖估计以及成功和失败记录。因此，软件既考虑费用，也考虑支付通过的概率。与此同时，其他支付还可能改变流动性，也就是能向所需方向发送的可用资金。 [4] [5]

这些步骤通过 HTLC 相互关联。HTLC 是一种有条件的支付，完成支付需要公开对应的秘密值；如果支付未完成，期限过后可以取回资金。计算从收款人应得的金额开始，沿路径反向进行。每个中间节点收到的金额，需要覆盖转给下一节点的金额及自身费用。入站 HTLC 的到期时间必须比出站 HTLC 足够晚，以满足所需的 CLTV 差值。路径越长，可能费用越高，出问题时资金被占用的时间也可能越久。 [1] [2]

BOLT #4 中的 onion routing 使用 Sphinx 结构，为每一步分别加密指令。中间节点知道前后相邻节点以及自己要执行的指令。仅凭这个数据包，它无法得知完整路径、路径长度或自己在其中的确切位置。不过，流量分析或节点之间的串通仍可能削弱隐私。 [1]

通道可能暂时失效，费用可能不足，CLTV 可能不正确，下一节点也可能不可用或未知。发送方只能收到有限的错误信息。软件可以降低某条路径的评分，重新计算后再试。这不是向节点支付罚款；一次结果也不是对其可靠性的永久评价。 [1] [4]

仅有连接还不够：每一步都必须接受 HTLC，并在所需方向上有足够的可用资金。部分余额可能需要保留为储备，或已被未完成的支付占用。技术字段 htlc_minimum_msat 和 htlc_maximum_msat 还规定了该方向上单个 HTLC 的金额下限和上限。msat 是千分之一聪，聪是 Bitcoin 链上最小的金额单位。即使公布的上限很高，也不能证明所需流动性此刻就可用。因此，一个不合适的通道就可能阻断整条路径。 [2]

如果收款人支持 basic MPP，也就是把一笔支付拆成多个部分，发送方可以把协议中标为 total_msat 的总金额拆分到多条路径。收款人等待所需的各部分到齐，再一起结算。这样可以利用分散在不同通道里的流动性，但 MPP 不会创造新的流动性。HTLC 数量和尝试次数会增加，费用也可能增加。 [1]

BOLT #11 中的 route hints 可以补充最后几步未公开通道的信息。BOLT #12 使用的 route blinding 则通过一个入口节点，即 introduction point，提供加密的路径末段。发送方仍需找到通向该入口的可用路径，并满足汇总的费用和 CLTV 条件。更好的隐私并不保证支付能够送达。 [3] [6] [1]

日常付款时，钱包会负责寻找路径。下面这些细节主要适合节点运营者，或用来排查反复发生的问题。记录软件及版本、金额、费用上限、CLTV 限制、尝试次数、使用的路径、完成时间，以及失败的准确原因。比较时，应选择同一对节点和相近的时间。成功率描述的是特定网络状态下的具体支付，而不是永久有效的全网评分。 [4] [5]