Lightning Network

В 2017 году один Bitcoin-перевод мог стоить 50 и занимать часы. Купить кофе за BTC было дороже, чем сам кофе. Казалось, Bitcoin навсегда останется «цифровым золотом» - ценным, но бесполезным для повседневных платежей. А потом появилась Lightning Network, и стало возможным отправить 10 сатоши (меньше цента) за доли секунды с комиссией в тысячные доли цента. Как именно этого добились?

• **El Salvador** (2021) принял Bitcoin как законное платёжное средство - массовые повседневные покупки идут через Lightning (кофе, такси, продукты). Приложение Chivo Wallet обработало миллионы микротранзакций
• **Nostr** (децентрализованная социальная сеть) использует Lightning для «zaps» - мгновенных микроплатежей авторам контента. Вместо лайков - реальные сатоши, пересылаемые за миллисекунды
• **Bitstamp, Kraken, Coinbase** - крупнейшие биржи интегрировали Lightning для мгновенных депозитов и выводов Bitcoin, сократив время с 30-60 минут до секунд

Предварительные знания

• Bitcoin: the UTXO model
• Bitcoin Script: programmable money

Payment Channels

Bitcoin обрабатывает ~7 транзакций в секунду. Visa - ~24 000. Записывать каждую покупку кофе в блокчейн - всё равно что отправлять нотариально заверенное письмо вместо SMS. **Payment channel** решает эту проблему: два участника открывают канал одной on-chain транзакцией и затем обмениваются платежами **мгновенно и бесплатно**, не трогая блокчейн.

Для открытия канала Алиса и Боб создают **funding transaction** - multisig 2-of-2 транзакцию, которая блокирует средства на совместном адресе. Допустим, Алиса вносит 0.5 BTC. Теперь эти средства контролируются обеими подписями.

Каждый платёж внутри канала - это новая **commitment transaction**. Она перераспределяет баланс между участниками, но не публикуется в блокчейн. Обе стороны подписывают новое состояние и **отменяют предыдущее** с помощью revocation keys.

Если Алиса попытается опубликовать **старый** commitment TX (где у неё больше денег), у Боба есть revocation key для этого состояния. Боб может использовать его в течение таймлока и **забрать все средства канала** как штраф. Это делает мошенничество экономически невыгодным.

**Ключевой инсайт:** payment channel использует блокчейн как **арбитражный суд**. Пока обе стороны честны - суд не нужен. Но если кто-то мошенничает - блокчейн обеспечивает справедливость. Это называется **optimistic execution**: предполагаем честность, наказываем обман.

Hash Time-Locked Contracts (HTLC)

Payment channel связывает только двух участников. Но что если Алиса хочет заплатить Кэрол, с которой у неё нет прямого канала? Если у Алисы есть канал с Бобом, а у Боба - с Кэрол, можно **передать платёж через Боба**. Проблема: как гарантировать, что Боб не украдёт деньги?

**HTLC (Hash Time-Locked Contract)** решает эту проблему с помощью двух механизмов: 1. **Hash Lock** - средства можно забрать, только предъявив секрет (preimage), хеш которого совпадает с заданным 2. **Time Lock** - если секрет не предъявлен за определённое время, средства возвращаются отправителю

**Атомарность:** платёж либо проходит **полностью** (все HTLC разрешаются), либо **не проходит совсем** (все HTLC истекают по таймлоку). Невозможна ситуация, когда Боб получил деньги от Алисы, но не заплатил Кэрол - потому что Боб узнает секрет S **только после** оплаты Кэрол.

В реальной Lightning Network цепочка может содержать **до 20 промежуточных узлов**. Каждый HTLC на пути уменьшает таймлок (по умолчанию на 40 блоков ≈ 6.7 часа), поэтому максимальная цепочка ограничена суммарным таймлоком.

Маршрутизация платежей

HTLC объяснил, как безопасно передать платёж через цепочку узлов. Но как **найти** эту цепочку? В сети Lightning Network тысячи узлов и десятки тысяч каналов. Нужен механизм, который построит маршрут от отправителя до получателя.

Lightning использует **source routing** - маршрут выбирает **отправитель**, а не промежуточные узлы (как в IP-сетях). Для этого отправитель должен знать топологию сети. Узлы обмениваются информацией о каналах через **gossip protocol**: каждый узел сообщает соседям о своих каналах, комиссиях и ёмкости.

Для крупных платежей, которые не помещаются в один канал, Lightning поддерживает **MPP (Multi-Part Payments)** - разбиение платежа на части и отправка по разным маршрутам. Например, платёж в 1 BTC может пойти как 0.3 + 0.3 + 0.4 по трём разным путям.

Но если отправитель выбирает маршрут - промежуточные узлы видят, кто кому платит? Нет. Lightning использует **onion routing (Sphinx)**, вдохновлённый Tor. Каждый промежуточный узел знает только **предыдущий и следующий хоп**. Платёж «заворачивается» в слои шифрования - как луковица.

