💬 Протокол замены защелки Lightning Layer Mercury Layer

Протокол замены защелки Lightning Layer Mercury Layer

Commerceblock выпустила новый протокол атомарного обмена для использования с цепочками состояний в своем протоколе Mercury Layer. Сервер HSM представил функциональные возможности для поддержки атомарной замены двух цепочек состояний, а также принудительного обмена цепочки состояний для платежей Lightning. Это первый пример конкретно определенного и построенного взаимодействия между цепочками состояний и сетью Lightning. Синергия между обоими протоколами постулировалась с тех пор, как концепция цепочки состояний была первоначально предложена Рубеном Сомсеном, в частности, как способ решения ограничения, связанного с необходимостью одновременной передачи всей цепочки состояний UTXO.

Базовые свопы Statechain

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

Это позволяет серверу HSM отслеживать и применять все переменные, необходимые для обеспечения безопасного атомарного обмена. При запуске обмена пользователи должны напрямую взаимодействовать друг с другом, чтобы установить между ними общий пакетный идентификатор. С этого момента они обмениваются всей необходимой информацией, необходимой для облегчения нормальной передачи цепочки состояний, и отправляют эту информацию, а также Batch_id и время пакета на сервер. По сути, они запускают обычный процесс передачи, а также присоединяют переменные для соединения отдельных цепочек состояний, участвующих в обмене, и определения длительности периода ожидания для этого.

На этом этапе сервер применит блокировку к каждой цепочке состояний, используя один и тот же Batch_id в процессе передачи. Пока тайм-аут не истечет или все цепочки состояний в его базе данных, использующие один и тот же пакетный_ид, не будут разблокированы текущими владельцами, сервер не будет одобрять какие-либо передачи. Особенность того, как HSM реализует логику подкачки, заключается в том, что не имеет значения, кто первым обращается к серверу. Когда сервер получает сообщение с использованием Batch_id, он проверяет каждую цепочку состояний в своей базе данных и, если для этого Batch_id уже существует время пакета, он устанавливает его как то же самое. Это гарантирует, что независимо от того, кто первым зарегистрирует обмен, все они будут использовать одно и то же значение времени для функции таймаута.

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

Молния защелка

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

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

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

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

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

Для чего это полезно?

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

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

Другим потенциальным вариантом использования (TRIGGER WARNING) может быть возможность создания более эффективных торговых площадок для торговли порядковыми номерами. Поскольку порядковые номера представляют собой просто индексную схему, отслеживающую пути назад в истории транзакций к конкретным сатоши, их можно легко перенести из цепочки в цепочку состояний. Эта динамика в сочетании с Lightning Latch может позволить дешевле и быстрее совершать покупки ординалов вне сети. Кто-то может создать рынок, на котором их можно будет мгновенно продавать вне сети через Lightning Network.

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

Что касается чистой передачи состояний между цепочками состояний, это дает потенциал для уровня передачи сообщений для воссоздания coinjoin, как системы, смешивающей монеты вне цепочки, аналогично исходной функции смешивания в первой реализации цепочки состояний Commerceblock.

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

Вы можете послушать, как команда Commerceblock объясняет логику протокола здесь:

Беседа с доктором @TTrevethan о том, зачем создавать молнию на @mercurylayer #bitcoin #layer2 pic.twitter.com/CKVG9aHTQ6 – Николас Грегори (@gregory_nico) 15 марта 2024 г.

Беседа с доктором @TTrevethan о том, зачем создавать молнию на @mercurylayer #bitcoin #layer2 pic.twitter.com/CKVG9aHTQ6

А более техническое объяснение здесь:

Подробно рассказываем о том, как будет работать молниеносная защелка с @TTrevethan на @mercurylayer #bitcoin #layer2 pic.twitter.com/aQIcjh2ukq – Николас Грегори (@gregory_nico) 16 марта 2024 г.

Подробно рассказываем о том, как будет работать молниеносная защелка с @TTrevethan на @mercurylayer #bitcoin #layer2 pic.twitter.com/aQIcjh2ukq