У канала Lightning два баланса, сумма которых ограничена ёмкостью канала. Доступный локальный баланс образует исходящую ликвидность, доступный удалённый — входящую. Резервы, комиссии транзакции commitment, незавершённые HTLC, правила каналов и доступная ёмкость каждого перехода определяют, сможет ли конкретная сумма действительно пройти маршрутом.
Ёмкость канала — биткоины, заблокированные в финансирующем выходе. Ликвидность — только часть, доступная сейчас в одном направлении. Поэтому канал ёмкостью 1 000 000 sats может иметь почти всё на одной стороне и не передать крупный платёж в обратном направлении. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Исходящая ликвидность — сумма, которую локальный узел может отправить по каналу после учёта резервов протокола, обязательств по комиссии транзакции commitment и незавершённых HTLC. Она уменьшается при платеже или пересылке наружу и увеличивается, когда стоимость поступает от соседа. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Входящая ликвидность — сумма, которую сосед может отправить локальному узлу. Она нужна для получения через этот канал, но изменение платёжного запроса её не создаёт: она должна находиться в удалённом балансе или появиться благодаря операции управления ликвидностью. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Маршрутизированный платёж проходит только тогда, когда у каждого выбранного перехода достаточно доступной ликвидности в нужном направлении и он принимает HTLC согласно правилам комиссий, минимальной и максимальной сумме и временному ограничению CLTV. Один исчерпанный канал может заблокировать в остальном хорошо связанный маршрут. [BOLT #2 — Peer Protocol for Channel Management] [BOLT #7 — P2P Node and Channel Discovery]
channel_reserve_satoshis, комиссии транзакции commitment, anchor outputs, правила dust, max_htlc_value_in_flight_msat, max_accepted_htlcs и уже незавершённые HTLC могут уменьшить сумму для нового платежа. Поэтому баланс кошелька, ёмкость канала и сумма, которую можно немедленно направить по маршруту, — три разных числа. [BOLT #2 — Peer Protocol for Channel Management]
BOLT #7 позволяет объявлять канал и его правила пересылки. Ёмкость можно определить по финансирующему выходу, найденному в цепи; приватное распределение балансов при этом не раскрывается. Отправитель оценивает маршрут по собственной информации, прошлым результатам и попыткам платежей. Публичный обозреватель не может подтвердить, что выбранный маршрут прямо сейчас передаст конкретную сумму. [BOLT #7 — P2P Node and Channel Discovery]
Завершённый платёж перемещает баланс в каждом используемом канале: у отправляющей стороны исходящая ликвидность падает, а входящая растёт; на другом конце происходит обратное. Платёж перераспределяет имеющуюся ёмкость, но не увеличивает общую. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Узлу пересылки для одного и того же HTLC нужна входящая ликвидность в одном канале и исходящая в следующем. Большая общая сумма sats не поможет, если они находятся не в тех каналах или не на тех сторонах. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Полученные платежи, круговая перебалансировка, открытие или закрытие каналов, свопы и splicing могут перемещать ликвидность. Они отличаются комиссиями, следом в цепи, временем, доверием к контрагенту и риском неудачи; ни один метод не создаёт бесплатную ликвидность. Платёж из нескольких частей может объединять маршруты, но всё равно требует достаточной суммарной направленной ёмкости. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Managing Liquidity]
На собственном узле проверьте локальные и удалённые балансы каждого канала, резервы, незавершённые HTLC и запас для комиссий, затем испытайте намеченную сумму. Запишите направление, размер, время и реализацию: ликвидность меняется после каждого платежа и не является постоянной единой оценкой всей сети. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity] [Lightning Labs — Managing Liquidity]
Для полной картины прочитайте эту статью вместе с Lightning Network, Payment Channel, Lightning Routing, Inbound Liquidity, Bitcoin, HTLC. На эту статью также ссылаются Payment Channel, Lightning Routing, Волатильность, Рыночная капитализация.