В прошлой статье мы с вами подробно разобрали работу платежных каналов, а также несколько различных методов по обеспечению безопасности платежей, проходящих через них, однако этого все еще недостаточно для построения рабочей сети каналов: даже если мы уверены в том, что внутри каждого канала все играют честно, мы не можем гарантировать доставку средств по цепочке через ряд каналов. И здесь нам на помощь приходят смарт-контракты, называемые HTLC (hash-time-lock-contracts). В этой статье мы разберем принцип их работы, и продемнострируем как проходит платеж в сети Lightning network.

Table of contents

• HTLC
• Lightning network example
• Clearing out failure
• Transport protocol
• Benefits and use cases
• Conclusion
• Links

Hash time lock contracts (HTLC)

HTLC контракты представляют собой несложную, но при этом очень эффективную конструкцию, позволяющую создавать платежи с определенным "сроком годности". Как вы наверно уже догадались, htlc-контракт состит из 2ух частей: проверки хеша и проверки истечения определенного времени.

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

H = Hash(R)

Этот хеш H будет включен в запирающий скрипт. Таким образом испльзовать платеж сможет только тот, кто знает секрет, хешированием которого был получен H. Секрет R также называют прообразом (preimage) .

Второй частью htlc-контрактра является проверка истечения времени блокировки платежа. Если секрет не был вовремя выявлен и платеж не был использован, отправитель может вернуть все средства себе.

Рассмотрим пример HTLC платежа, предназначенного определенному человеку:

# check if secret R is preimage of H
HASH160 <H> EQUAL
IF
    # check if person, who revealed secret is intended payee
    <Payee Public key> CHECKSIG
ELSE
    # check if time-lock is ended
    <locktime> CHECKLOCKTIMEVERIFY
    # check that person that requested refund is original payer
    <Payer Public Key> CHECKSIG
ENDIF

При предоставлении верного секрета R, являющегося прообразом хеша H мы попадаем в поток IF, где далее идет проверка: действительно ли человек, нашедший секрет R, это тот, кому предназначен платеж. Чтобы потратить этот платеж, получателю нужно предоставить довольно простой отпирающий скрипт:

<sig> <secret R>

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

<sig> <wrong secret>

Конечно же, это очень базовая имплементация HTLC-контракта, представляющая из себя обычный time-lock платеж. Вы можете добавить сколько угодно различный условий к скрипту: убрав, например, проверку публичного ключа в IF потоке, мы можем сделать платеж доступным любому, кто знает секрет или же вместо одной подписи требовать несколько, как в мультисиге и тд.

P.s Здесь мы использовали опкод CHECKLOCKTIMEVERIFY, который использует абсолютное значение для задания времени блокировки, например "Этот выход не может быть потрачен до блока #546212". В Lightning Network помимо него используется еще и другой, более "гибкий" вариант — CHECKSEQUENCEVERIFY, он задает время блокировки относительно, то есть возможен такой вариант: "Этот выход не может быть потрачен, пока с момента отправки транзакции в сеть не прошло 1000 блоков." .

Lightning Network Example

Теперь, когда мы наконец разобрали все составляющие, можно взглянуть на всю картину целиком, а именно на то, как же все-таки работает Lightning Network. В этом примере у нас будет 5 участников: Алиса, Боб, Кэрол, Диана и Эрик, у которых есть открытые платежные каналы между друг другом с балансом по 2 биткоина у каждого на каждом канале, где они являются одной из сторон. Таким образом, имея цепочку каналов, попробуем провести платеж от Алисы к Эрику.

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

1. Эрик создает некий секрет R и сообщает его хеш Алисе (сам секрет он при этом никому не показывает).
2. Алиса создает с помощью этого хеша HTLC с блокировкой на 10 блоков вперед на сумму 1.003. Дополнительные 0.003 будут использованы как вознаграждение промежуточным участникам за участие в цепочке. Таким образом Алиса запирает свои 1.003 BTC баланса в HTLC, со следующим правилом: "Алиса заплатит Бобу 1.003 биткоина, если он узнает секрет R в течение 10ти блоков, в противном случае средства вернутся к Алисе.". Баланс канала был изменен коммит-транзакцией и теперь представляет следующее: 2 BTC у Боба, 0.997 у Алисы и 1.003 заперто в HTLC.
3. Боб, имея на руках коммит-транзакцию Алисы (HTLC отправленный на канал между ними), в свою очередь также создает HTLC на канале между ним и Кэрол на сумму 1.002 BTC с блокировкой уже на 9 блоков вперед. При этом он использует тот же хеш, что использован Алисой. Боб знает, что Кэрол нужно будет найти секрет R, чтобы разблокировать HTLC, отправленный им, и как только она это сделает, он также его узнает, а значит сможет разблокировать 1.003 BTC, отправленные ему Алисой. Если же Кэрол не сможет найти R, средства Боба и Алисы просто вернутся к ним после истечения блокировок. Также заметим, что сумма, которую отправил Боб, на 0.001 меньше, чем полученная им — это комиссия, которую он взял за участие в цепочке. Баланс канала между Бобом и Кэрол теперь: 2 BTC у Кэрол, 0.998 BTC у Боба и 1.002 BTC заперто в HTLC.
4. Кэрол, получив коммит-транзакцию Боба, создает HTLC (с помощью хеша, использованного Бобом) на канале с Дианой на сумму 1.001 BTC и блокировкой на 8 блоков. Если Диана сможет найти секрет R в течение 8 блоков и разблокировать HTLC, чтобы получить 1.001 BTC, Кэрол также узнает секрет, а значит сможет разблокировать 1.002 BTC, отправленные ей Бобом и таким образом заработает 0.001 BTC. Баланс канала между Кэрол и Дианой теперь теперь: 2 BTC у Дианы, 0.999 BTC у Кэрол и 1.001 BTC заперто в HTLC.
5. Наконец, Диана отправляет HTLC (все с тем же хешем) на ее канал с Эриком на сумму 1 BTC и с блокировкой на 7 блоков. Баланс их канала теперь: 2 BTC у Эрика, 1 BTC у Дианы и 1 BTC заперт в HTLC.
6. Теперь же, мы дошли до конца нашей цепочки. Эрик, имея секрет R, хеш которого был использован во всех HTLC коммит-транзакциях, может разблокировать HTLC, отправленный ему Дианой и получить 1 BTC. Как только Эрик использует секрет для получения средств, он также откроет его Диане. Баланс канала между Эриком и Дианой теперь составляет: 3 BTC у Эрика и 1 BTC у Дианы.
7. Диана, получив секрет, разблокирует 1.001 BTC, отправленные Кэрол и тем самым откроет ей секрет. Баланс канала между ними теперь составляет: 3.001 BTC у Дианы и 0.999 BTC у Кэрол.
8. Кэрол, получив секрет, разблокирует 1.002 BTC, отправленные Бобом и откроет ему секрет. Баланс канала между ними теперь составляет: 3.002 BTC у Кэрол и 0.998 у Боба.
9. На последнем шаге Боб с помощью секрета получает 1.003 BTC на канале между ним и Алисой. Баланс их канала теперь: 3.003 BTC у Боба, 0.997 у Алисы.

