This article is also available in English.

В части 0 посмотрим, зачем это надо. В части 1 обсудим поверхностно общую идею платежных каналов, Lightning Network и проблемы. В части 2 введем необходимые строительные блоки. В части 3 наконец-то опишем более строго детали работы платежного канала. В части 4 по-быстрому построим Lightning из платежных каналов, расскажем про критику и комиссии. В части 5 немного подытожим.

Дисклеймер. Я сознательно опускаю/упрощаю некоторые технические моменты. А еще я не эксперт, и могу банально ошибаться.

0. Зачем?

Блокчейн биткоина — это своего рода децентрализованная база данных, в которой сохраняются все транзакции сети. При этом “все транзакции” — это довольно фундаментальная часть определения протокола. Чтобы система была по-настоящему децентрализованной и чтобы при этом не допустить ни одной ошибки, нужно, чтобы тысячи узлов сети перепроверяли и сохраняли все транзакции.

Это, разумеется, совсем не способствует масштабируемости: блокчейн занимает десятки гигабайт на диске, блоки переполнены, комиссии растут, люди ругаются и форкают биткоин. Поэтому в данный момент активно разрабатываются альтернативные решения. Одним из таких решений являются Lightning Network (далее LN).

1. Идея

Идея решений второго уровня (second layer solutions), к которым и относится LN, звучит довольно просто.

? Вместо того, чтобы записывать и верифицировать все транзакции на блокчейне, давайте будем проводить большую часть платежей вне сети (off-chain), а на главный блокчейн будем время от времени по желанию синхронизировать балансы и разрешать на нем конфликты. А работать это будет как всегда с помощью криптомагии.

Звучит интригующе, но совсем непонятно как…

1.1. Платежный канал

Начнем с того, как можно упростить жизнь двум людям, Алисе и Бобу, которые часто расплачиваются между собой. Предлагается следующая схема.

1. Алиса и Боб отправляют депозиты на адрес, который управляется ими совместно с помощью двух приватных ключей.
2. Каждый из них создает специальную транзакцию — смарт-контракт (да, в биткоине есть смарт-контракты, об этом в следующей части). Эта транзакция корректна, но пока не записывается в блокчейн.
3. Изначально транзакции содержат информацию о том, что Алиса и Боб могут забрать свои депозиты обратно.
4. Когда Алиса расплачивается с Бобом, они по обоюдному согласию обновляют информацию в этих транзакциях. Алиса соглашается получить меньше изначального депозита, Боб — больше. По сути эти транзакции представляют собой долговые обязательства (IOU, I owe you). Но в отличии от большинства банковских долговых обязательств, LN платежи 100% обеспечены и могут быть реализованы в любой момент.
5. Так они могут обмениваться небольшими суммами (в пределах их депозитов) друг с другом, хоть до бесконечности.
6. В какой-то момент любая сторона может решить рассчитаться окончательно. Тогда Алиса (или Боб) просто записывают одну финальную транзакцию в главный блокчейн и получают суммы депозитов с учетом всех промежуточных платежей.

Пункты 1–3 в этой схеме называются открытием платежного канала (payment channel, канал микроплатежей). Пункты 4 и 5 — использованием канала. Пункт 6—закрытием платежного канала.

? В блокчейн записывается всего две транзакции: перечисление депозитов для открытия канала и финальная транзакция (закрытие канала). Все промежуточные платежи осуществляются без синхронизации с блокчейном, поэтому проходят они бесплатно и мгновенно.

1.2. Сеть платежных каналов

Сами по себе платежные каналы между двумя людьми — вещь не особо полезная. В конце концов, с большинством людей мы не проводим частых регулярных транзакций. Но…

? Когда платежные каналы выстраиваются в сеть, появляется возможность проводить платежи между любыми участниками, между которыми есть путь в графе этой сети (даже если они не связаны напрямую). Это и есть основная идея Lightning Network.

В принципе, аналогично протоколу TCP, простому человеку достаточно иметь всего один открытый канал, чтобы проводить транзакции с кем угодно.

Конечно, нужно еще искать оптимальные пути между двумя людьми, и еще нужно как-то мотивировать участников обрабатывать чужие платежи. Но начнем с основной проблемы: с проблемы доверия.

1.3. Проблема доверия

