Lightning Network: все технические детали

16 0 Новости

ЭкономияСохраненоУдалено 0

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

Как минимум три компании — основанная авторами идеи LN Джозефом Пуном (Joseph Poon) и Тэджем Дрийа (Tadge Dryja) Lightning, а также Blockstream и Blockchain.info — в настоящее время работают над реализацией этой технологии. Однако, кроме вовлеченных в это разработчиков мало кто понимает, как вся эта магия вообще работает. Мы предлагаем своим читателям восполнить этот пробел в своих знаниях.

Чтобы как следует понять концепцию, нужно последовательно изучить все строительные блоки, которы она включает. Для начала давайте разберемся, какие элементы задействованы в создании двунаправленного платежного канала — первой важной составляющей Lightning Network.

Элемент 1: неподтвержденные транзакции

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

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

Черным цветом обозначена подтвержденная транзакция. Синяя транзакция может быть отправлена в сеть Алисой, но только в том случае, если подтверждена предыдущая транзакция. Красная транзакция может быть отправлена в сеть Бобом — с тем же условием: если подтверждена предыдущая транзакция. В данном примере Алиса может в любой момент подписать и транслировать в сеть свою неподтвержденную транзакцию, отправив 2 биткойна Бобу, и лишь после этого Боб сможет подписать свою транзакцию, отправляющую 1 биткойн Кэрол.

Элемент 2: механизм защиты от двойной траты

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

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

Элемент 3: мультиподпись

Третий элемент Lightning Network также прост: это адреса с мультиподписями. Так называют биткойн-адреса, для разблокирования которых необходимо несколько закрытых ключей. Условия разблокирования могут быть самыми разными, например 2 ключа из 3, 15 из 15 и т. д. В Lightning Network часто используются мультиподписи по схеме «2 из 2», т. е., чтобы потратить биткойны, хранящиеся по такому адресу, необходимы две подписи, сгенерированные с помощью двух закрытых ключей.

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

Элемент 4: временные блокировки

Четвертый элемент Lightning Network — это временные блокировки. Они позволяют блокировать биткойны в выходе, чтобы их можно было потратить (включить в следующий вход) лишь спустя какое-то время.

Временные блокировки бывают двух видов: абсолютные, или CheckLockTimeVerify (CLTV), и относительные, или CheckSequenceVerify (CSV). Блокировка CLTV блокирует биткойны до какого-то (более-менее) конкретного момента в будущем: до фактического времени или определенного блока. В CSV вместо этого используется относительное время. Как только выход с CSV записан в блокчейн, должно быть сгенерировано определенное количество блоков, прежде чем эти биткойны можно будет потратить.

В Lightning Network блокировка CSV (обозначенная на рисунке часами) часто используется как задержка.

Элемент 5: хеши и секреты

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

Если коротко, то «значение» или «секрет» — это длинная уникальная строка чисел, которую практически невозможно угадать даже на очень мощных компьютерах. Этот секрет можно «хешировать» — преобразовать в другую строку чисел, или «хеш». Хитрость в том, что любой, кто знает значение, может с легкостью получить его хеш, но обратное невозможно: хеширование — однонаправленная операция.

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

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

Первая задача: двунаправленные платежные каналы

Идея платежных каналов обсуждалась еще до Lightning Network. Безусловно, обычные платежные каналы полезны, но ограничены: они однонаправленны. Ключевая особенность Lightning Network — это двунаправленные платежные каналы «без доверия».

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

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

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

Чтобы открыть канал, Алиса и Боб отправляют на адрес с мультиподписью «2 из 2» по 5 биткойнов. Это и есть «открывающая транзакция». Биткойны по этому адресу можно потратить, только если транзакцию подпишут и Алиса, и Боб.

Кроме того, Алиса и Боб создают секрет (строку чисел) и получают ее хеш.

Далее Алиса немедленно создает из открывающей транзакции новую транзакцию. Это так называемая «транзакция-обязательство» (commitment transaction). С ее помощью Алиса отправляет 4 биткойна себе, а оставшиеся 6 — на второй адрес с мультиподписью. Этот адрес немного необычен. Боб может разблокировать его самостоятельно, но только через 1000 блоков, потому что это адрес с CSV-блокировкой. Или же его может разблокировать Алиса, но только указав секрет, хеш от которого сообщил ей Боб (разумеется, Алиса понятия не имеет, каков этот секрет — она знает только его хеш, — так что она пока не может воспользоваться этой возможностью).

Алиса подписывает транзакцию-обязательство, но не транслирует ее в сеть! Вместо этого она отправляет ее Бобу.

