Lightning Network — протокол второго уровня поверх Bitcoin, который позволяет проводить мгновенные платежи с минимальными комиссиями, не загружая основной блокчейн. Транзакции проходят между узлами через двусторонние платёжные каналы, а в блокчейн попадают только две записи: открытие и закрытие канала. Всё, что происходит между ними, остаётся вне цепи.
Блокчейн Bitcoin обрабатывает порядка 7 транзакций в секунду, а время подтверждения блока составляет в среднем 10 минут. Для повседневных платежей — кофе, подписки, микроплатежи — это неприемлемо. Комиссия в периоды высокой нагрузки может превышать сумму самого платежа.
Lightning решает обе проблемы: платежи проходят за доли секунды, а комиссия составляет доли цента, потому что в блокчейн записываются только две транзакции на канал, независимо от числа платежей внутри него.
Канал — это мультиподписная транзакция (2-of-2 multisig), которую два участника создают совместно. Каждый вносит свою долю, и эти средства блокируются на общем адресе.
Каждый платёж внутри канала — это не транзакция в блокчейне, а обмен подписанными commitment transactions. Эти транзакции описывают, как разделить средства канала между участниками на текущий момент.
Пример: Алиса отправляет Бобу 0.01 BTC. Они оба подписывают новую commitment transaction, по которой Алисе причитается 0.09 BTC, а Бобу — 0.11 BTC. Старая commitment transaction становится недействительной благодаря механизму revocation: каждый участник передаёт другому секрет (revocation secret), который позволяет оспорить попытку закрыть канал по устаревшему состоянию.
Закрытие бывает двух типов:
Прямой канал существует не между каждой парой участников. Чтобы отправить платёж тому, с кем нет прямого канала, используется механизм HTLC (Hashed Time-Lock Contract).
Это гарантирует атомарность: либо платёж проходит целиком по всему маршруту, либо не проходит вообще. Ни один промежуточный узел не может потерять средства.
Каждый узел Lightning знает о каналах в сети через gossip-протокол: узлы обмениваются объявлениями о каналах и обновлениями политик маршрутизации. На основе этих данных строится граф сети.
Отправитель использует алгоритм поиска пути по графу (обычно вариацию Дейкстры или A*), учитывая:
Если первый найденный маршрут не сработал (например, на одном из каналов не хватило ликвидности), отправитель пробует альтернативный путь. Современные реализации поддерживают multi-path payments (MPP): один платёж разбивается на несколько частей, которые идут разными маршрутами.
Каждый промежуточный узел видит только предыдущий и следующий хоп в цепочке. Он не знает, кто отправитель и кто конечный получатель. Это реализовано через onion-пакет, аналогичный Tor: каждый слой шифрования раскрывается только на соответствующем узле.
Главная практическая проблема Lightning — управление ликвидностью.
Если вы открыли канал на 0.1 BTC и потратили 0.09, ваша исходящая ликвидность — 0.01 BTC, а входящая — 0.09. Чтобы получать платежи, нужна входящая ликвидность.
Когда ликвидность смещается в одну сторону, узел может выполнить ребалансировку: отправить средства через кольцевой маршрут обратно себе, чтобы восстановить баланс. Это стоит комиссию, но дешевле закрытия и повторного открытия канала.
Средства в канале защищены так же, как средства на мультиподписном адресе в блокчейне. Однако если контрагент попытается закрыть канал по устаревшему состоянию, у вас есть ограниченное время на оспаривание. Поэтому:
Если вы потеряете данные канала (например, при потере телефона), вы не сможете доказать актуальное состояние. Кошелёк должен поддерживать бэкап состояния каналов. Некоторые реализации автоматически сохраняют зашифрованный бэкап при каждом обновлении.
Если вы публикуете устаревшую commitment transaction (случайно или из-за потери данных), контрагент имеет право забрать все средства канала как штраф за попытку мошенничества. Это не баг, а механизм защиты протокола.
Существует несколько реализаций Lightning-узлов:
Для обычных пользователей доступны кошельки, которые управляют каналами автоматически: Phoenix, Breez, Muun. Они абстрагируют сложность открытия каналов и управления ликвидностью.
Зачем нужен второй уровень
Блокчейн Bitcoin обрабатывает порядка 7 транзакций в секунду, а время подтверждения блока составляет в среднем 10 минут. Для повседневных платежей — кофе, подписки, микроплатежи — это неприемлемо. Комиссия в периоды высокой нагрузки может превышать сумму самого платежа.
Lightning решает обе проблемы: платежи проходят за доли секунды, а комиссия составляет доли цента, потому что в блокчейн записываются только две транзакции на канал, независимо от числа платежей внутри него.
Платёжный канал: механика открытия и работы
Канал — это мультиподписная транзакция (2-of-2 multisig), которую два участника создают совместно. Каждый вносит свою долю, и эти средства блокируются на общем адресе.
Открытие канала
- Алиса и Боб создают транзакцию финансирования (funding transaction), которая отправляет, например, 0.1 BTC на мультиподписный адрес.
- Эта транзакция записывается в блокчейн Bitcoin.
- С этого момента канал считается открытым.
Обновление баланса внутри канала
Каждый платёж внутри канала — это не транзакция в блокчейне, а обмен подписанными commitment transactions. Эти транзакции описывают, как разделить средства канала между участниками на текущий момент.
Пример: Алиса отправляет Бобу 0.01 BTC. Они оба подписывают новую commitment transaction, по которой Алисе причитается 0.09 BTC, а Бобу — 0.11 BTC. Старая commitment transaction становится недействительной благодаря механизму revocation: каждый участник передаёт другому секрет (revocation secret), который позволяет оспорить попытку закрыть канал по устаревшему состоянию.
Закрытие канала
Закрытие бывает двух типов:
- Кооперативное — обе стороны подписывают финальную транзакцию, которая распределяет средства согласно последнему балансу. Это самый быстрый и дешёвый вариант.
- Некооперативное (принудительное) — одна из сторон публикует последнюю подписанную commitment transaction в блокчейн. Вторая сторона получает время (обычно 24 часа — параметр
to_self_delay) на проверку: если опубликована устаревшая транзакция, она может оспорить её с помощью revocation secret и забрать все средства канала.
HTLC: как платёж проходит через несколько узлов
Прямой канал существует не между каждой парой участников. Чтобы отправить платёж тому, с кем нет прямого канала, используется механизм HTLC (Hashed Time-Lock Contract).
Принцип работы HTLC
- Получатель генерирует случайный секрет (preimage) и вычисляет его хеш.
- Хеш передаётся отправителю через инвойс.
- Отправитель создаёт цепочку HTLC-контрактов через промежуточные узлы. Каждый контракт содержит одинаковый хеш и таймаут, причём таймаут уменьшается с каждым хопом.
- Когда получатель раскрывает preimage, чтобы забрать платёж, этот секрет распространяется обратно по цепочке, и каждый промежуточный узел получает свою комиссию.
- Если preimage не раскрыт до истечения таймаута, все HTLC откатываются и средства возвращаются отправителю.
Это гарантирует атомарность: либо платёж проходит целиком по всему маршруту, либо не проходит вообще. Ни один промежуточный узел не может потерять средства.
Маршрутизация: как находится путь
Каждый узел Lightning знает о каналах в сети через gossip-протокол: узлы обмениваются объявлениями о каналах и обновлениями политик маршрутизации. На основе этих данных строится граф сети.
Алгоритм поиска маршрута
Отправитель использует алгоритм поиска пути по графу (обычно вариацию Дейкстры или A*), учитывая:
- Ёмкость каналов — маршрут должен быть способен пропустить нужную сумму.
- Комиссии промежуточных узлов — каждый узел задаёт базовую комиссию и процентную ставку.
- Надёжность узлов — некоторые реализации учитывают историю успешных и неудачных попыток.
Если первый найденный маршрут не сработал (например, на одном из каналов не хватило ликвидности), отправитель пробует альтернативный путь. Современные реализации поддерживают multi-path payments (MPP): один платёж разбивается на несколько частей, которые идут разными маршрутами.
Приватность маршрутизации: onion-маршрутизация
Каждый промежуточный узел видит только предыдущий и следующий хоп в цепочке. Он не знает, кто отправитель и кто конечный получатель. Это реализовано через onion-пакет, аналогичный Tor: каждый слой шифрования раскрывается только на соответствующем узле.
Ликвидность: ключевое ограничение сети
Главная практическая проблема Lightning — управление ликвидностью.
Входящая и исходящая ликвидность
- Исходящая ликвидность — сколько вы можете отправить. Определяется вашей долей в канале.
- Входящая ликвидность — сколько вы можете получить. Определяется долей контрагента.
Если вы открыли канал на 0.1 BTC и потратили 0.09, ваша исходящая ликвидность — 0.01 BTC, а входящая — 0.09. Чтобы получать платежи, нужна входящая ликвидность.
Ребалансировка
Когда ликвидность смещается в одну сторону, узел может выполнить ребалансировку: отправить средства через кольцевой маршрут обратно себе, чтобы восстановить баланс. Это стоит комиссию, но дешевле закрытия и повторного открытия канала.
Ограничения и проблемы сети
| Ограничение | Суть |
|---|---|
| Ёмкость канала | Максимальная сумма, которую можно держать в одном канале. Ограничена размером funding transaction |
| Ликвидность | Нельзя отправить больше, чем позволяет исходящая ликвидность конкретного канала |
| Онлайн-требование | Узел должен быть в сети для приёма платежей. Оффлайн-узел не получит входящий платёж |
| Приватность | Несмотря на onion-маршрутизацию, анализ графа каналов может раскрыть информацию об участниках |
| Централизация ликвидности | Крупные узлы (хабы) концентрируют значительную долю ликвидности, создавая точки отказа |
| Максимальный размер платежа | Ограничен ёмкостью каналов на маршруте; для крупных сумм нужен прямой канал или несколько каналов |
| Спам и мусорные каналы | Злоумышленники могут открывать каналы с нулевой ликвидностью, загрязняя граф |
Безопасность: что нужно знать пользователю
Хранение средств в канале
Средства в канале защищены так же, как средства на мультиподписном адресе в блокчейне. Однако если контрагент попытается закрыть канал по устаревшему состоянию, у вас есть ограниченное время на оспаривание. Поэтому:
- Кошелёк должен быть в сети или использовать watchtower — сервис, который мониторит блокчейн и автоматически оспаривает мошеннические закрытия.
- Не стоит держать в канале больше, чем вы готовы потерять при потере доступа к устройству.
Резервное копирование состояния канала
Если вы потеряете данные канала (например, при потере телефона), вы не сможете доказать актуальное состояние. Кошелёк должен поддерживать бэкап состояния каналов. Некоторые реализации автоматически сохраняют зашифрованный бэкап при каждом обновлении.
Риски при принудительном закрытии
Если вы публикуете устаревшую commitment transaction (случайно или из-за потери данных), контрагент имеет право забрать все средства канала как штраф за попытку мошенничества. Это не баг, а механизм защиты протокола.
Практические реализации
Существует несколько реализаций Lightning-узлов:
- LND (Lightning Network Daemon) — от Lightning Labs, написан на Go. Одна из самых распространённых реализаций.
- Core Lightning (CLN) — от Blockstream, написан на C. Ориентирован на гибкость и расширяемость через плагины.
- Eclair — от ACINQ, написан на Scala. Используется в мобильных кошельках.
Для обычных пользователей доступны кошельки, которые управляют каналами автоматически: Phoenix, Breez, Muun. Они абстрагируют сложность открытия каналов и управления ликвидностью.
Сравнение с ончейн-транзакцией
| Параметр | Ончейн | Lightning |
|---|---|---|
| Скорость | ~10 минут на подтверждение | Мгновенно (доли секунды) |
| Комиссия | Зависит от загрузки мемпула | Доли цента |
| Приватность | Все транзакции публичны | Видны только открытие и закрытие канала |
| Доступность | Не требует онлайн | Узел должен быть в сети для приёма |
| Максимальная сумма | Не ограничена протоколом | Ограничена ликвидностью каналов |
| Обратимость | Необратима | Необратима после раскрытия preimage |
Когда Lightning не подходит
- Крупные переводы — если сумма превышает доступную ликвидность на маршруте, проще отправить ончейн.
- Получение без онлайн — если получатель не может держать узел в сети, он не получит платёж (хотя некоторые кошельки решают это через доверенные сервисы).
- Максимальная приватность — ончейн-транзакция через CoinJoin может обеспечить более высокий уровень анонимности, чем Lightning с анализом графа.
- Первое получение — новому пользователю нужна входящая ликвидность, которую кто-то должен обеспечить. Это создаёт начальный барьер входа.
