Підпис адаптера та його застосування в крос-ланцюговому атомному обміні

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

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

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

Технологія крос-ланцюгового атомарного обміну в основному включає дві основні складові: на основі хеш-часового замка (HTLC) та на основі підпису адаптера. Атомарний обмін за допомогою HTLC має проблему витоку конфіденційності. Атомарний обмін на основі підпису адаптера замінив скрипти на ланцюзі, зменшивши обсяг, що займається на ланцюзі, та забезпечивши незв'язність транзакцій, тим самим захищаючи конфіденційність.

У цій статті будуть представлені принципи підпису адаптера Schnorr/ECDSA та крос-ланцюгового атомного обміну, проаналізовано проблеми безпеки випадкових чисел, що виникають у цих процесах, а також системні гетерогенні проблеми в крос-ланцюгових сценаріях, і запропоновано розв'язання. Наприкінці буде розглянуто розширене застосування підпису адаптера для реалізації неінтерактивного зберігання цифрових активів.

Підпис адаптера та крос-ланцюг атомарного обміну

Підпис адаптера Schnorr та атомарний обмін

Процес попереднього підписання адаптера Schnorr виглядає так:

1. Аліса обирає випадкове число $r$, обчислює $R=r\cdot G$
2. Аліса обчислює $c=H(R||P_A||m)$
3. Аліса обчислює $\hat{s}=r+cx$
4. Аліса надіслала $(R,\hat{s})$ Бобу

Процес верифікації попередньо підписаного документа Бобом є наступним:

1. Bob обчислює $c=H(R||P_A||m)$
2. Боб перевіряє $\hat{s}\cdot G \stackrel{?} {=} R+c\cdot P_A$

Процес адаптації підпису для Alice виглядає наступним чином:

1. Аліса вибирає випадкове число $y$
2. Аліса обчислює $Y=y\cdot G$
3. Аліса обчислює $s=\hat{s}+y$
4. Аліса надіслала $(R,s,Y)$ Бобу

Процес підтвердження підпису Бобом виглядає наступним чином:

1. Bob обчислює $c=H(R||P_A||m)$
2. Боб перевіряє $s\cdot G\stackrel{?} {=} R+c\cdot P_A+Y$

Процес атомного обміну на основі адаптерних підписів Schnorr виглядає так:

1. Аліса створює транзакцію $T_A$, відправляє BTC Бобу
2. Боб створює транзакцію $T_B$, відправляючи BCH Алісі
3. Аліса проводить попереднє підписування $T_A$, отримує $(\hat{R}_A,\hat{s}_A)$, відправляє Бобу
4. Боб адаптує підпис для $T_B$, отримуючи $(R_B,s_B,Y)$, відправляє Алісі
5. Аліса перевіряє адаптивний підпис Боба, якщо він дійсний, то транслює $T_B$
6. Боб витягує $y$ з $T_B$, обчислює $s_A=\hat{s}_A+y$
7. Bob транслює $(R_A,s_A)$ завершено підписання $T_A$

ECDSA адаптер підпису та атомарний обмін

Процес попереднього підписання адаптера ECDSA виглядає наступним чином:

1. Аліса вибирає випадкове число $r$, обчислює $R=r\cdot G$
2. Еліс обчислює $c=H(R_x||P_A||m)$
3. Аліса обчислює $\hat{s}=r^{-1}(c+R_x\cdot x)$
4. Аліса відправила $(R,\hat{s})$ Бобу

Процес верифікації попереднього підпису Боба такий:

1. Bob обчислює $c=H(R_x||P_A||m)$
2. Боб перевіряє $R \stackrel{?} {=} c\cdot(\hat{s}\cdot G)^{-1}+R_x\cdot P_A\cdot(\hat{s}\cdot G)^{-1}$

Процес підготовки підпису для Аліси виглядає так:

1. Аліса вибирає випадкове число $y$
2. Аліса обчислює $Y=y\cdot G$
3. Аліса обчислює $s=\hat{s}+y$
4. Alice відправила $(R,s,Y)$ Бобу

Процес перевірки підпису Bob виглядає наступним чином:

