Inbound Liquidity

彼得经营一家咖啡馆，接受 Lightning Network 付款。他的节点，也就是处理付款的软件，明明显示有资金，顾客却付不了款。缺少入站流动性可能是原因之一。支付通道是两个节点关于所存入比特币如何分配的约定。彼得的一侧叫 local balance，对手方的一侧叫 remote balance。收款时，一部分价值从对手方转到彼得这边。要完成这种转移，对手方必须有可转移的资金。但 remote balance 仍属于对手方；获得收款能力并不是收到别人赠送的比特币，也不是已经赚到营业收入。 [1] [6]

假设通道容量为 1000000 sat。Sat 是 satoshi 的缩写，是比特币的小单位。彼得的 local balance 为 800000 sat，对手方的 remote balance 为 200000 sat。因此，未扣除限制前的收款空间是 200000 sat。若彼得收到 100000 sat，他这一侧升至 900000 sat，对手方剩下 100000 sat。他确实收到了一笔钱，但接下来能收款的空间变小了。为便于理解，例子省略了储备金、费用和下文将解释的待处理 HTLC 付款。如果新通道完全由彼得出资，且没有最初转给对手方的金额，他主要获得的是发送能力。通道开启得到确认，不会自动颠倒这个方向。 [1] [2]

生意好的一天里，彼得一侧的资金不断增加，所用通道的入站空间却逐渐减少。所以，余额上升可能同时意味着更难接收下一笔付款。自建基础设施需要关注可用通道、预期金额、进行中的付款，以及补充流动性的成本。有些钱包会替用户处理部分工作，但底层机制并未消失。彼得甚至可能看不到失败的付款尝试：付款在到达他的节点前就可能中断。已经开具的发票或过期的容量数据，都不能证明钱已到账。 [6]

彼得通过 Lightning 向供应商付款时，所用通道的 local balance 减少，remote balance 增加，从而可能腾出未来的收款空间。Loop Out 的作用类似：通过 swap，也就是支付层之间的交换，他从 Lightning 发送价值，并在链上地址收到比特币，期间不必关闭通道。Loop In 则反过来，把链上资金变成 Lightning 中可以支出的余额。这些操作不会创造比特币。比较结果时，需要算上路由费、交换服务费和链上交易费，还要确认操作确实完成。 [1] [4]

另一种方式是由对手方出资开通连接彼得的通道。彼得获得入站空间，但对手方并没有把资金送给他。Lightning Pool 文档介绍了这类协议的市场：bid 是对流动性的需求，ask 是提供流动性的报价。租期以区块计量，并涉及租赁溢价和其他费用。区块是一组加入区块链的交易；区块链就是比特币的公开交易历史。因此，租期随新区块的产生推进，并不对应固定的小时数。这不是买下整个远端余额。约定租期也不意味着整个期间始终能接收相同金额，因为付款会改变余额分布。协议结束后，也不能假设通道永远可用。 [1] [5]

彼得可能有多个通道，却需要把入站空间放在另一个对手方那里。Circular rebalancing，即循环再平衡，会让自己的付款经一个通道进入网络，再从另一个自有通道回来。发送的通道获得入站空间，接收的通道则消耗入站空间。资金在彼得各个通道的本地侧之间移动，并未产生新资本，而且路由需要付费。这项操作需要一条可用路径。如果所有通道的远端都没有资金，返回的付款便无处进入。仅靠循环再平衡不能解决这个问题。 [1]

部分资金必须作为储备留在通道里，以保证安全运行。其他资金可能暂时被 HTLC 占用，也就是有条件的付款承诺。收款人需要公开一个秘密值，从该值计算出的哈希必须与约定的支付哈希一致，才能领取资金。哈希在这里是用于核对条件的值。如果付款失败，发送方可在期限届满后通过退款路径取回资金。通道管理规范 BOLT 2 还限制最小金额、同时存在的 HTLC 数量及其总价值。因此，并非整个 remote balance 都能用于下一笔付款。把所有远端余额相加，再减去一个统一储备额，并不足以得到答案；必须看每条通道及其当前状态。 [2]

付款通常会经过多个节点。即便彼得能接收，路径前面的某一段也可能离线或资金不足。BOLT 7 规定了 channel_update 消息，节点通过它公布通道某个方向的路由条件，包括费用，以及 htlc_maximum_msat——单个条件付款的金额上限，单位为 msat，即 satoshi 的千分之一。这不是对整条路径实时余额的保证。因此，彼得的入站空间总和并不保证他能从每一个具体付款人那里收到等额资金。收款方的流动性是必要条件之一，而不是全部。 [3]