В прошлой статье мы с вами подробно разобрали работу платежных каналов, а также несколько различных методов по обеспечению безопасности платежей, проходящих через них, однако этого все еще недостаточно для построения рабочей сети каналов: даже если мы уверены в том, что внутри каждого канала все играют честно, мы не можем гарантировать доставку средств по цепочке через ряд каналов. И здесь нам на помощь приходят смарт-контракты, называемые HTLC (hash-time-lock-contracts). В этой статье мы разберем принцип их работы, и продемнострируем как проходит платеж в сети Lightning network.  HTLC контракты представляют собой несложную, но при этом очень эффективную конструкцию, позволяющую создавать платежи с определенным "сроком годности". Как вы наверно уже догадались, htlc-контракт состит из 2ух частей: проверки хеша и проверки истечения определенного времени. Начнем разбор с хеша. Для создания HTLC платежа сначала должен быть создан секрет R, а затем посчитан его хеш. В качетсве секрета может выступать что угодно — цифра или слово, в любом случае это всего лишь набор байтов. Этот хеш H будет включен в запирающий скрипт. Таким образом испльзовать платеж сможет только тот, кто знает секрет, хешированием которого был получен H. Секрет R также называют прообразом (preimage) . Второй частью htlc-контрактра является проверка истечения времени блокировки платежа. Если секрет не был вовремя выявлен и платеж не был использован, отправитель может вернуть все средства себе. Рассмотрим пример HTLC платежа, предназначенного определенному человеку: При предоставлении верного секрета R, являющегося прообразом хеша H мы попадаем в поток IF, где далее идет проверка: действительно ли человек, нашедший секрет R, это тот, кому предназначен платеж. Чтобы потратить этот платеж, получателю нужно предоставить довольно простой отпирающий скрипт: Если же предоставленный секрет R будет неверным, мы попадаем в поток ELSE, где сначала проверяется, прошло ли отведенное количество времени, и если да, то отправительно платежа может вернуть все средства. Отпирающий скрипт для возврата средств ничем не отличается, за исключением того, что мы должны специально указать неверный секрет, чтобы попасть в ELSE поток: Конечно же, это очень базовая имплементация HTLC-контракта, представляющая из себя обычный time-lock платеж. Вы можете добавить сколько угодно различный условий к скрипту: убрав, например, проверку публичного ключа в IF потоке, мы можем сделать платеж доступным любому, кто знает секрет или же вместо одной подписи требовать несколько, как в мультисиге и тд. P.s Здесь мы использовали опкод CHECKLOCKTIMEVERIFY, который использует абсолютное значение для задания времени блокировки, например "Этот выход не может быть потрачен до блока #546212". В Lightning Network помимо него используется еще и другой, более "гибкий" вариант — CHECKSEQUENCEVERIFY, он задает время блокировки относительно, то есть возможен такой вариант: "Этот выход не может быть потрачен, пока с момента отправки транзакции в сеть не прошло 1000 блоков." . Теперь, когда мы наконец разобрали все составляющие, можно взглянуть на всю картину целиком, а именно на то, как же все-таки работает Lightning Network. В этом примере у нас будет 5 участников: Алиса, Боб, Кэрол, Диана и Эрик, у которых есть открытые платежные каналы между друг другом с балансом по 2 биткоина у каждого на каждом канале, где они являются одной из сторон. Таким образом, имея цепочку каналов, попробуем провести платеж от Алисы к Эрику.  Допустим, Алиса хочет перевести Эрику 1 биткоин. Однако, как мы видим, они не соединены каналом напрямую, а открытие нового канала требует средств и времени. К счастью, Алиса подключена к Lightning network и может провести платеж ненапрямую с помощью серии HTLC контрактов. Рассмотрим по шагам, как это произойдет.  Таким образом Алиса заплатила Эрику 1 BTC без открытия между ними нового канала. Никто из участников цепочки не обязан был доверять друг другу, а за предоставление своих услуг как "посредников", они заработали в качестве комиссии по 0.001 BTC. В случае, если бы кто-то из цепочки не смог выполнить свою часть, никто не потерял бы свои средства, а только временно (на время блокировки) заморозил их. В нашем примере все прошло гладко, однако в реальной жизни все подчиняется закону Мерфи, и если что-то может сломаться, то оно так и сделает, поэтому давайте разберем работу механизмов "защиты" Lightning Network. Очевидно, что, чем длиннее цепочка, по которой доставляются средства, тем выше вероятность того, что средства не дойдут до конца — кто-то из участников может закрыть канал, а у кого-то может просто отключиться интернет. Рассмотрим 2 варианта событий, где что-то пошло не так. В первом случае представим, что средства успешно дошли до конца цепочки, однако на обратом пути (когда секрет должен по цепочке вернутся к самому началу) возникла проблема — один из участников отказался или не смог кооперировать — в нашем примере это Боб.  Диана, как только до нее дошла цепочка, сразу же забирает свои средства, используя секрет, попутно раскрывая его Кэрол. Кэрол также хочет получить свои деньги от Боба, однако он не отвечает, поэтому, чтобы не рисковать, она закрывает канал, отправляя последнюю коммит-транзакцию канала (HTLC-контракт, отправленный Бобом ранее) в блокчейн, и, с помощью секрета, забирает средства. У Боба в таком случае все еще есть 3 дня, чтобы выйти на связь и забрать свои деньги у Алисы (так как транзакция отправилась в блокчейн, он может спокойно найти ее и увидеть R), в противном случае по истечении этого срока она сможет вернуть все свои средства.  Как видите, в этом случае, если один из участников цепочки по какой-либо причине выходит из строя, он единственный, кто может потерять средства, все остальные же находятся в безопасности. Во втором случае рассмотрим ситуацию, когда средства не дошли до конца цепочки, опять же по причине неработоспособности одного из участников. Теперь это Кэрол. Первым и самым очевидным способом является просто подождать, пока истечет время блокировки HTLC-контрактов и можно будет вернуть средства назад, чтобы отправить новый платеж.  Но что, если Алиса торопится? Конечно, можно не ждать, пока средства вернутся и просто отправить еще 1 платеж уже по другой цепочке, но если Кэрол вдруг вернется, свяжется с Бобом и закончит цепочку? В таком случае Алиса отправит двойную сумму денег.  Так неужели каждый раз при провале операции мы вынуждены ждать, прежде чем отправить новую? К счастью, дабы не дожидаться окончания блокировки, мы можем "обнулить" предыдущий платеж. Для этого Диана (получатель средств) должна отправить платеж эквивалентной суммы Алисе, используя все тот же хеш, что и в первый раз, при этом цепочка вовсе не должна быть той же самой. Теперь, если Кэрол вернется и завершит свою часть работы, деньги просто перейдут по кругу. Таким образом неудавшийся платеж можно считать аннулированным и спокойно отправлять новый платеж по другой цепочке.  Думаю, вы заметили, что хоть Алиса и "отменила" первый платеж и теперь может отправлять новый, это не меняет того факта, что средства все еще заморожены там и у нее может просто не хватить денег на повторение операции, поэтому в Lightning Network предпочтительнее отправлять малую сумму за один HTLC. Так как коммит-транзакции не "ударяют" по блокчейну, можно делить сумму на крайне мелкие части. Таким образом как только цепочка перестает работать, замороженной остается только лишь малая часть платежа, отправленная последней. Также здесь стоит упомянуть очень важное свойство Lightning Network — вся информация о цепочке платажей абсолютно анонимна. Это значит, что каждый участник цепочки знает только о своем "участке": для Кэрол, например, платеж выглядит как перевод средств от Боба к Диане, она не знает, что Боб в свою очередь получил деньги от Алиса, или что Диана далее должна перевести деньги Эрику. Lightning использует протокол многослойного шифрования сообщений Sphinx для упаковки таких сообщений. Используя его, Алиса заворачивает каждый участок цепи в "слой" шифрования, начиная с конца цепочки. Она зашифровывает сообщение для Эрика, используя его публичный ключ. Это сообщение включено в сообщение для Дианы, которое в свое очередь также будет зашифровано ее ключом, а сообщение для Дианы будем включено в сообщение для Кэрол, опять же зашифрованное соответствующим ключом и так до самого начала цепочки. Таким образом Боб сможет расшифровать только самый верхний слой сообщения, который адресован ему и перешлет сообщение Кэрол и тд.. На каждом этапе раскрывается только необходимая информация: количество средств, которые должны быть отправлены, размер комиссии, время блокировки и тд. Также, чтобы нельзя было догадаться о длине цепочке по весу сообщения, оно всегда имеет фиксированный размер, как будто в цепочке участвуют 20 человек. Каждый участник, кроме последнего, видит сообщение одного и того же размера и думает, что впереди еще 20 участников. Конечно же, преимущества Lightning Network не ограничиваются одним только масштабированием биткоина, как многие думают. Рассмотрим некоторые из возможностей, которые перед нами открывает Lightning. На этом мы заканчиваем наш разбор Lightning Network. В следующих статьях мы расскажем вам как можно при помощи HTLC контрактов провести cross-chain atomic swap между биткоином и лайткоином. Software Engineer