By Bitcoin Журнал - 4 місяці тому - Час читання: 5 хвилини
Ртутний шар: величезне вдосконалення державних ланцюгів
CommerceBlock випускається Ртутний шар сьогодні це покращена версія їхньої варіації ланцюга станів. Ви можете прочитати розгорнуте пояснення того, як працюють їхні ланцюжки станів Mercury тут. Оновлення до Mercury Layer є значним покращенням у порівнянні з початковою реалізацією ланцюжка станів, однак, на відміну від початкового випуску Mercury Wallet, це не упаковано як гаманець, повністю готовий для споживача. Він випускається як бібліотека та інструмент CLI, який можуть інтегрувати інші гаманці. Ось короткий опис того, як вони працюють:
По суті, ланцюжки станів багато в чому аналогічні платіжним каналам, тобто вони є спільно використовуваним UTXO із попередньо підписаною транзакцією як механізмом останньої інстанції, за допомогою якого люди можуть захистити своє право власності. Основна відмінність між каналом Lightning і ланцюгом станів полягає в тому, які сторони беруть участь у спільному обміні UTXO, а також у тому, як право власності на позовну вимогу проти нього передається іншим сторонам.
На відміну від каналу Lightning, який створюється та використовується між двома статичними учасниками, ланцюжок станів відкривається фасилітатором/оператором і може вільно передаватись повністю між будь-якими двома учасниками, які готові довіряти оператору, щоб бути чесним, повністю вимкненим. - ланцюг. Хтось, хто бажає завантажити ланцюжок станів, співпрацює з оператором, щоб створити єдиний відкритий ключ, у якому і творець, і оператор володіють часткою відповідного закритого ключа, при цьому жоден не має повної копії ключа. Звідси вони попередньо підписують транзакцію, що дозволяє творцю вимагати назад свої монети після закінчення часу в односторонньому порядку.
Щоб передати ланцюжок станів, поточний власник співпрацює з одержувачем і оператором, щоб підписати криптографічний доказ за допомогою свого спільного ключа, що вони передають монету, а потім одержувач і оператор генерують нову пару спільних ключів, які складаються в той самий закритий ключ і підпис транзакція з тимчасовим блокуванням для нового власника з коротшим часовим блокуванням, ніж початкова (щоб гарантувати, що вони зможуть використати свою транзакцію раніше, ніж попередні власники). Цей процес повторюється для кожної передачі, доки тимчасове блокування більше не можна буде скоротити, після чого ланцюжок станів має бути закритий у ланцюжку.
Власники передають весь історичний ланцюжок минулих станів із кожною передачею, щоб користувачі могли перевірити, чи блокування часу належним чином зменшено, а оператор ставить на них позначки часу за допомогою Основна опора, варіант Opentimestamps, де кожна частина даних має власний унікальний «слот» у дереві Merkle, щоб гарантувати, що лише одна версія даних має позначку часу. Це дозволить кожному перевірити історію передачі ланцюга станів.
У Країні Сліпих
Великі зміни, які Mercury Layer вносить в оригінальну версію ланцюжків станів, засліплюють. Оператор служби ланцюга станів більше не зможе нічого дізнатися про те, що передається: наприклад, задіяні TXID, задіяні відкриті ключі, навіть підписи, які він співпрацює з користувачами для створення попередньо підписаних транзакцій, необхідних для повернення вимоги. свої кошти в односторонньому порядку.
Представляючи сліпий варіант Schnorr MuSig2, Mercury може спрощувати процес підписання транзакцій, не вивчаючи жодних деталей того, що вони підписують. Це вимагає деяких змін у дизайні, щоб врахувати той факт, що оператор більше не може бачити та публікувати всю історію передачі ланцюжка станів. Вони взагалі не в змозі підтвердити транзакцію, яку вони підписують.
У попередній ітерації унікальність поточного власника ланцюга станів/набору транзакцій була засвідчена оператором шляхом публікації всієї історії передачі ланцюга станів за допомогою Mainstay. Тут це неможливо, оскільки в сліпій версії оператор взагалі не дізнається подробиць про ці транзакції. Це вимагає нового способу підтвердження оператором поточної власності на ланцюжок станів. Усі ці дані повністю передаються в модель перевірки на стороні клієнта. Оператор просто відстежує, скільки разів він підписував щось для одного ланцюжка станів, і повідомляє користувачеві це число, коли його запитують. Потім користувач отримує транзакції минулого стану ланцюга станів від користувача, який йому надсилає, і повністю перевіряє на стороні клієнта, що кількість транзакцій відповідає заявленій оператором, а потім повністю перевіряє, що всі підписи дійсні, а блокування часу зменшено на відповідну кількість щоразу. Замість публікації повних транзакцій ланцюга станів і порядку передачі в Mainstay, оскільки він розроблений таким чином, щоб не знати всієї цієї інформації, він публікує свою частку відкритого ключа (а не повний сукупний відкритий ключ) для поточного користувача для кожного ланцюга станів користувача. Це дозволяє будь-якому користувачеві, який отримує ланцюжок станів, перевірити історію передачі та поточний стан на відповідність даним транзакцій, надісланим відправником.
Сервер оператора відстежує унікальні ланцюжки станів для підрахунку минулих підписів, призначаючи кожному ланцюжку станів випадковий ідентифікатор під час створення, який зберігається разом із його номіналом і частками закритого та відкритого ключів (а не всього сукупного відкритого ключа). Нова схема координації шардингу та повторного шардингу ключа виконується таким чином, що сервер передає свою частку ключа користувачеві, а дані, необхідні для повторного шардингу, закриваються, тому сервер не в змозі дізнатися повну інформацію користувача відкритий ключ, що дозволяє створити повний сукупний відкритий ключ і ідентифікувати монету в ланцюжку.
Конструкція навіть не дозволяє оператору знати, коли він підписав угоду про закриття співпраці з поточним власником, а не попередньо підписану транзакцію для нового власника поза мережею; він не бачить жодних деталей, щоб відрізнити два випадки один від одного. Однак це безпечно для користувачів, які можуть піддатися атаці з боку когось, хто намагається «подвоїти витрати» на ланцюжок держав, надаючи фальшиву транзакцію, яку неможливо здійснити. По-перше, цей користувач побачить у ланцюжку, що UTXO, що підтримує цей ланцюжок станів, витрачено. По-друге, історія транзакцій, оскільки оператор повинен підписувати всі оновлення стану, матиме лише чітке кооперативне закриття в ланцюжку минулих транзакцій. Обидві ці речі дозволять користувачеві відмовитися від транзакції, знаючи, що вона нелегітимна.
Зв’язки станів також дозволяють каналам Lightning «розміщуватись на вершині» ланцюга станів, забезпечуючи платіж з ланцюжка станів на адресу з кількома підписами між двома людьми, і вони двоє узгоджують звичайний набір транзакцій зобов’язань Lightning поверх нього. Потрібно було б закрити ланцюжок станів у ланцюжку перед закриттям каналу Lightning, тому для платежів Lightning потрібно було б використовувати довший час блокування, але іншіwise функціонував би цілком нормально.
Загалом із значними покращеннями конфіденційності нової ітерації ланцюжків станів і можливістю комбінування з Lightning це відкриває багато можливостей для економічної життєздатності та гнучкості механізмів транзакцій другого рівня на Bitcoin. Особливо в світлі нещодавніх радикальних змін у динаміці mempool і викликаного цим тиску комісії.
Він пропонує ті ж переваги щодо ліквідності, що й Ark, тобто можливість вільно передавати без необхідності отримання ліквідності, але на відміну від Ark живий і функціональний сьогодні. Це, безсумнівно, інша модель довіри, ніж щось на кшталт Lightning, але з огляду на величезні переваги в гнучкості та масштабованості, це безумовно можливість вивчити.
Оригінальний джерело: Bitcoin журнал