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 — предложение её предоставить. У аренды есть срок в блоках, премия и другие комиссии. Блок — группа транзакций, добавленная в блокчейн, публичную историю транзакций Bitcoin. Поэтому срок определяется появлением новых блоков, а не точным количеством часов. Это не покупка всего удалённого остатка. Согласованный срок также не означает, что всё время можно будет принять ту же сумму: платежи меняют распределение. После окончания соглашения нельзя предполагать постоянную доступность канала. [1] [5]

У Петра может быть несколько каналов, а входящий запас нужен у другого партнёра. Circular rebalancing, круговая ребалансировка, отправляет его платёж в сеть по одному каналу и возвращает по другому собственному. Отправляющий канал получает входящий запас, принимающий его расходует. Средства переходят между сторонами Петра в каналах, не создавая нового капитала, а маршрутизация стоит комиссий. Нужен доступный путь. Если средств нет на удалённых сторонах всех его каналов, возвращающемуся платежу некуда войти. Одна лишь круговая ребалансировка проблему не устранит. [1]

Часть средств должна оставаться резервом для безопасной работы канала. Другие средства могут временно участвовать в HTLC, условных платёжных обязательствах. Получатель может забрать их, раскрыв секретное значение, из которого вычисляется согласованный платёжный хеш — значение для проверки. Если платёж не проходит, у отправляющей стороны есть способ вернуть средства после истечения срока. BOLT 2, спецификация управления каналами, также ограничивает минимальную сумму, число одновременных HTLC и их общую стоимость. Поэтому весь remote balance может быть недоступен для нового платежа. Недостаточно сложить удалённые остатки и вычесть универсальный резерв: важны конкретные каналы и их состояние. [2]

Обычно платёж проходит несколько узлов. Даже если у Петра есть возможность приёма, более ранний участок может быть недоступен или не иметь средств. BOLT 7 описывает сообщения channel_update, которыми узлы объявляют условия маршрутизации для направления канала. Они содержат комиссии и htlc_maximum_msat — верхний предел отдельного условного платежа в msat, тысячных долях satoshi. Это не обещание актуального остатка на всём пути. Поэтому сумма входящего запаса Петра не гарантирует приём такой суммы от каждого конкретного отправителя. Ликвидность получателя — необходимая часть решения, но не единственная. [3]