Оригінальна назва: «Bitlayer Core Technology: DLC and Its Optimization Considerations»
Автори: lynndell & mutourend, Bitlayer Research Group
1. Введення
Discreet Log Contract (DLC) — це набір рішень для виконання контрактів на основі Oracle, запропонований Таджем Драйя з MIT у 2018 році. DLC дозволяє двом сторонам здійснювати умовні платежі на основі попередньо визначених умов. Кожна сторона визначає та заздалегідь підписує можливі результати та використовує ці попередні підписи для здійснення платежу, коли оракул підписує результати. Таким чином, DLC дозволяє використовувати нові децентралізовані фінансові програми, одночасно забезпечуючи безпеку депозитів Bitcoin.
Порівняно з Lightning Network DLC має такі вагомі переваги:
Конфіденційність: DLC перевершує Lightning Network з точки зору захисту конфіденційності. Деталі контракту надаються лише учасникам і не зберігатимуться в блокчейні. Навпаки, транзакції Lightning Network направляються через загальнодоступні канали та вузли, а їхня інформація є публічною та прозорою;
Складність і гнучкість фінансових контрактів: DLC може створювати та виконувати складні фінансові контракти безпосередньо в мережі біткойн, наприклад контракти на деривативи, страхування та азартні ігри, тоді як Lightning Network в основному використовується для швидких невеликих платежів і не може підтримувати складне застосування;
Зменшення ризику контрагента: кошти DLC заблоковані в контрактах з декількома підписами та будуть вивільнені лише після настання результатів попередньо визначених подій, що зменшує ризик невиконання будь-якою стороною умов контракту. Незважаючи на те, що Lightning Network зменшує потребу в довірі, все ще існує певний ризик контрагента з точки зору управління каналами та забезпечення ліквідності;
Немає необхідності керувати платіжними каналами: операції DLC не вимагають створення або обслуговування платіжних каналів, які є основним компонентом Lightning Network.
Масштабованість для конкретних випадків використання: Lightning Network певною мірою покращує пропускну здатність транзакцій Bitcoin, тоді як DLC забезпечує кращу масштабованість з точки зору складних контрактів на Bitcoin.
Незважаючи на те, що DLC має великі переваги в екологічних додатках біткойн, все ще існують певні ризики та проблеми, як-от:
Ключовий ризик: приватний ключ машини Oracle і обіцяне випадкове число ризикують бути витоком або втраченими, що призведе до втрати ресурсів користувача;
Централізований ризик довіри: проблеми з централізацією Oracle можуть легко призвести до атак на відмову в обслуговуванні;
Децентралізація запобігає виведенню ключів: якщо оракул децентралізований, вузол оракула володіє лише фрагментом приватного ключа. Однак децентралізовані вузли Oracle не можуть напряму використовувати BIP32 для отримання ключів на основі шардингу приватного ключа;
Ризик змови: якщо вузли оракула змовляються один з одним або змовляються зі сторонами-учасниками, проблема довіри машини оракула все ще не вирішена. Для мінімізації довіри до оракулів потрібен надійний механізм контролю;
Вирішена проблема зі зміною номіналу: умовні підписи вимагають детермінованого набору перелічуваних подій перед створенням контракту для створення транзакції. Таким чином, для DLC, які будуть використовуватися для перерозподілу активів, буде мінімальний ліміт суми, що призведе до проблеми зі зміною номіналу.
З цією метою ця стаття пропонує деякі рішення та ідеї оптимізації для вирішення ризиків і проблем DLC і покращення безпеки екосистеми Bitcoin.
2. Принцип DLC
Аліса та Боб підписують угоду про парі: вони роблять ставку на те, що хеш-значення n+k-го блоку є парним або непарним числом. Якщо це непарне число, Аліса виграє гру і може вилучити активи протягом t часу; якщо це парне число, Боб виграє гру і може вилучити активи протягом t часу. Використовуючи DLC, інформація про n+k-й блок передається через оракул для створення умовного підпису, щоб правильний переможець виграв усі активи.
Ініціалізація: генератором еліптичної кривої є G, а порядок – q.
Генерація ключів: Оракул, Аліса та Боб незалежно один від одного генерують власні приватні та відкриті ключі.
Приватним ключем машини оракула є z, а відкритим ключем є Z, що задовольняє співвідношення Z=z⋅G;
Приватним ключем Аліси є x, а її відкритим ключем є X, що задовольняє співвідношення X=x⋅G;
Приватним ключем Боба є y, а його відкритим ключем є Y, що задовольняє співвідношення Y=y⋅G.
Транзакція вливання капіталу: Аліса та Боб разом створюють транзакцію вливання капіталу, кожен з яких блокує 1 BTC у виході мультипідпису 2 із 2 (один відкритий ключ X належить Алісі, а один відкритий ключ Y належить Бобу).
Трансакція виконання контракту: Аліса та Боб створюють дві транзакції виконання контракту (CET) для транзакцій із вкладенням капіталу.
Зобов'язання Oracle Computes
$R:=k ⋅ G$
Потім обчисліть S і S'
$S:=R-хеш(Непарне число,R) ⋅ Z,$
$S':=R-хеш(парне число,R) ⋅ Z$
трансляція (R, S, S').
Аліса та Боб обчислюють кожен відповідний новий відкритий ключ
$PK^{Аліса}:=X+ S,$
$PK^{Bob}:=Y+ S'.$
Розрахунок: коли з’являється n+k-й блок, машина Oracle генерує відповідні s або s' на основі хеш-значення блоку.
Якщо хеш-значення n+k блоку непарне, оракул обчислює та транслює s
$s:=k-хеш(Непарне число,R) ⋅ z$
Якщо хеш-значення n+k блоку парне, оракул обчислює та транслює s'
$s':=k-хеш(парне число,R) ⋅ z$
Зняти монети: один із учасників, Аліса чи Боб, може вивести активи на основі s або s', які транслює оракул.
Якщо оракул передає s, Аліса може обчислити новий закритий ключ sk^{Alice} і вилучити заблоковані 2 BTC
$sk^{Alice}:= x + s.$
Якщо оракул передає s', Боб може обчислити новий закритий ключ sk^{Bob} і вилучити заблоковані 2 BTC
$sk^{Bob}:= y + s'.$
Аналіз: новий приватний ключ sk^{Alice}, обчислений Алісою, і новий відкритий ключ PK^{Alice} задовольняють співвідношення дискретного логарифму
$sk^{Аліса} ⋅ G= (x+s) ⋅ G=X+S=PK^{Аліса}$
У цьому випадку виведення валюти Аліси пройде успішно.
Таким же чином, новий приватний ключ sk^{Bob}, обчислений Бобом, і новий відкритий ключ PK^{Bob} задовольняють співвідношення дискретного логарифму.
$sk^{Bob} ⋅ G= (y+s') ⋅ G=Y+S'=PK^{Bob}$
У цьому випадку вихід Боба буде успішним.
Крім того, якщо оракул транслює s, це корисно Алісі, але не Бобу. Оскільки Боба не можна використовувати для обчислення відповідного нового закритого ключа sk^{Bob}. Таким же чином, якщо оракул передає s', це корисно Бобу, але не Алісі. Оскільки Аліса не може бути використана для обчислення відповідного нового закритого ключа sk^{Alice}.
Нарешті, у наведеному вище описі відсутні часові блокування. Необхідно додати блокування часу, щоб одна сторона могла обчислити новий закритий ключ і вилучити валюту протягом часу t. В іншому випадку, якщо час t перевищено, інша сторона може вилучити активи за допомогою оригінального закритого ключа.
3. Оптимізація DLC
3.1 Керування ключами
У протоколі DLC приватний ключ оракула та обіцяне випадкове число є вирішальними. Якщо закритий ключ оракула та обіцяне випадкове число витік або втрачено, це легко призведе до наступних чотирьох проблем безпеки:
(1) Машина Oracle втрачає закритий ключ z
Якщо оракул втрачає приватний ключ, DLC не може бути врегульовано, що призводить до необхідності виконати договір відшкодування DLC. Таким чином, у протоколі DLC налаштовується транзакція відшкодування, щоб запобігти втраті оракулом свого закритого ключа.
(2) Машина Oracle витікає закритого ключа z
У разі витоку приватного ключа оракула всі DLC, засновані на цьому приватному ключі, піддаються ризику шахрайського врегулювання. Зловмисник, який викрадає закритий ключ, може підписати будь-яке повідомлення, яке захоче, досягаючи повного контролю над результатом усіх майбутніх контрактів. Крім того, зловмисник не обмежується публікацією одного підписаного повідомлення, але також може публікувати конфліктні повідомлення, наприклад підписувати n+k-й блок непарними та парними хешами одночасно.
(3) Машина оракула витікає або повторно використовує випадкове число k
Якщо оракул витікає випадкове число k, то під час фази розрахунку, незалежно від того, транслює оракул s або s', зловмисник може обчислити закритий ключ z оракула наступним чином
$z:=(k-s)/хеш(Непарне число, R)$
$z:=(k-s')/hash(EvenNumber, R)$
Якщо машина оракула повторно використовує випадкове число k, то після двох розрахунків зловмисник може розв’язати систему рівнянь відповідно до сигнатури, переданої машиною оракула, і одну з наступних чотирьох ситуацій, щоб отримати закритий ключ z машини оракула,
Випадок 1:
$s_1=k-хеш(Непарне_1, R) ⋅ z$
$s_2=k-хеш(Непарне_2, R) ⋅ z$
Випадок 2:
$s_1'=k-хеш(парне число_1, R) ⋅ z$
$s_2'=k-хеш(парне число_2, R) ⋅ z$
Випадок 3:
$s_1=k-хеш(Непарне_1, R) ⋅ z$
$s_2'=k-хеш(парне число_2, R) ⋅ z$
Випадок 4:
$s_1'=k-хеш(парне число_1, R) ⋅ z$
$s_2=k-хеш(Непарне_2, R) ⋅ z$
(4) Машина-оракул втрачає випадкове число k
Якщо оракул втрачає випадкове число k, відповідний DLC не може бути врегульований, і необхідно виконати договір повернення DLC.
Таким чином, щоб підвищити безпеку закритого ключа Oracle, BIP32 слід використовувати для отримання дочірнього ключа або ключа онука для підпису. Крім того, щоб підвищити безпеку випадкового числа, хеш-значення k:=hash(z, лічильник) закритого ключа та лічильника слід використовувати як випадкове число k, щоб запобігти повторенню чи втраті випадкового числа.
3.2 Децентралізований Oracle
У DLC вирішальною є роль оракула, який надає ключові зовнішні дані, які визначають результат контракту. Для підвищення безпеки цих контрактів потрібні децентралізовані оракули. На відміну від централізованих оракулів, децентралізовані оракули розподіляють відповідальність за надання точних і захищених від втручання даних між кількома незалежними вузлами, що може зменшити ризик покладатися на єдину точку збою та зменшити можливість маніпуляцій або цілеспрямованих атак. Завдяки децентралізованим оракулам DLC може досягти вищого ступеня надійності та надійності, гарантуючи, що виконання контракту повністю покладається на об’єктивність заздалегідь визначених умов.
Порогові підписи Шнорра можуть реалізувати децентралізовані оракули. Порогові підписи Шнорра мають такі переваги:
Покращена безпека: порогові підписи зменшують ризик поодиноких збоїв завдяки децентралізованому управлінню ключами. Навіть якщо ключі деяких учасників витікають або атакуються, вся система залишається в безпеці, доки встановлений поріг не перевищено.
Розподілений контроль: пороговий підпис реалізує розподілений контроль над керуванням ключами. Жодна сутність не має повної повноважень підпису, таким чином зменшуючи ризик, спричинений надмірною концентрацією повноважень.
Покращена доступність: лише певна кількість вузлів Oracle повинна погодитися на завершення підпису, що покращує гнучкість і доступність системи. Навіть якщо деякі вузли будуть недоступні, це не вплине на надійну роботу всієї системи.
Гнучкість і масштабованість: протокол порогового підпису може встановлювати різні порогові значення за потреби для адаптації до різних вимог безпеки та сценаріїв. Крім того, він також підходить для великих мереж і має хорошу масштабованість.
Підзвітність: кожен вузол оракула генерує фрагменти підпису для повідомлень на основі фрагментів закритого ключа, а інші учасники можуть використовувати відповідні фрагменти відкритого ключа для перевірки правильності фрагментів підпису для досягнення підзвітності. Якщо правильно, фрагменти підпису накопичуються для створення повного підпису.
Таким чином, протокол порогового підпису Schnorr має значні переваги в децентралізованих оракулах, які покращують безпеку, надійність, гнучкість, масштабованість і підзвітність.
3.3 Поєднання децентралізації та керування ключами
У технології керування ключами оракул має повний ключ z. На основі повного ключа z і приросту ω, використовуючи BIP32, він може видавати велику кількість підключів z+{ω }^{(1)} і великих ключів. z+ω ^{(1)}+ω ^{(2)}. Для різних подій оракул може використовувати різні великі приватні ключі z+ω ^{(1)}+ω ^{(2)} для створення відповідного підпису σ для відповідного повідомлення про подію.
У сценарії децентралізованої програми Oracle є n учасників, і t+1 учасники повинні виконувати порогові підписи. Серед них т. Кожен з n вузлів оракула має фрагмент закритого ключа z_i, i=1,...,n. Ці n фрагментів закритого ключа z_i відповідають повному закритому ключу z, але повний закритий ключ z не відображається від початку до кінця. За припущення, що повний приватний ключ z не відображається, t+1 вузлів oracle використовують фрагменти приватного ключа z_i, i=1,...,t+1 для генерації фрагментів підпису σ_i' для повідомлення msg' і фрагментів підпису σ_i' об'єднується в повну сигнатуру σ '. Верифікатор може перевірити правильність пари підписів повідомлення (msg',σ '), використовуючи повний відкритий ключ Z. Оскільки для спільного створення порогового підпису потрібно t+1 вузлів oracle, він має високий рівень безпеки.
Однак у сценарії децентралізованої програми Oracle повний закритий ключ z не відображається, і BIP32 не можна використовувати безпосередньо для отримання ключа. Іншими словами, технологія децентралізації Oracle і технологія керування ключами не можуть бути безпосередньо пов’язані.
У статті Розподілене виведення ключів для багатостороннього управління цифровими активами блокчейну пропонується розподілений метод виведення ключів у сценарії порогового підпису. Основна ідея цієї статті полягає в тому, що згідно з інтерполяційним поліномом Лагранжа фрагмент закритого ключа z_i та повний закритий ключ z задовольняють наступному інтерполяційному співвідношенню
Додавши приріст ω до обох частин наведеного вище рівняння, ми отримаємо таке рівняння
Це рівняння показує, що: фрагмент закритого ключа z_i плюс приріст ω все ще задовольняє співвідношення інтерполяції з повним закритим ключем z плюс приріст ω. Іншими словами, фрагмент підприватного ключа z_i+ω і підключ z+ω задовольняють взаємозв’язку інтерполяції. Таким чином, кожен учасник може використовувати фрагмент закритого ключа z_i плюс приріст ω, щоб отримати фрагмент субприватного ключа z_i+ω, який використовується для створення фрагментів субпідпису, і може використовувати відповідний субвідкритий ключ Z+ω ⋅ G Перевірка дійсності.
Однак слід розглянути розширений і нерозширений BIP32. Enhanced BIP32 приймає закритий ключ, ланцюжковий код і шлях як вхідні дані, обчислює SHA512 і виводить приріст і код підланцюжка. Нерозширений BIP32 приймає відкритий ключ, ланцюжковий код і шлях як вхідні дані, обчислює SHA512 і виводить приріст і код підланцюжка. У випадку порогового підпису закритий ключ не існує, тому можна використовувати лише нерозширений BIP32. Або використовуйте гомоморфну хеш-функцію, є розширений BIP32. Однак гомоморфна хеш-функція відрізняється від SHA512 і несумісна з оригінальним BIP32.
3.4 OP-DLC: мінімізація довіри Oracle
У DLC договір між Алісою та Бобом виконується на основі результату підпису оракула, тому оракулу потрібно до певної міри довіряти. Таким чином, правильна поведінка машини Oracle є основною передумовою для роботи DLC.
Щоб не довіряти оракулам, були проведені дослідження щодо виконання DLC на основі результатів n оракулів, щоб зменшити залежність від одного оракула.
Модель «n-of-n» означає використання n оракулів для підписання контракту та виконання контракту на основі результатів n оракулів. Ця модель потребує n оракулів, щоб усі підписали онлайн. Якщо оракул виходить з мережі або має розбіжності щодо результатів, це вплине на виконання контракту DLC. Припущення довіри полягає в тому, що всі п оракули чесні.
Модель «k-of-n» означає використання n оракулів для підписання контракту та виконання контракту на основі результатів k оракулів. Якщо в змову вступить більше к оракулів, це вплине на чесне виконання контракту. Крім того, при використанні моделі «k-of-n» кількість CET, які потрібно підготувати, у C_n^k разів перевищує кількість одного оракула або моделі «n-of-n». Припущення довіри полягає в тому, що принаймні k оракулів з n оракулів є чесними.
Збільшення кількості машин-оракулів не призводить до недовіри до машин-оракулів. Тому що, коли оракул робить щось погане, потерпіла сторона в контракті не має каналу оскарження в ланцюжку.
Тому в цьому розділі пропонується OP-DLC, який представляє оптимістичний механізм виклику в DLC. Перед тим, як оракули візьмуть участь у створенні DLC, вони повинні заздалегідь пообіцяти створити бездозвільну мережеву OP гру та пообіцяти не робити зла. Якщо будь-який оракул робить зло, Аліса чи Боб, або будь-який інший чесний оракул чи інший сторонній чесний спостерігач може ініціювати виклик. Якщо претендент виграє гру, злого оракула буде покарано на ланцюжку, а його депозит буде втрачено. Крім того, OP-DLC також можна підписати за допомогою моделі "k-of-n". Серед них значення k може навіть дорівнювати 1. Таким чином, припущення про довіру зводиться до того, що якщо в мережі є чесний учасник, можна запустити виклик OP, щоб покарати злий вузол-оракул.
При розрахунку OP-DLC за результатами розрахунку Layer2:
Якщо оракул використовує неправильний підпис результату, завдаючи шкоди інтересам Аліси, Аліса може використати Рівень 2, щоб правильно обчислити результат і кинути виклик бездозвільній OP-грі в ланцюзі, заздалегідь обіцяній оракулом. Аліса виграє гру, карає злого оракула та компенсує програш;
Таким же чином Боб, інші чесні вузли оракула та сторонні чесні спостерігачі можуть ініціювати виклики. Однак, щоб запобігти зловмисним викликам, претендент також має зробити ставку.
Тому OP-DLC дозволяє вузлам Oracle контролювати один одного, мінімізуючи довіру Oracle. Для цього механізму потрібен лише один чесний учасник і рівень відмовостійкості становить 99%, що краще усуває ризик змови оракула.
3.5 Подвійний міст OP-DLC + BitVM
Якщо DLC використовується як перехресний міст, виділення коштів потрібне під час урегулювання контракту DLC:
Необхідно попередньо встановити CET. Це означає, що деталізація розрахунків коштів DLC обмежена, наприклад мережа Bison з деталією 0,1 BTC. Існує проблема: взаємодія активів користувачів на Рівні 2 не повинна обмежуватися деталізацією фонду DLC CET.
Коли Аліса хоче розрахуватися зі своїми активами Рівня 2, активи користувача Боба з Рівня 2 будуть змушені бути розраховані на Рівні 1. Існує проблема: кожен користувач Рівня 2 повинен мати можливість вільно вибирати внесення та зняття коштів без впливу на депозити та зняття інших користувачів.
Аліса та Боб домовляються про вартість. Є проблема: обидві сторони повинні бути готові співпрацювати.
Тому для вирішення вищезгаданих проблем у цьому розділі пропонується подвійний міст OP-DLC + BitVM. Це рішення дозволяє користувачам вносити та знімати гроші через міст без дозволу BitVM, а також вносити та знімати гроші через механізм OP-DLC, досягаючи зміни з будь-якою деталізацією та покращуючи ліквідність капіталу.
В OP-DLC оракул — BitVM Alliance, Аліса — звичайний користувач, а Боб — BitVM Alliance. Під час налаштування OP-DLC у створеному CET вихідні дані, надані користувачеві Алісі, можуть бути використані негайно на Layer1, а у вихідних даних, наданих Бобу, створюється «гра DLC, у якій Аліса може брати участь у виклику» та блокується час встановлюється період блокування. Коли Аліса хоче зняти гроші:
Якщо BitVM Alliance діє як оракул і правильно підписує, Аліса може зняти гроші на рівні 1. Однак Боб може зняти гроші на рівні 1 після закінчення періоду блокування.
Якщо BitVM Alliance діє як оракул і обманює, інтересам Аліси буде завдано шкоди. Однак Аліса може оскаржити UTXO Боба. Якщо виклик буде успішним, суму Боба можна конфіскувати. Примітка: хтось із інших членів BitVM Alliance також може ініціювати виклик, але Аліса найбільше мотивована ініціювати виклик, оскільки її інтересам завдано шкоди.
Якщо BitVM Alliance діє як оракул і шахраює, інтересам Боба буде завдано шкоди. Однак чесний член BitVM Alliance може кинути виклик «грі BitVM» і покарати шахрайські вузли оракула.
Крім того, коли користувач Аліса хоче зняти кошти з рівня 2, але попередньо встановлений CET у контракті OP-DLC не відповідає сумі, Аліса може вибрати такі методи:
Знімайте гроші через BitVM і передавайте їх на Layer1 оператором BitVM. Міст BitVM передбачає чесного учасника альянсу BitVM.
Зніміть гроші через певний CET в OP-DLC, а залишок здачі буде передано оператором BitVM на рівні 1. Зняття OP-DLC закриє канал DLC, але кошти, що залишилися в каналі DLC, будуть переведені в пул коштів BitVM Layer1, не змушуючи інших користувачів Layer2 знімати кошти. Містова довіра OP-DLC передбачає, що в каналі є чесний учасник.
Аліса та Боб домовляються про вартість без участі машини-оракула, вимагаючи від Боба співпраці.
Таким чином, подвійний міст OP-DLC + BitVM має такі переваги:
Використання BitVM вирішує проблему зміни коштів каналу DLC, зменшує кількість налаштувань CET і не впливає на деталізацію коштів CET;
Поєднання мосту OP-DLC і мосту BitVM надає користувачам кілька каналів зняття коштів і депозитів, а також зміни з будь-якою деталізацією;
Встановіть альянс BitVM для Боба та оракула та мінімізуйте довіру оракула через механізм OP;
Введіть баланс вилучення каналу DLC у пул капіталу мосту BitVM, щоб покращити використання капіталу.
4. Висновок
DLC з’явилося до активації Segwit v1 (Taproot), було реалізовано інтеграцію DLC-каналу та Lightning Network, а також DLC було розширено для оновлення та виконання безперервних контрактів у межах одного DLC-каналу. За допомогою таких технологій, як Taproot і BitVM, можна досягти складнішої перевірки та врегулювання контрактів поза мережею в DLC, а в поєднанні з механізмом виклику OP можна досягти мінімізації довіри Oracle.
Список літератури
Специфікація для контрактів Discreet Log
Дискретні договори журналу
Масштабування DLC Частина 1: Контракти дискретного журналу поза мережею
Масштабування DLC Part2: Проблема з безкоштовними опціями DLC
Масштабування DLC Part3: Як уникнути проблеми з безкоштовними опціями DLC
Мережа Lightning
DLC на Lightning
DLC Керування закритим ключем Частина 1
DLC Private Key Management Part 2: Приватні ключі Oracle
DLC Key Management Pt 3: Oracle Public Key Distribution
BitVM: обчислюйте будь-що на біткойнах
BitVM 2: перевірка біткойнів без дозволу
Биткойн-контракти поза ланцюгом BitVM
BIP32 BIP44
Підпис Шнорра
FROST: гнучкі оптимізовані круглі порогові підписи Шнорра
Опитування порогового підпису ECDSA
Розподілена деривація ключів для багатостороннього управління цифровими активами блокчейну
Сегрегований свідок
Оптимістичний збір
Стрижневий корінь