Как часто бывает в криптографии, систему платежных каналов легко себе представить, если все стороны доверяют друг другу. Нет необходимости городить огород с депозитами, ключами, специальными транзакциями. Можно просто записывать, кто кому сколько должен.

Дело за малым: понять, как можно реализовать канал платежей и сеть этих каналов без доверия. Основных проблем будет три.

1. Оба депозита от Алисы и Боба хранятся на общем кошельке. Если Боб откажется подписывать транзакции, то как Алисе вернуть свой депозит?
2. В процессе расчетов создается много версий долговых обязательств. Предположим, что в основном Алиса платит Бобу. Тогда в финальной версии транзакции Боб получает больше своего депозита, а Алиса — меньше. Но Алиса может схитрить и самовольно записать в блокчейн самую первую валидную версию транзакции, как будто Боб никогда и не получал денег. Что тогда делать Бобу?
3. Если Алиса и Боб передают деньги по сети каналов через Витю, то как они могут убедиться, что Витя действительное передаст деньги, а не заберет их себе?

Назовем эти проблемы соответственно: “проблема общего депозита”, “проблема последней транзакции” и “проблема посредника”.

Все перечисленные выше проблемы решаются с помощью буквально парочки трюков. Но обо всем по порядку: для начала введем несколько необходимых строительных блоков…

2. Смарт-контракты

Биткоин поддерживает простейший язык смарт-контрактов Script. В каждой биткоин-транзакции есть специальное поле, которое содержит скрипт на этом языке. Этот скрипт проверяет, при выполнении каких условий выход транзакции может быть потрачен.

“Потратить выход транзакции A” — это на самом деле более технически корректный способ сказать “потратить деньги с адреса/кошелька K, на который они были зачислены с помощью транзакции A”.

☝ В отличии, например, от этереума, возможности смарт-контрактов биткоина намного более ограничены. Связано это с тем, что Script не является полным по Тьюрингу. Например, в нем нельзя использовать циклы/рекурсию и нельзя создавать переменные (отсутствует память).

Про устройство транзакций и использование скриптов можно почитать по ссылке ниже.

Рассмотрим несколько важных операций этого языка.

2.1. Авторизация

Пожалуй, самая стандартная часть любой транзакции — это проверка подписи. Пусть транзакция A зачисляет средства на некий адрес K. Чтобы дальше потратить деньги с K, нужно доказать наличие ключа. За это отвечает операция OP_CheckSig.

Но при желании, можно также проверить что-нибудь дополнительное. Например, можно проверить, что у человека есть секретное число, хеш от которого равен заданному значению. Для этого нужно две операции: OP_SHA256 (считает хэш) и OP_EqualVerify (проверяет равенство). Зачем это нужно станет понятно в части 4.

2.2. Кооперация

Другой пример простейших смарт-контрактов на биткоине основан на операции OP_CheckMultiSig. Она позволяет тратить средства только при подписании несколькими определенными ключами.

На этом принципе построены так называемые multiple signature кошельки. Примерно как ячейка в банке, которая закрывается на два замка (один ключ у работника банка, второй — у клиента).

2.3. Сроки

С относительно недавних пор биткоин также поддерживает операцию OP_CheckSequenceVerify, которая позволяет тратить средства только через какое-то фиксированное количество блоков.

Например, это позволяет дисциплинировать людей, которые не умеют откладывать деньги. Блокчейн работает лучше любой копилки: если пользователь решил заморозить сбережения на какой-то срок, то они будут гарантировано заморожены.

Но помимо этого сценария, OP_CheckSequenceVerify и другие компоненты активно используются в реализации платежного канала.

3. Реализация канала

Теперь, когда все строительные блоки на месте, можно описать некоторые детали работы платежного канала.

На самом деле разновидностей платежных каналов довольно много, и первую из них предложил еще Сатоши. Я буду примерно ориентироваться на спецификацию, которая называется Poon-Dryja payment channels (по имени главных авторов статьи про Lightning Network).

3.1. Открытие канала

