Как работает Lightning Network: каналы, invoice и ликвидность платежа

В канале лежит bitcoin, а не «монета Lightning»

Канал начинается с funding transaction в Bitcoin. Два участника закрепляют средства в выходе, который тратится по согласованным условиям, и заранее держат подписанные варианты расчёта. Пока канал работает, им не нужно публиковать новое распределение после каждого платежа: они заменяют прежнее состояние более свежим.

Для пользователя мобильного кошелька эта механика может быть полностью скрыта. Одни приложения управляют каналами на устройстве, другие подключают пользователя к инфраструктуре провайдера, третьи хранят баланс кастодиально. Одинаковая кнопка Lightning не отвечает, кто контролирует ключи и кто обязан оставаться онлайн — это определяется архитектурой кошелька.

Ёмкость канала не равна сумме, которую можно отправить в любую сторону

Представим канал на 500 000 sat. Если его полностью открыл ваш узел, в начале почти вся usable liquidity находится на вашей стороне: вы можете отправлять, но ещё почти не можете получать через этот канал. После платежа 120 000 sat часть баланса перемещается к peer — outbound liquidity уменьшается, inbound увеличивается.

Числа упрощены: реальный spendable balance учитывает channel reserve, fees и незавершённые HTLC. Но направление принципиально. Поэтому сообщение insufficient liquidity не обязательно означает, что кошелёк пуст. Возможно, подходящей суммы нет в нужном направлении по всему найденному маршруту.

Отправителю не нужен прямой канал с магазином

Lightning образует сеть связанных каналов. Узел отправителя строит route через промежуточные nodes, учитывая объявленные fees и timelocks. При этом фактическое распределение balance внутри публичного канала не публикуется в network graph, поэтому подходящий на карте путь может оказаться без достаточной направленной ликвидности.

Платёж защищается цепочкой hash time-locked contracts — HTLC. Получатель раскрывает preimage, соответствующий payment hash, и это позволяет каждому hop забрать входящий платёж при передаче следующему. Если условие не выполнено до timeout, обязательства можно отменить по правилам протокола. Промежуточному узлу не нужно доверять всю сумму или знать полный маршрут.

Onion routing ограничивает информацию каждого hop: он получает инструкции о следующем участнике, но не видит весь путь как открытый список. Это улучшает privacy, однако BOLT 4 отдельно не обещает анонимность от любого наблюдателя — сопоставление по времени, суммам и сетевому трафику остаётся отдельной моделью угроз.

Invoice — это запрос на конкретный платёж, а не вечный адрес

Классический BOLT 11 invoice кодирует сеть, payment hash, timestamp, подпись и дополнительные поля. В нём может быть сумма, описание, expiry и routing hints. Кошелёк обязан проверить формат и подпись, а пользователь — получателя, сумму и назначение до подтверждения.

Expired invoice лучше не оплачивать повторным использованием старой строки: запросите новый. Если amount не зафиксирован, интерфейс должен явно предложить ввести его. Строка, начинающаяся похоже на Lightning request, не должна вручную редактироваться — checksum и signature защищают точную структуру запроса, а не вашу интерпретацию текста рядом.

Что меняется от сканирования QR до settled

Если route не найден, средства не обязаны покидать канал. Приложение может повторить попытку по другому пути, разбить платёж на части или вернуть ошибку. Точное поведение зависит от реализации кошелька, поэтому полезно сохранить invoice и payment status, но не отправлять второй платёж вслепую после неопределённого ответа интерфейса.

У Lightning есть routing fee и две возможные on-chain комиссии

Маленький routing fee не гарантирует дешёвое владение собственным каналом. Если пользователь часто открывает и закрывает каналы в периоды дорогого blockspace, on-chain расходы могут превысить стоимость внутренних платежей. И наоборот, кастодиальный сервис способен скрыть channel management, но тогда пользователь принимает его правила доступа и хранения.

Ошибка маршрута не похожа на failed Bitcoin transaction

У обычного Lightning payment может не быть отдельного публичного txid в Bitcoin. Поэтому просьба «пришлите hash перевода» должна уточнять тип операции: payment hash и preimage относятся к Lightning, а funding или closing txid — к on-chain каналу. Эти идентификаторы доказывают разные события.

Закрытие канала возвращает итог в Bitcoin

При cooperative close оба peer согласуют closing transaction и распределяют средства по последнему состоянию. При force close один участник публикует commitment transaction самостоятельно. Для его локального выхода BOLT 3 предусматривает задержку, чтобы вторая сторона могла отреагировать на публикацию отозванного состояния.

Force close — не кнопка мгновенного вывода. Он использует blockspace, timelocks и должен быть корректно отслежен программой узла или совместимым recovery-механизмом. Конкретный срок нельзя переносить с одного кошелька на все реализации: его определяют параметры канала и тип выходов.

Пять вопросов к Lightning-кошельку важнее красивого QR

Lightning полезен именно как платёжный слой: он экономит место в блоках, ускоряет повторяющиеся небольшие расчёты и оставляет Bitcoin механизмом окончательного закрытия. Но скорость появляется благодаря каналам и liquidity management. Понимание этой границы помогает отличить нормальную route failure от проблемы с bitcoin, кошельком или получателем.