Понимание Lightning Network, часть 2: создание сети

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

Но мало кто полностью понимает, как «будущее микроплатежей» должно расширить возможности Биткоина.

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

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

Сеть

В предыдущей статье Элис и Боб установили двунаправленный платежный канал. Теперь Элис хочет заплатить один биткоин третьему лицу – Кэрол.

Для этого Элис и Кэрол могли бы открыть между собой платежный канал. Но на самом деле им это не нужно. Как оказалось, у Боба и Кэрол уже есть общий канал, поэтому Элис может просто заплатить Кэрол через Боба.

В частности, Элис может заплатить Бобу один биткоин, а Боб может заплатить Кэрол один биткоин.

Однако Элис на самом деле не доверяет Бобу или Кэрол, если уж на то пошло. Она боится, что если она заплатит Бобу, Боб никогда не заплатит Кэрол. Или, возможно, Боб действительно заплатит Кэрол, но Кэрол будет утверждать, что никогда не получала денег, и Элис не будет знать, кого винить.

Поэтому Элис хочет убедиться, что она только тогда платит Бобу один биткоин, если он также платит один биткоин Кэрол. Это достигается (частично) с помощью простого криптографического трюка.

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

Тем временем Элис берет хэш у Кэрол, возвращается к Бобу и говорит Бобу, что даст ему биткоин, если он предоставит ей соответствующее числовое значение (которое есть только у Кэрол).

Итак, Боб обращается к Кэрол и дает Кэрол один биткоин в обмен на числовое значение.

Затем Боб возвращается к Элис с числовым значением. Элис знает, что Боб, должно быть, получил числовое значение от Кэрол в обмен на биткоин, и поэтому заключает, что Кэрол получила ее биткоин. Так что Элис может с уверенностью дать Бобу биткоин.

Все счастливы.

Хорошо...почти все счастливы.

В этом «наивном» сценарии посредник Боб по-прежнему должен доверять Элис и Кэрол. Боб должен доверять Кэрол в том, что она действительно даст ему числовое значение после того, как он переведет ей биткоин, и Боб должен доверять Элис, что она действительно даст ему биткоин, как только он предоставит ей числовое значение.

Таким образом, сделки формата «биткоин в обмен на числовое значение» должны быть абсолютно гарантированы в сети. Более конкретно: если Боб отдает биткоин Кэрол, он должен гарантированно получить биткоин обратно от Элис.

Вот тут-то и появляются контракты с хешлоками и таймлоками (временной блокировкой) (HTLC).

Контракты с хешлоками и таймлоками (HTLC)

Итак, Элис и Боб хотят обменять биткоин на числовое значение через HTLC. (И Боб и Кэрол также хотят обменять биткоины на ту же сумму, но пока не берите это в голову).

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

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

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

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

И если Боб не предоставит числовое значение вовремя, у Элис есть «альтернатива в виде тайм-аута», чтобы вернуть свои биткоины. Все просто.

Вернемся к сети, так как именно для этого нужна эта настройка HTLC.

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

Следовательно, если это произойдет, Боб гарантированно получит биткоин и от Элис. Боб может взять числовое значение, которое Кэрол сделала общедоступным в блокчейне, включить его в свой HTLC с Элис, а также потребовать биткоин для себя. Два канала эффективно связаны.

И наконец, действительно важно, чтобы Боб получил числовое значение от Кэрол, прежде чем Элис сможет вернуть свои биткоины от Боба. Если Боб получает числовое значение от Кэрол только после того, как Элис уже вернула свое обратно, Боб в конце концов застрянет посередине. Таким образом, тайм-аут в HTLC Боба и Кэрол должен истечь до истечения тайм-аута в HTLC Элис и Боба. (Например, ровно через десять дней вместо двух недель. Именно поэтому для HTLC требуется CheckLockTimeVerify (CLTV), а не CheckSequenceVerify (CSV)).

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