Тем временем Боб делает то же самое, но с обратными параметрами: создает транзакцию-обязательство, отправляя 6 биткойнов себе, а 4 — на новый адрес с мультиподписью. Алиса может разблокировать этот адрес через 1000 блоков, а Боб — с помощью секрета Алисы.

Боб подписывает свою транзакцию-обязательство и отправляет ее Алисе.

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

Теперь и Алиса, и Боб могут подписать и отправить в биткойн-сеть обязательства, которые они получили друг от друга. Если Алиса сделает это, Боб немедленно получит 6 биткойнов. Если это сделает Боб, Алиса получит 4 биткойна. В любом случае тот, кто подпишет и отправит в биткойн-сеть соответствующую транзакцию, должен будет подождать 1000 блоков, чтобы разблокировать адрес с мультиподписью и получить доступ к остальным биткойнам.

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

Обновление канала

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

Прежде всего, они повторяют изложенный выше процесс (за исключением открывающей транзакции — она уже записана в блокчейн). В этот раз Алиса и Боб отписывают себе по 5 биткойнов, а оставшиеся 5 отправляют на адреса с мультиподписью. Требования к этим адресам похожи, но использовать они должны новые секреты. Это означает, что Алиса и Боб сообщают друг другу новые хеши. Они подписывают свои транзакции-обязательства и отправляют их друг другу.

Далее Алиса и Боб передают друг другу свои секреты из первого сценария.

После этого Алиса и Боб могут подписать и отправить в сеть полученные транзакции-обязательства. Тот, кто сделает это, сможет получить свои 5 биткойнов через 1000 блоков, а вторая сторона — немедленно.

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

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

Это означает, что Алиса и Боб экономически заинтересованы в том, чтобы соблюдать правила и транслировать в сеть только транзакции с актуальным состоянием канала.

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

Сеть

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

Однако Алиса не доверяет Бобу и Кэрол — она боится, что, если она отправит 1 биткойн Бобу, тот никогда не заплатит Кэрол или же заплатит, но Кэрол заявит, что не получала никаких денег, и Алиса не будет знать, кто из них говорит правду.

Таким образом, Алиса готова заплатить Бобу 1 биткойн, только если будет уверена, что он, в свою очередь, заплатит Кэрол 1 биткойн. Это возможно благодаря нехитрому криптографическому протоколу.

Когда Алиса хочет отправить 1 биткойн Кэрол, она просит Кэрол создать значение (случайную строку чисел) и сообщить ей его хеш. Она также просит Кэрол уведомить Боба, что он может получить это значение за 1 биткойн. Далее Алиса говорит Бобу, что отправит ему 1 биткойн, если он предоставит ей значение, соответствующее хешу, который она получила от Кэрол. Боб принимает предложение Кэрол и отправляет ей 1 биткойн, а за это получает значение. После этого Боб сообщает значение Алисе. Алиса знает, что Боб купил это значение у Кэрол за 1 биткойн, и компенсирует ему его расходы.

Ну, почти все.

В этом упрощенном сценарии посредник в лице Боба все же должен доверять Алисе и Кэрол. Он должен быть уверен, что Кэрол действительно сообщит ему нужное значение в обмен на 1 биткойн, и он также должен быть уверен, что Алиса на самом деле отправит ему 1 биткойн, как только он сообщит ей нужное значение.

Честность такого обмена биткойнов на значения должна быть гарантирована во всей сети. Точнее говоря, если Боб отправляет 1 биткойн Кэрол, он должен иметь гарантию того, что получит 1 биткойн от Алисы. Для этого используются контракты с хешированием и временной блокировкой (HTLC).

Контракты с хешированием и временной блокировкой

Итак, Алиса хочет обменять 1 биткойн на значение у Боба с помощью HTLC (Боб и Кэрол хотят того же самого, но забудем пока об этом). Для этого Алиса отправляет биткойн на новый адрес с мультиподписью, где биткойн блокируется. Разблокировать его можно двумя способами: Боб может сделать это, указав свою подпись и значение, а Алиса — указав только свою подпись. Однако во втором случае действует CLTV-блокировка: Алиса может подписать и отправить в сеть транзакцию только по прошествии, скажем, двух недель.

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

Но на самом деле контракты HTLC необходимы на уровне сети.

Как уже было сказано, HTLC создают не только Алиса с Бобом, но и Боб с Кэрол. Если Кэрол потребует 1 биткойн у Боба, он получит в обмен нужное ему значение — оно будет записано в блокчейн. Ну а если эта сделка будет совершена, Боб гарантированно получит 1 биткойн от Алисы: для этого ему достаточно добавить обнародованное Кэрол значение в HTLC, заключенный с Алисой. Два канала связаны.

