Что такое контракт с блокировкой времени хеширования (HTLC)?

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

Одна из самых мощных технологий в языке программирования биткоин-скрипта — это известный контракт HTLC или Hash Time Locked Contract. Это тип смарт-контрактов, основная способность которых заключается в создании платежных каналов или платежных шлюзов. Таким образом, HTLC позволяют создавать технологии  наподобие Lightning Network (LN),  в Биткойне и в других криптовалютах, совместимых с этой мощностью. Это означает, что HTLC позволяют создавать протоколы второго уровня, способные значительно ускорить масштабируемость Биткоина. И все это без ущерба для безопасности этого блокчейна.

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

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

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

 Канал nSequence Сатоши Накамото

Первая идея, которая привела к HTLC, исходила от самого Сатоши Накамото и касалась т.н. каналов nSequence. Эти типы каналов оплаты создаются с использованием Op_code. nSequence и nLockTime. Таким образом, можно было бы создать систему, в которой пользователь мог бы отправлять транзакцию со значением nLockTime (блокировка по времени) и nSequence (значение, позволяющее заменить одну транзакцию другой). Таким образом, пользователь может совершить определенное количество «мгновенных» покупок и платежей.

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

Это стало возможным потому что:

nSequences были разработаны, чтобы позволить заменять транзакции в мемпуле, если это значение не было помечено шестнадцатеричным значением 0xFFFFFFFF, поскольку, если оно было помечено этим значением, TX не мог быть заменен. Фактически, эта небольшая конструкция привела к созданию replace by Fee или RBF. Идея его использования в каналах nSequence заключалась в том, чтобы добавлять платежные операции в TX и заменять их в мемпуле до тех пор, пока, наконец, указанная TX не будет считаться окончательной транзакцией (помечая ее 0xFFFFFFFF в nSequence).

При использовании nLockTime будет установлен лимит времени, чтобы майнеры могли, наконец, принять TX и подтвердить его. Любопытный факт: nLockTime работает только в том случае, если nSequence отличается от 0xFFFFFFFF, поэтому эффективно это значение служит гарантией того, что каналы nSequence обмануты, гарантируя оплату продавцу через некоторое время, даже если канал не был закрыт nSequence.

Конечно, это очень простое решение, одностороннее (с ним мог справиться только создатель TX), с ограниченным временем жизни (использование nLockTime и nSequence не допускает бесконечной работы) и без безопасных правил консенсуса (всё случается) в мемпуле, где ничего не подтверждено).

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

Две  других известных форм платежных каналов - Spilman и CLTV Channels. Первый из них был предложен Джереми Спилманом. В  этом канале транзакции с мультиподписями сочетаются с использованием nLockTime, чтобы избежать ловушек, позволяющих украсть средства. По сути, Spilman состоит из:

• Создания транзакции с несколькими подписями «2 из 2», в которой покупатель и продавец создают канал оплаты. Транзакция только создается, но не передается в сеть, пока не будет выполнена вся операция. Этот первая сделка считается сделкой финансирования.
• Далее создается транзакция, которая тратит предыдущую с использованием nLockTime, гарантирующего оплату мультиподписной передачи. Эта сделка доставляется продавцу, который подписывает ее и возвращает покупателю.

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

Теперь при каждой новой платежной транзакции создается TX, который расходует транзакцию финансирования (первую созданную транзакцию). Эта операция отправляет оплату запрошенной вами суммы продавцу и возвращает сдачу покупателю. Покупатель может тратить столько, сколько он хочет, пока его финансовая транзакция позволяет.  При превышении лимита  пользователь не сможет продолжать тратить. Если пользователь закончил тратить, закрыв канал со сдачей, она автоматически перейдет покупателю.

Эту систему также можно создать с помощью OP_CODE, OP_ CHECKLOCKTIMEVERIFY(CLTV). В этом случае CLTV позволяет вам включать только новые условия закрытия платежного канала, которые позволяют избежать определенных ловушек (например, когда продавец не желает закрывать платежный канал после  завершения пользователем покупок). Кроме того, использование CLTV сводит к минимуму количество шагов, поскольку нет необходимости создавать вторую транзакцию канала Spilman.

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

Работа HTLC состоит из двух частей. Во-первых, это его способность выполнять хэш-блокировки или блокировки посредством хеширования выполняемых транзакций. И второе — возможность выполнять временную блокировку , или временные блокировки тех самых транзакций. Вместе эти две функции позволяют HTLC выполнять транзакции при определенных условиях, согласованных при исполнении контракта. Самое приятное то, что эти транзакции защищены на уровне хеша и времени. Это делает их очень безопасными по сравнению с первоначальными моделями платежных каналов, такими как nSequence Channel.

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

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

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

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

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

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

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

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

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

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

Другие альтернативы HTLC

Несмотря на преимущества, предлагаемые внедрением HTLC, некоторые разработчики сосредоточили свой интерес на разработке новых альтернатив этим смарт-контрактам. Разработчики экосистемы Lightning Network объединяют усилия для внесения  серьезных изменений в эту сеть. Это сделано с целью использования PTLC при выполнении транзакций с гораздо более высоким уровнем конфиденциальности, чем тот, который в настоящее время предлагает HTLC.

К  другим  видам смарт-контрактов, которые появляются при выполнении транзакций с несколькими подписями, относится Taproot.