Протокол обміну міжшаровим спалахом шару ртуті

Протокол обміну міжшаровим спалахом шару ртуті

Компанія Commerceblock випустила новий протокол атомного обміну для використання зі стейчейнами на їхньому протоколі Mercury Layer. Сервер HSM впровадив функціонал для підтримки атомного обміну двох стейчейнів, а також забезпечення атомного обміну стейчейну за платіж Lightning. Це перший приклад чітко визначених та побудованих взаємодій між стейчейнами та Lightning Network. Синергія між обома протоколами була припущена з моменту створення концепції стейчейну Рубеном Сомсеном, специфічно як спосіб вирішення обмеження необхідності передачі цілого стейчейну UTXO одночасно. Базові обміни стейчейнів

Для підтримки нових протоколів обміну, сервер HSM потрібно додати деякі нові поля до своїх записів баз даних, які відстежують кожен стейчейн, який він фасує. Для полегшення обміну між стейчейнами, сервер повинен відстежувати: Batch_id: значення, що асоціює стейчейни, що обмінюються в групі. Batch-time: час, який розпочинає лічильник після якого стейчейни можуть бути `відновлені`, якщо обмін не вдасться. Заблоковано: значення, що вказує, чи є стейчейн заблокований і обмежений для звичайних переказів.

Це дозволяє серверу HSM відстежувати та забезпечувати всі змінні, необхідні для забезпечення безпечного атомного обміну. Під час ініціювання обміну користувачам потрібно спілкуватися один з одним безпосередньо, щоб встановити спільне batch_id між ними. З цього моменту вони торгують усією необхідною інформацією, необхідною для полегшення нормального переказу стейчейну, та відправляють цю інформацію разом з batch_id та batch-time на сервер. Фактично вони починають стандартний процес переказу, але також додають змінні для підключення окремих стейчейн, які беруть участь в обміні одночасно та тривалість тайм-ауту для цього.

На цей момент сервер додасть блокування до кожного стейчейну, який використовує той самий batch_id у процесі переказу. Доки тайм-аут не закінчиться або всі стейчейни в його базі даних, які використовують той самий batch_id, не будуть розблоковані поточними власниками, сервер не схвалить жодних переказів. Чудовий момент в тому, як HSM забезпечує логіку обміну, полягає в тому, що не має значення, хто звертається до сервера першим. Коли сервер отримує повідомлення з використанням batch_id, він перевіряє кожен стейчейн в своїй базі даних і, якщо для цього batch_id є попередній час, він встановлює це саме. Це забезпечує, що незалежно від того, хто реєструє обмін першим, вони всі використовують одне значення часу для функції тайм-ауту.

Кожен клієнт, задіяний у взаємному обміні на цей момент, перевіряє та завантажує повідомлення, що ініціюють процес переказу, та після підтвердження їх правильності відправляє повідомлення на сервер для розблокування їх стейчейнів, видаляючи обмеження переказу. Коли хтось намагається завершити переказ на стороні одержувача будь-якого з стейчейнів, що беруть участь у взаємному обміні, сервер перевіряє, чи всі стейчейни з тим самим batch_id розблоковані. Якщо навіть один з них з відповідним batch_id ще є заблокованим, сервер завершить переказ для жодного з них. Якщо обмін не вдасться до тайм-ауту, сервер продовжить обмежувати завершення переказу, але дозволить поточним власникам ініціювати новий переказ собі для ефективного скасування обміну. Lightning Latch

Функціонал Lightning Latch, обмін стейчейну за платіж Lightning, працює дуже схоже на обмін стейчейну на стейчейн. Ось нові поля, які сервер повинен відстежувати для Lightning-обміну: Batch_id: значення, що асоціює стейчейни, які обмінюються у групі. Batch-time: час, який починає лічильник після чого стейчейни можуть бути `відновлені`, якщо обмін не вдасться. Pre-image: преімедж платежу Lightning, який генерується сервером HSM. Заблокований_1 та заблокований_2: для Lightning-обміну є два поля блокування, одне авторизоване кожним користувачем, що бере участь.

Так само як з обміном стейчейну на стейчейн, користувачі встановлюють та діляться випадковим batch_id. Поточний власник стейчейну потім відправляє серверу повідомлення із batch_id та включеним стейчейном і просить його згенерувати хеш-блокування для платежу Lightning. Цей користувач потім генерує рахунок Lightning, використовуючи цей преімедж, і другий користувач зв`язується з сервером для підтвердження, що він згенерував преімедж. Поточний власник стейчейну потім розпочинає процес переказу стейчейну і завантажує повідомлення про переказ на сервер.

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

Зараз, коли обидва заблокування видалено, сервер HSM вивільняє преімедж поточному власникові стейчейну для завершення платежу Lightning і завершує переказ стейчейну одержувачу.

Для цієї схеми потрібно довіряти оператору стейчейну для чесної роботи, проте це фундаментально не змінює модель довіри до використання стейчейну взагалі. Оператор ніколи не має керування коштами користувачів, нічого не знає про деталі платежу Lightning. Для чого це потрібно?

Ця схема відстань від спочатку поставленої інтеракції між стейчейнами та каналами Lightning, накладаючи одне на одне, але навіть як початкова точка це презентує функціональну корисність для існуючих користувачів Lightning. Перебалансування каналів є необхідною річчю для багатьох вузлів, якщо ємність повністю стиснута в одну сторону або в іншу, корисність цього каналу обмежена для маршрутизації платежів.

Багато бізнесів та користувачів почали експериментувати з використанням Liquid як механізму для цього через підвищення внутрішньоканальних комісій та зроблення обмінів в межах Lightning Network дорожчими.

Стейчейни пропонують альтернативний механізм для федеративного бічного ланцюжка, щоб полегшити деякі витрати на комісії, пов`язані з управлінням балансом каналу. Замість того, щоб дістатися до головного ланцюжка безпосередньо, або використовувати бічний ланцюжок, кошти можуть бути обмінені на стейчейн та утримуватися там, поки вони не будуть потрібні для обміну коштів назад у канал. Аналогічні економії на комісіях можна зробити, зберігаючи здатність односторонньо претендувати на свої кошти на головному ланцюжку.

Інші потенційні використання (ТРИГЕРНЕ ПОПЕРЕДЖЕННЯ) можуть бути можливістю більш ефективних ринків для торгівлі ординалами. Оскільки ордінали просто схема індексування, що відстежує шляхи назад у історії транзакцій до конкретних сатоші, їх легко можна перенести в офлайн на стейчейн. Ця динаміка разом з Lightning Latch може дозволити дешевші та швидші офлайн-покупки ординалів. Хтось міг би побудувати ринок, де їх можна продавати миттєво офлайн через мережу Lightning.

Навіть одного дня, якщо клієнти Lightning якось могли б усвідомити, яким стейчейн операторам довіряється конкретним вузлам Lightning, то Latch може бути використана для допомоги в маршрутизації платежів шляхом передачі стейчейнів між різними вузлами замість використання традиційних каналів Lightning.

Щодо чистого переказу стейчейну на стейчейн, це відкриває потенціал для шару передачі повідомлень, щоб відтворити систему міксування монет поза ланцюжком, схожу на оригінальну функціональність