Lightning Routing — это поиск и использование пути для платежа через сеть Lightning. Путь состоит из платёжных каналов: их участники совместно блокируют средства в Bitcoin и обновляют, какая доля принадлежит каждому. Каналами управляют программы, называемые узлами. Отправитель обычно планирует маршрут на основе публичной информации, данных получателя и прошлых попыток. Однако он не видит всех текущих балансов, поэтому должен оценивать, сработает ли путь, а иногда пробовать другой.
Анна хочет заплатить за кофе, но у неё нет канала с кафе. У неё есть канал с Павлом, а у Павла — ещё один с кафе. Поэтому платёж может пройти через него: в первом канале часть баланса переходит от Анны к Павлу, во втором — от Павла к кафе. Это не передача одной и той же монеты между каналами, а связанные изменения их балансов. Поэтому Павлу нужны собственные доступные средства на той стороне, с которой он платит кафе. Кошелёк или узел отправителя выбирает путь к получателю и готовит инструкции для каждого шага. Получатель сообщает необходимые данные и поддерживаемые функции, иногда сведения о непубличном конечном участке. Промежуточные узлы передают платёж по инструкциям, а не ищут каждый самостоятельно весь путь до цели. [1] [4]
Gossip — способ распространения информации между узлами. BOLT #7 описывает объявления каналов и направленные обновления: базовую и пропорциональную комиссию, разницу сроков CLTV, минимальную и максимальную суммы, признак доступности. Объявленные условия не доказывают, что соседний узел сейчас онлайн или располагает достаточными средствами. Здесь CLTV обозначает срок, заданный высотой блока Bitcoin, то есть его порядковым номером в цепочке, а не точным временем на часах. Разница между сроками оставляет посреднику время отреагировать, если передача платежа остановится. [2]
Общая ёмкость канала не показывает, сколько сейчас может отправить каждая сторона. Отправитель знает собственные каналы, а для остальных использует оценки и историю успехов и ошибок. Поэтому программа учитывает комиссию и вероятность прохождения. Другой платёж тем временем может изменить ликвидность — средства, которые можно отправить в нужном направлении. [4] [5]
Шаги связывают HTLC — условные платежи, для завершения которых нужно раскрыть соответствующий секрет. Если платёж не завершён, после истечения срока средства можно вернуть. Расчёт начинается с суммы для получателя и идёт назад. Каждый посредник должен получить сумму для следующего узла плюс свою комиссию. Входящий HTLC должен истекать достаточно позже исходящего, согласно требуемой разнице CLTV. Более длинный путь может увеличить расходы и время, на которое средства останутся заблокированными при возникновении проблемы. [1] [2]
Onion routing по BOLT #4 использует конструкцию Sphinx: каждый шаг получает отдельно зашифрованные инструкции. Посредник знает предыдущего и следующего партнёра и собственные указания. Сам пакет не раскрывает весь маршрут, его длину или точную позицию узла. Анализ трафика либо сотрудничество узлов всё же могут ослабить приватность. [1]
Канал может временно отказать, комиссия быть слишком низкой, CLTV неверным, а следующий партнёр недоступным или неизвестным. Отправитель получает лишь ограниченные сведения об ошибке. Программа может снизить оценку маршрута, пересчитать его и повторить платёж. Это не денежный штраф узлу, а один результат не является постоянной оценкой надёжности. [1] [4]
Одних соединений недостаточно: каждый шаг должен принять HTLC и иметь достаточно доступных средств в нужном направлении. Часть баланса может быть оставлена в резерве или заблокирована в незавершённых платежах. Технические поля htlc_minimum_msat и htlc_maximum_msat также задают нижнюю и верхнюю границы суммы одного HTLC в этом направлении. Единица msat — тысячная доля сатоши; сатоши является наименьшей единицей суммы в блокчейне Bitcoin. Даже высокий объявленный лимит не доказывает, что необходимая ликвидность доступна прямо сейчас. Поэтому один неподходящий канал может остановить весь маршрут. [2]
Если получатель поддерживает basic MPP, то есть платёж, разделённый на несколько частей, отправитель может разделить общую сумму, обозначенную в протоколе как total_msat, между несколькими маршрутами. Получатель ждёт необходимые части и завершает их вместе. Так используется ликвидность разных каналов, но MPP не создаёт новую. Добавляются HTLC, попытки и, возможно, комиссии. [1]
Route hints в BOLT #11 могут сообщить отправителю сведения о последних необъявленных шагах. Route blinding, используемый в BOLT #12, вместо этого предоставляет зашифрованный конец пути через входной узел — introduction point. Отправителю всё равно нужен пригодный путь к этой точке с соблюдением общих условий комиссий и CLTV. Лучшая приватность не гарантирует доставки. [3] [6] [1]
При обычной оплате поиском маршрута занимается кошелёк. Следующие подробности полезны прежде всего операторам узлов и при выяснении причин повторяющихся проблем. Запишите программу и версию, сумму, максимальную комиссию и предел CLTV, число попыток, использованные маршруты, время завершения и точную причину ошибки. Сравнивайте одну пару узлов в близкое время. Успех описывает конкретный платёж при конкретном состоянии сети, а не постоянную глобальную оценку. [4] [5]
Для полной картины прочитайте эту статью вместе с Lightning Network, HTLC, Ликвидность Lightning, Payment Channel, Bitcoin, Inbound Liquidity. На эту статью также ссылаются HTLC, Ликвидность Lightning, BOLT 12, Inbound Liquidity.