1. Алиса и Боб создают транзакцию/транзакции, которые зачисляют средства на общий адрес-депозит O. Предположим, что X биткоинов зачисляется с кошелька Алисы и Y — с кошелька Боба. Средства с общего депозита можно потратить только при подписании одновременно ключами Алисы и Боба (OP_CheckMultiSig).
2. Первый трюк заключается в том, что они пока НЕ подписывают и НЕ транслируют созданную транзакцию в блокчейн (иначе Боб может обмануть Алису и заморозить её средства навечно).
3. Вместо этого Алиса и Боб создают две новые транзакции возвращения депозитов (соответственно A1 и B1). Входом этих транзакций являются средства с общего депозита (выход транзакции O). Выходов у транзакций два: X уйдет обратно на адрес Алисе, Y — Бобу. На самом деле все немного сложнее, но об это чуть позже.
4. Дальше Боб подписывает транзакцию A1 и передает её Алисе. Алиса подписывает транзакцию B1 и передает её Бобу.
5. Теперь транзакцию зачисления депозитов можно смело транслировать в блокчейн, никто никого не обманет. Если Боб откажется кооперировать, Алиса всегда сможет подписать транзакцию A1, записать её в блокчейн и вернуть свой депозит.

Теперь “проблема общего депозита” решена. Открытие канала можно провести без доверия второй стороне.

☝ Интересный факт. Еще полгода назад (до внедрения SegWit) подписание выхода неподтвержденной транзакции (пункт 4) провернуть было намного сложнее из-за проблемы пластичности транзакций (transaction malleability).

3.2. Использование канала

Платежи внутри канала на самом деле осуществляются переписыванием транзакций A1 и B1 на новые транзакции.

1. Алиса платит Бобу за кружку кофе, которая стоит C.
2. При этом Алиса соглашается, что при закрытии канала она заберет не изначальную сумму X, а X’=(X-C).
3. Боб при этом получит Y’=(Y+C).

Соответственно, новые транзакции A2 и B2 будут выглядеть точно также, как A1 и B1, но с новыми суммами. Любая из сторон может в любой момент закрыть канал, записав последнюю версию транзакции в блокчейн.

Как убедиться, что Алиса не запишет в блокчейн транзакцию A1 вместо транзакции A2? Для этого есть еще один трюк.

1. Каждый раз, когда Алиса и Боб создают новые транзакции, они выбирают одноразовый приватный ключ, который нужен, чтобы забрать депозит (OP_CheckSig).
2. При каждом очередном платеже i, Алиса показывает Бобу предыдущий приватный ключ AK(i-1), и создает новый ключ AKi для новой транзакции. Боб не принимает оплату без предыдущего ключа.
3. Если Боб знает ключ, то он может потратить все деньги Алисы. Но только в случае, если Алиса решит записать неправильную транзакцию в блокчейн.
4. Таким образом, Алиса всегда заинтересована в том, чтобы записывать в блокчейн только самую последнюю транзакцию.

Последняя маленькая модификация. Для того, чтобы у Боба была возможность оспорить транзакцию Алисы и предоставить её ключ, Бобу нужно время. Поэтому Алиса будет получать свой депозит не сразу, а через какое-то количество блоков T (OP_CheckSequenceVerify). Например, через 48 блоков, то есть примерно 8 часов.

Если Алиса подписывает одну из своих транзакций (они уже подписаны Бобом), и транслирует эту транзакцию в блокчейн, то возможны два сценария.

1. Алиса транслирует финальную транзакцию => Боб не знает последнего ключа Алисы AKi. Это корректное закрытие канала, все должны получить свои деньги. Алиса получит их через какое-то время.
2. Алиса пытается записать старую транзакцию вместо финальной => Алиса пытается обмануть Боба. В этом случае Боб знает ключ Алисы и он может воспользоваться им, чтобы получить все средства Алисы. Разумеется, Алиса не заинтересована в этом сценарии.

Итак, “проблема последней транзакции” тоже решена и платежный канал между двумя людьми готов. Теперь также становятся очевидны некоторые плюсы и минусы.

? Преимущества: 1. платежи внутри канала мгновенны и бесплатны, они не создают нагрузки на главный блокчейн. 2. стороны не обязаны доверять друг другу.

? Недостатки: 1. депозиты заблокированы на все время существования канала. 2. обе стороны должны периодически появляться онлайн (как минимум раз в T).

? На самом деле оба недостатка важны для платежных каналов между двумя людьми, но не очень важны в контексте Lightning Network. Первый недостаток перестает быть недостатком, если один платежный канал может быть использован для транзакций с разными людьми.

Второй недостаток отсутствует в LN, так как проверку корректности может совершать любой участник сети (если Вася вскроет мошенничество Алисы, то он разделит с Бобом конфискованные средства Алисы).