Важно отметить, что Боб должен получить значение от Кэрол раньше, чем Алиса получит шанс потребовать свой биткойн обратно, в противном случае он останется со значением, но без денег. Таким образом, HTLC между Бобом и Кэрол должен истекать раньше, чем HTLC между Алисой и Бобом (например, через 10 дней и 2 недели соответственно; по этой же причине в HTLC необходимо использовать блокировку CheckLockTimeVerify (CLTV), а не CheckSequenceVerify (CSV)).

Чтобы Lightning Network была полезной, осталось решить лишь одну задачу: все это должно выполняться вне блокчейна.

Lightning Network

Теперь Алисе, Бобу и Кэрол нужно добавить HTLC в канал, чтобы Боб, купивший у Кэрол значение за 1 биткойн, наверняка мог компенсировать свои расходы, получив биткойн от Алисы.

Как и раньше, Алиса и Боб первым делом создают по одной транзакции-обязательству. Эти транзакции включают обычный выход и выход, указывающий на адрес с мультиподписью, CSV-блокировкой и специальной хеш-блокировкой. Далее Алиса и Боб обмениваются своими старыми секретами, делая старый канал недействительным. После обмена они теоретически могут в любой момент подписать свое обязательство и отправить его в блокчейн.

Все это нам уже известно, а теперь изменение. В этот раз транзакции-обязательства Алисы и Боба включают новый выход с одним биткойном (иначе говоря, балансы распределяются в отношении 4-5-1: 4 биткойна для Алисы, 5 для Боба и 1 для нового выхода).

Этот новый выход соответствует HTLC-контракту, и разблокировать его можно тремя способами.

Прежде всего, этот выход (в обязательстве и Алисы, и Боба) разблокирует биткойн, если последующая транзакция включает подпись и значение Боба. Таким образом, неависимо от того, кто подпишет и отправит в сеть транзакцию-обязательство, — Алиса или Боб — разблокировать этот выход может только Боб, указав нужное значение. Однако между двумя обязательствами есть одно небольшое различие: если Боб решит закрыть канал, будет задействована CSV-блокировка и ему придется подождать 1000 блоков. Если же канал закроет Алиса, он получит 1 биткойн немедленно).

Причина, по которой Бобу придется подождать 1000 блоков, такая же, как и раньше: это позволяет Алисе забрать 1 биткойн в том случае, если Боб попытается подписать и отправить в сеть старое состояние канала. Это приводит нас ко второму способу разблокирования нового выхода: Алиса может «украсть» деньги, если укажет (самый новый) секрет Боба. Но если она попытается смошенничать и отправит в сеть устаревшее состояние канала, Боб сможет получить 1 биткойн, воспользовавшись секретом Алисы (ему даже не придется указывать значение).

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

Что же мы имеем на текущий момент?

У Алисы и Боба есть по транзакции-обязательству. Если Алиса отправит свое обязательство в блокчейн, она немедленно отправит 5 биткойнов Бобу. Она также может подождать 1000 блоков и забрать 4 биткойна. Кроме того, у Боба есть 2 недели на то, чтобы предоставить значение и забрать 1 биткойн из HTLC-выхода (если он не предоставит значение за 2 недели, Алиса сможет вернуть этот биткойн себе).

Боб может в любой момент отправить свое обязательство в блокчейн и немедленно отправить 4 биткойна Алисе, а также он может подождать 1000 блоков и забрать 5 биткойнов (кроме того, как было сказано чуть выше, он может забрать 1 биткойн из HTLC-выхода, предоставив нужное значение).

И, конечно, если Алиса или Боб попытаются схитрить и отправить в сеть устаревшее состояние канала, честная сторона сможет получить все биткойны в канале.

Фиксация состояния

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

Алисе это известно, и она никак не может украсть у Боба его биткойн — даже если она каким-либо образом узнает значение.

Таким образом, Алиса и Боб могут согласовать платежный баланс вне канала. Боб может просто передать значение Алисе, а Алиса обновит состояние канала без HTLC-контракта и тайм-аута. Так они и будут делать, если они заинтересованы в поддержании канала, потому что это проще, чем фиксировать состояние канала в блокчейне.

Закрытие канала

Теперь вам должна быть понятна реальная мощь сети Lightning Network:

Почти все, что мы обсудили в этой статье, никогда не попадет в блокчейн.

Если Алиса и Боб захотят мирно закрыть канал по обоюдному согласию, они могут просто создать транзакцию, переопределяющую все, что произошло после открывающей транзакции. Иначе говоря, если в нашем примере Алиса хочет закрыть канал, она может создать транзакцию, которая выплачивает 4 биткойна ей и 6 Бобу, и попросить Боба подписать эту транзакцию. У Боба нет причин отказывать Алисе, поэтому он почти наверняка пойдет ей навстречу. После подписания и отправки транзакции канал будет закрыт.

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