Таким образом Алиса заплатила Эрику 1 BTC без открытия между ними нового канала. Никто из участников цепочки не обязан был доверять друг другу, а за предоставление своих услуг как "посредников", они заработали в качестве комиссии по 0.001 BTC. В случае, если бы кто-то из цепочки не смог выполнить свою часть, никто не потерял бы свои средства, а только временно (на время блокировки) заморозил их.

Clearing out failure

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

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

Broken channel

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

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

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

Rerouting

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

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

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

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

Payment amount

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

Transport protocol

Также здесь стоит упомянуть очень важное свойство Lightning Network — вся информация о цепочке платажей абсолютно анонимна. Это значит, что каждый участник цепочки знает только о своем "участке": для Кэрол, например, платеж выглядит как перевод средств от Боба к Диане, она не знает, что Боб в свою очередь получил деньги от Алиса, или что Диана далее должна перевести деньги Эрику.

Lightning использует протокол многослойного шифрования сообщений Sphinx для упаковки таких сообщений. Используя его, Алиса заворачивает каждый участок цепи в "слой" шифрования, начиная с конца цепочки. Она зашифровывает сообщение для Эрика, используя его публичный ключ. Это сообщение включено в сообщение для Дианы, которое в свое очередь также будет зашифровано ее ключом, а сообщение для Дианы будем включено в сообщение для Кэрол, опять же зашифрованное соответствующим ключом и так до самого начала цепочки. Таким образом Боб сможет расшифровать только самый верхний слой сообщения, который адресован ему и перешлет сообщение Кэрол и тд.. На каждом этапе раскрывается только необходимая информация: количество средств, которые должны быть отправлены, размер комиссии, время блокировки и тд.

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

Benefits and use cases

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

• Мгновенные транзакции. Используя Lighting, транзакции проходят практически мгновенно. С его помощью заплатить за кофе с помощью биткоина становится возможно.
• Арбитраж. На данный момент быстрый перевод денег с одной биржы на другую не представляется возможным, так как требуется 3-6 блоков для подтверждения транзакции. Если же биржы будут использовать lightning, то пользователи смогут переводить средства мгновенно, что позволит проводить арбитражные сделки. Также, биржам не нужно будет держать 'холодных' кошелькох для хранения средств, что сильно уменьшит вероятность краж.
• Микроплатежи. Комиссия за транзакцию в биткоине слишком большая, чтобы проводить микроплатежи. Врядли кто-то захочет платить 0.001 для того, чтобы перевести столько же или еще меньше. С Lightning у вас появится возможность переводить мгновенно любые суммы, так что вы сможете, например, оплачивать интернет помегабайтно.
• Финансовые смарт-контракты и сделки. Финансовые контракты особенно чувствительны ко времени и часто требуют много вычислений. Перемещая большую их часть 'наружу', мы получаем возможность создания крайне сложных транзакций и контрактов без их записи в блокчейн.
• Cross-chain платежи. Если в блокчейнах с разными правилами консенсуса присутствуют похожие хеш-функции, то между ними возможно проводить транзакции. Участникам при этом не нужно будет доверять друг другу или использовать посредника.
• Приватность. Транзакции в Lightning гораздо более анонимны, чем в блокчейне биткоина, так как участники цепочек, по которым идет платеж, не могут видеть отправителя или получателя.

Conclusion

На этом мы заканчиваем наш разбор Lightning Network. В следующих статьях мы расскажем вам как можно при помощи HTLC контрактов провести cross-chain atomic swap между биткоином и лайткоином.

Links

• Lightning network part 1: payment channels
• "Mastering bitcoin" — Andreas M. Antonopoulos
• Lightning network whitepaper
• Segregated witness for dummies