4. Lightning Network

4.1. Платежный канал через посредника

Предположим теперь, что Алиса и Боб не имеют открытого канала между собой, но они оба поддерживают открытый канал с Витей. Алиса может безопасно передать деньги Вите, Витя может безопасно передать деньги Бобу.

Но как убедиться, что Витя, получив деньги, действительно передаст их дальше Бобу?

На самом деле идея немного похожа на предыдущий трюк, только вместо одноразовых ключей используется некоторое секретное число.

1. Боб генерирует секретное число S, хэш от этого секретного ключа HS и передает эту информацию Алисе. HS при этом может использоваться как виртуальный чек.
2. Алиса создает транзакцию AV, которая передает деньги Вите, но только в случае, если Витя предоставит секретное число S. Для этого она использует скрипт, который проверяет равенство хэша предоставленного числа и значения HS (тут как раз и используются операции OP_SHA256 и OP_EqualVerify).
3. Витя создает аналогичную транзакцию VB, которая передает деньги Бобу, но только в случае, если Боб предоставит секретное число.
4. Боб видит, что он может получить деньги от Вити, и показывает ему секретное число S.
5. Витя теперь может доказать, что он передал деньги Бобу, и соответственно он может обналичить транзакцию AV.

Тут есть несколько вариантов развития событий.

1. Во-первых, Вите не имеет смысла обманывать Алису. Он не может не передать деньги Бобу, потому что иначе Витя все равно не получит деньги от Алисы.
2. Но Боб может решит обмануть Витю и не передать ему секретное число. При этом он может закрыть канал с Витей и записать транзакцию VB в блокчейн. Но для вывода денег ему все равно придется показать свое секретное число, и тут-то Витя его и узнает.

Тут есть пара нетривиальных нюансов с тем, как выбрать время, в течении которого Алиса, Боб и Витя могут разрешить конфликты. Но эти более технические подробности выходят за рамки этой вводной статьи. Если интересно — гуглите Hash Time-Locked Contracts (HTLCs).

4.2. Маршрутизация

На практике Алиса и Боб могут быть связаны между собой не через одного общего знакомого Витю, а через несколько неизвестных/анонимных посредников по всему миру. Проблема поиска пути в графе узлов сети называется проблемой маршрутизацией.

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

Не вдаваясь в подробности, поиск пути и передача платежей в LN реализуется на основе Onion routing — технологии анонимного распространения информации по peer-to-peer сетям. Именно так, например, работает Tor.

Все децентрализовано, весь трафик зашифрован. Никто не знает, от кого пришли деньги и кому они пойдут дальше. Отсюда еще одно преимущество.

? Преимущества: Lightning Network намного более анонимна, чем сам биткоин. Во-первых, промежуточные транзакции не записываются в публичный блокчейн, их видит всего несколько участников. Во-вторых, даже среди этих участников, только первый и последний человек точно знают, от кого и кому переводятся средства.

4.3. Экономика комиссий

Остается два очевидных вопроса.

Вопрос номер 1: зачем посредникам обрабатывать чужие платежи?

Во-первых, потому что им самим так проще пользоваться LN. Во-вторых, потому что они получают с этого очень маленькую, но все-таки комиссию.

На данный момент сеть поддерживают в основном энтузиасты и комиссия практически нулевая: 1 сатоши, или ~0.01 цента за каждого посредника.

? Пропускная способность каналов — намного менее ценный ресурс, чем размер блока. Каналы открывать просто и недорого. Поэтому комиссии в LN на порядки ниже комиссий в основном блокчейне.

Вопрос номер 2: а как же комиссия за открытие/закрытие канала?

Действительно, эта комиссия может иногда составлять десятки долларов. Таким образом, платежи будут тем выгоднее, чем реже придется открывать/закрывать каналы.

Это мотивирует людей открывать каналы с большими депозитами, и использовать каналы в двух направлениях: не только для исходящих платежей, но и для получения средств.

Пример: я открываю канал, зачисляю туда 1000 долларов, и использую канал только для исходящих платежей. Оборот в канале составит 1000 долларов, примерно 20 долларов уйдет на открытие и закрытие канала. То есть суммарно комиссии составят 2%. Немного лучше, чем виза и мастеркард, но явно больше, чем хотелось бы.