**Проблема маршрутизации** - одна из самых сложных в Lightning. Отправитель знает ёмкость каналов, но не знает **текущее распределение балансов** (это приватная информация). Поэтому маршрут может не сработать, и придётся пробовать альтернативные пути. Современные реализации используют вероятностные модели для оценки успешности маршрута.

Ликвидность и управление каналами

Маршрут найден, HTLC работает, onion routing обеспечивает приватность. Но есть фундаментальная проблема: **ликвидность**. Канал с ёмкостью 1 BTC не означает, что через него можно передать 1 BTC в любом направлении. Ёмкость разделена между участниками, и это распределение постоянно меняется.

Ключевое различие: **inbound capacity** (сколько вам могут заплатить) и **outbound capacity** (сколько вы можете заплатить). Если Алиса открыла канал на 1 BTC с Бобом, у Алисы 1 BTC outbound, но 0 inbound - ей **не могут заплатить** через этот канал, пока она не потратит часть средств.

Когда каналы становятся несбалансированными (вся ёмкость на одной стороне), маршрутизация перестаёт работать. Для решения используют несколько стратегий: - **Circular rebalancing** - отправить платёж самому себе через кольцевой маршрут, чтобы перераспределить балансы - **Submarine swaps** - обмен on-chain BTC на Lightning BTC (и наоборот) без закрытия каналов. Позволяет «долить» ликвидность в канал

Для обычных пользователей и мерчантов управление каналами - сложная задача. Поэтому появились **LSP (Lightning Service Providers)** - профессиональные операторы, которые открывают каналы к пользователям, обеспечивают inbound capacity и маршрутизацию. Примеры: Breez, Phoenix (ACINQ), Voltage.

Протокол **Liquidity Ads** (представлен в спецификации BOLTs) позволяет узлам **объявлять** о готовности предоставить ликвидность за плату. Например: «Я готов внести 0.5 BTC в общий канал за комиссию 500 sat». Это создаёт **рынок ликвидности**, где операторы конкурируют за предоставление входящей ёмкости.

**Масштаб Lightning (2025):** ~15 000 публичных узлов, ~50 000 каналов, ~5 000 BTC общей ёмкости. Через Lightning ежедневно проходят миллионы транзакций с комиссией менее 1 сатоши. Крупнейшие интеграции: Binance, Coinbase, Cash App, Nostr (zaps).

Итоги

• **Payment channels** - два участника блокируют средства в multisig транзакции и обмениваются платежами off-chain. Блокчейн используется только для открытия и закрытия канала - как арбитражный суд, который нужен лишь при споре
• **HTLC** (Hash Time-Locked Contracts) - обеспечивают **атомарные** платежи через цепочку промежуточных узлов. Preimage + убывающие таймлоки гарантируют: либо все получат деньги, либо никто
• **Source routing + onion routing** - отправитель строит маршрут по графу каналов (gossip protocol), а Sphinx-шифрование скрывает полный путь от промежуточных узлов. **MPP** позволяет разбивать крупные платежи на части
• **Ликвидность** - inbound vs outbound capacity определяет, кто может платить и получать. LSP, submarine swaps и Liquidity Ads решают проблему управления ликвидностью для обычных пользователей
• Вспомните вопрос из начала: как отправить доли цента за миллисекунды, если Bitcoin обрабатывает 7 транзакций в секунду? Ответ - **вынести платежи за пределы блокчейна**, сохранив его безопасность через payment channels и HTLC

Связанные темы

Lightning Network строится на базовых примитивах Bitcoin и открывает дорогу к новым возможностям:

• Bitcoin: модель UTXO — Funding transaction создаёт UTXO на multisig-адресе - это фундамент канала. Понимание UTXO необходимо для понимания commitment transactions
• Bitcoin Script — HTLC, таймлоки (CLTV, CSV) и revocation keys реализованы через Bitcoin Script. Ограничения Script определяют возможности Lightning
• Taproot — Taproot делает cooperative close каналов неотличимым от обычной транзакции (приватность), уменьшает размер on-chain данных и открывает путь к PTLCs - улучшенной замене HTLC

Вопросы для размышления

• Payment channel требует, чтобы обе стороны были онлайн для мониторинга мошенничества (старые commitment TX). Как это ограничение влияет на использование Lightning обычными пользователями с мобильных устройств, и какие решения существуют (watchtowers)?
• Source routing означает, что отправитель должен знать топологию сети, но не знает текущие балансы каналов. Как вы думаете, почему балансы каналов не публикуются через gossip protocol, и к каким проблемам это привело бы?
• Submarine swaps позволяют обменивать on-chain BTC на Lightning BTC. Но они требуют on-chain транзакцию, которая стоит дорого. Видите ли вы здесь замкнутый круг, и как LSP и Liquidity Ads пытаются его разорвать?

Связанные уроки

• dist-07-transactions