1. Bob обчислює$c=H(R_x||P_A||m)$
2. Боб перевіряє $R \stackrel{?} {=} c\cdot(s\cdot G-Y)^{-1}+R_x\cdot P_A\cdot(s\cdot G-Y)^{-1}$

Процес атомарного обміну на основі підпису адаптера ECDSA подібний до Schnorr.

Підпис адаптера ECDSA також потребує доказу з нульовим знанням $\mathsf{zk}{r|\hat{R}=r\cdot G,R=r\cdot Y}$ для підтвердження того, що $R$ і $\hat{R}$ використовували однакове випадкове число $r$. Процес доказу виглядає так:

1. Prover вибирає випадкове число $v$, обчислює $\hat{V}=v\cdot G$ та $V=v\cdot Y$
2. Verifier генерує випадковий виклик $c$
3. Prover обчислює $z=v+cr$
4. Verifier Verify $z\cdot G\stackrel{?} {=} \hat{V}+c\cdot\hat{R}$ та $z\cdot Y \stackrel{?} {=} V+c\cdot R$

Питання та рішення

Проблема випадкових чисел та рішення

Проблема безпеки підпису адаптера Schnorr/ECDSA полягає в витоку та повторному використанні випадкових чисел:

1. Якщо випадкове число $r$ зливається, можна обчислити приватний ключ $x$ за допомогою рівняння підпису.
2. Якщо в двох транзакціях використовується однаковий випадковий номер $r$, можна отримати приватний ключ $x$, розв'язуючи систему рівнянь.

Рішення полягає у використанні стандарту RFC 6979, шляхом визначеного методу отримання випадкового числа з приватного ключа та повідомлення $k$:

$k = \mathsf{SHA256}(sk, msg, counter)$

Це забезпечує те, що підпис завжди є ідентичним, коли однакові повідомлення підписуються з використанням однакового приватного ключа, що посилює відтворюваність і безпеку.

проблеми та рішення для крос-ланцюгових сценаріїв

В моделі UTXO (, як у Bitcoin ), та в моделі рахунків (, як у Ethereum ), під час крос-ланцюгового обміну існує проблема системної гетерогенності. Рішенням є використання смарт-контрактів на ланцюгу моделі рахунків для реалізації логіки атомного обміну.

Коли два ланцюги використовують однакову криву, але різні алгоритми підпису, (, як один використовує ECDSA, а інший - Schnorr ), підпис адаптера все ще є безпечним.

Але якщо дві ланцюги використовують різні еліптичні криві, то не можна безпосередньо використовувати підпис адаптера для крос-ланцюгового обміну.

Застосування зберігання цифрових активів

Підпис адаптера може бути використаний для реалізації неінтерактивного зберігання цифрових активів. Конкретний процес виглядає наступним чином:

1. Аліса та Боб створюють фінансову транзакцію з виходом 2-of-2 MuSig
2. Аліса і Боб по черзі генерують підпис адаптера та шифрують секрет адаптера за допомогою публічного ключа керуючої сторони.
3. Аліса та Боб перевіряють зашифровані дані один одного, а потім підписують та транслюють фінансову транзакцію.
4. У разі виникнення суперечки, депозитарій може розшифрувати шифротекст для отримання adaptor secret, щоб допомогти одній стороні завершити угоду.

Ця схема не вимагає участі депозитарію в ініціалізації та не потребує публікації змісту контракту, має переваги неінтерактивності.

Доказова криптографія є ключовим компонентом цього рішення. Наразі існує два рішення на основі Secp256k1: Purify і Juggling. Purify базується на нульових знаннях, тоді як Juggling використовує методи шардінгу. Обидва рішення не мають значних відмінностей у продуктивності.

Підсумок

Ця стаття детально описує адаптерні підписи Schnorr/ECDSA та їх застосування в крос-ланцюгових атомних обмінах, аналізує пов'язані з цим проблеми безпеки та виклики крос-ланцюгових сценаріїв, а також надає відповідні рішення. Одночасно обговорюються розширені застосування адаптерних підписів у таких сферах, як зберігання цифрових активів. Адаптерні підписи пропонують ефективне, безпечне та конфіденційне технічне рішення для децентралізованих крос-ланцюгових транзакцій, і, ймовірно, відіграватимуть важливу роль у майбутній міжблокчейнній взаємодії.