Ситуация кардинально меняется, когда я начинаю использовать Lightning на всю катушку: вкладывать большие суммы и получать деньги через каналы, а не только тратить их. Тогда, в зависимости от пропорции полученных/потраченных денег, канал может быть открыт вечно и комиссии в пределе будут стремиться к нулю.

4.4. Критика

В интернете можно найти большое количество критики решений второго уровня в целом и Lightning Network в частности. Какие-то пункты действительно заслуживают внимания, многие оказываются устаревшими. Приведем несколько примеров.

1. Использование LN приведет к централизации: пользователям будет выгодно подключаться к крупным хабам и эти хабы будут контролировать весь трафик.

Такой риск есть и стоит уделять этому внимание, но риск не очень велик. Во-первых, экономически выгодно и очень просто будет создать новый узел в обход больших хабов. Во-вторых, алгоритмы маршрутизации предусматривают балансировку трафика. В-третьих, пока что такой картины не наблюдается. В будущем, я надеюсь, топология сети будет оптимально выстраиваться алгоритмически.

2. Недостаточная пропускная способность каналов приведет к тому, что LN будет забита, комиссии будут расти, и вскоре ситуация будет такой же, как и в основном блокчейне.

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

3. Эффективная маршрутизация на большом количестве peer-to-peer узлов невозможна. Особенно с учетом сложности открытия новых каналов.

До этих проблем еще очень и очень и очень далеко, а исследования в этом направлении активно ведутся уже сейчас. Что-нибудь придумают.

4. Каналы нужно постоянно открывать и закрывать, комиссии, потраченные на это, будут огромны и LN окажется невыгодной.

На самом деле это проблема из прошлого, про которую почему-то до сих пор говорят. Ранние версии платежных каналов действительно были однонаправленными, а сам канал мог существовать только ограниченное время. Сейчас эти проблемы решены.

5. Для использования LN необходимо быть онлайн.

Опять же, в отличии от ранних реализаций LN, пользователю нет необходимости все время быть онлайн: другие узлы сети проверяют, что два владельца канала не пытаются обмануть друг друга. Действительно необходимо быть онлайн только для отправки и получения платежей, что безусловно является ограничением, но уже намного менее важным.

6. LN не совместимо с холодными хранилищами (cold storage).

Очень правильно замечание. Депозиты платежных каналов храняться в кошельке подключенном к интернету (hot wallet). Для защиты от хакеров необходимо будет очень серьезно подходить к безопасности.

7. LN платежи — это не безопасно.

LN платежи действительно чуть более опасны, чем платежи на основном блокчейне. Но только в одном случае: при успешной 51% атаке на блокчейн биткоина. Риск этого ничтожно мал.

5. LN сегодня

Самое важное, что вам нужно знать: Lightning уже реально работает.

Более тысячи узлов в тестовой сети биткоина и более двухсот узлов (число растет каждый день) в основной сети (mainnet) уже обрабатывают платежи и тестируют различный софт.

Что касается софта, то есть три основных реализации: lnd от Lightning Labs, c-lightning от Blockstream, eclair от ACINQ. Эти команды уже не один год работали совместно, чтобы разработать общий стандарт взаимодействия узлов: Lightning Network Specifications (BOLTs). И вот буквально в конце 2017-ого года они провели полномасштабное успешное тестирование протокола платежей, все три реализации оказались совместимы.

Расплатиться реальными биткоинами используя LN можно пока буквально в трех-четырех онлайн-магазинах. Но это на целых три-четыре магазина больше, чем всего месяц назад, так что это уже большой успех ?

Конечно, момент повсеместного перехода с on-chain биткоин платежей на off-chain платежи еще далеко. Огромную работу еще должны провести разработчики кошельков, платежных шлюзов, бирж, онлайн-магазинов. И, конечно, сами пользователи.

Самое интересное в этой истории, что более быстрые, анонимные и дешевые платежи — это только начало! На подходе еще больше анонимности, атомарные свопы, распределенные биржи и многое-многое другое. Будущее выглядит захватывающе! ⚡

Больше подробностей про LN по ссылкам: 1, 2, 3, 4, 5.

Комментируйте, критикуйте, задавайте вопросы, подписывайтесь! Авторский мини-канал про крипту в телеграме: https://t.me/cryptohodl. Больше об авторе: http://laptev.ch. По вопросам использования материала пишите на d@laptev.ch или https://t.me/x0100.