В Lightning Network маршрут обычно строит отправитель. По публичному gossip-графу, данным получателя и собственным результатам он оценивает путь к цели; в обратном порядке вычисляет сумму, fee и CLTV каждого hop, помещает инструкции в onion packet и после неудачи пробует другой путь. Поскольку граф не показывает текущее распределение балансов, routing — вероятностное решение на основе неполной и быстро меняющейся информации.
Routing начинается у payer: wallet или node выбирает path к payee и задаёт следующий channel каждому посреднику. Получатель сообщает identity, features и, возможно, route hints или blinded paths; публичную часть обычно рассчитывает отправитель.
BOLT #7 распространяет announcements и направленные channel updates с base fee, пропорциональной fee, CLTV delta, минимумом, максимумом и доступностью. Они описывают policy и топологию, но не доказывают online-статус или текущую ликвидность.
Публичный gossip не раскрывает распределение balance. Router объединяет известную локальную ликвидность, capacity, прошлые успехи, ошибки, штрафы и собственный scoring. Теоретически самый дешёвый path не обязательно самый вероятный.
Суммы и expiry строятся назад от payee. Каждый hop получает сумму следующего плюс свою fee и CLTV выше на свою delta; больше hops увеличивают совокупные fees и временной запас.
BOLT #4 применяет onion routing: payer создаёт Sphinx packet с отдельно зашифрованным payload для каждого hop. Посредник знает соседей и свою инструкцию, но не весь path, длину или позицию; анализ трафика и сговор остаются риском.
Временная ошибка channel, недостаточная fee, неверный CLTV или неизвестный next peer возвращают payer ограниченный сигнал. Реализация может штрафовать, пересчитывать и повторять; один результат не описывает channel навсегда.
Каждый hop должен принять HTLC и иметь ликвидность в нужном направлении после резервов, pending HTLC и min/max ограничений. Большая общая capacity или много connections не устраняют один несбалансированный bottleneck.
Basic MPP делит total_msat между несколькими paths, которые получатель исполняет вместе. MPP использует распределённую ликвидность, но добавляет HTLC, попытки и fees и не создаёт capacity.
Route hints BOLT 11 открывают последние приватные hops; BOLT 12 и route blinding передают зашифрованный хвост через introduction point. Payer всё равно должен достичь первой точки и соблюсти суммарные fee и CLTV.
Записывайте реализацию, версию, amount, пределы fee и CLTV, попытки, paths, время и точную ошибку. Сравнивайте ту же пару nodes в близкое время: успех относится к конкретному платежу и состоянию сети. Источники: BOLT #4 — Onion Routing Protocol; BOLT #7 — P2P Node and Channel Discovery; BOLT #11 — Lightning Payment Encoding; Lightning Labs — Pathfinding; LDK — Routing and Route Parameters.
Для полной картины прочитайте эту статью вместе с Lightning Network, HTLC, Ликвидность Lightning, Payment Channel, Bitcoin, Inbound Liquidity. На эту статью также ссылаются HTLC, Ликвидность Lightning, BOLT 12, Inbound Liquidity.