1. Вступ

Discreet Log Contract (DLC) - це фреймворк виконання контрактів на основі Oracle, запропонований Тедж Драйєю з Массачусетського технологічного інституту в 2018 році. DLC дозволяє двом сторонам виконувати умовні платежі на основі попередньо визначених умов. Сторони визначають можливі результати, попередньо підписують їх і використовують ці попередні підписи для виконання платежів, коли Oracle підтверджує результат. Таким чином, DLC дозволяє створювати нові децентралізовані фінансові додатки, забезпечуючи при цьому безпеку депозитів Bitcoin.

У порівнянні з мережею Lightning, DLC має наступні значні переваги:

• Конфіденційність: DLC пропонує кращий захист конфіденційності, ніж Мережа Lightning. Деталі контракту діляться лише між сторонами, які беруть участь, і не зберігаються в блокчейні. Натомість транзакції у Мережі Lightning маршрутизуються через відкриті канали та вузли, роблячи їхню інформацію публічною та прозорою.
• Складність та гнучкість фінансових контрактів: DLC може безпосередньо створювати та виконувати складні фінансові контракти в мережі Bitcoin, такі як деривативи, страхування та ставки, тоді як мережа Lightning в основному використовується для швидких платежів невеликої вартості і не може підтримувати складні додатки.
• Зменшений ризик контрагентів: кошти DLC заблоковані в контрактах з багато підписами і вивільняються лише тоді, коли відбувається результат попередньо визначеного події, що зменшує ризик того, що будь-яка сторона не дотримується контракту. Хоча мережа Lightning зменшує потребу в довірі, вона все ще несе певні контрагентні ризики у керуванні каналом та забезпеченні ліквідності.
• Не потрібно керувати платіжними каналами: операції DLC не потребують створення або обслуговування платіжних каналів, які є центральними для мережі Lightning і потребують складного та ресурсозатратного управління.
• Масштабованість для конкретних випадків використання: Хоча Мережа Блискавок трохи збільшує пропускну здатність транзакцій Bitcoin, DLC пропонує кращу масштабованість для складних контрактів на Bitcoin.

Хоча DLC мають значні переваги в екосистемі Bitcoin, все ще існують певні ризики та проблеми, такі як:

• Ключовий ризик: існує ризик витоку або втрати приватних ключів Oracle та зобов'язаних номерів, що призводить до втрати активів користувача.
• Ризик централізованої довіри: Централізація в Оракулах легко може призвести до атак на відмову в обслуговуванні.
• Проблема децентралізованого похідного ключа: Якщо Оракул децентралізований, то вузли Оракула мають лише частки приватного ключа. Однак децентралізовані вузли Оракула не можуть безпосередньо використовувати BIP32 для похідного ключа на основі цих часткових приватних ключів.
• Ризик змови: Якщо вузли Oracle співпрацюють між собою або з однією стороною, проблема довіри до Оракулів залишається невирішеною. Потрібен надійний механізм моніторингу для мінімізації довіри до Оракулів.
• Проблема зміни фіксованої номінальної величини: Умовні підписи потребують детермінованого, перераховуваного набору подій перед побудовою контракту для створення транзакції. Тому використання 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): Еліс та Боб створюють дві CET для витрачання транзакції фінансування.

Оракул обчислює зобов'язання

а потім обчислює S та S′

та трансляція (R, S, S′).

Аліса та Боб кожен обчислюють відповідний новий відкритий ключ

Розрахунок: після появи (n+k)-го блоку Оракул генерує відповідний s або s′ на основі значення хешу цього блоку.

• Якщо хеш-значення (n+k)-го блоку є непарним, Оракул обчислює та транслює

• Якщо хеш-значення (n+k)-го блоку парне, Оракул обчислює та розсилає

Виведення: Аліса або Боб можуть вивести активи на основі s або s′, які були передані Оракулом.

• Якщо Оракул транслює s, Еліс може обчислити новий приватний ключ sk^{Alice} і вибрати заблоковані 2 BTC

• Якщо Оракул транслює s′, Боб може обчислити новий приватний ключ sk^{Bob} та вивести заблоковані 2 BTC

Аналіз: Новий приватний ключ sk^{Alice}, розрахований Алісою, та новий відкритий ключ PK^{Alice} задовольняють відношення дискретного логарифма

Таким чином, виведення Еліс буде успішним.

Так само, новий приватний ключ sk^{Bob}, розрахований Бобом, та новий відкритий ключ 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) Витік або повторне використання Nonce k від Oracle

Якщо Оракул витікає номер k, то на етапі врегулювання, незалежно від того, чи передає Оракул s або s′, атакуючий може розрахувати приватний ключ Оракула z наступним чином:

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

case 1:

case 2:

case 3:

case 4:

(4) Oracle Втрачає Nonce k

Якщо Оракул втрачає номер k, відповідний DLC не може розрахуватися, що вимагає виконання контракту на повернення DLC.

Отже, щоб підвищити безпеку приватного ключа Oracle, рекомендується використовувати BIP32 для похідних або онукових ключів для підпису. Крім того, для підвищення безпеки одноразового значення, хеш-значення k:=hash(z, counter) слід використовувати як одноразове значення k, щоб уникнути повторення або втрати одноразового значення.

3.2 Децентралізований Оракул

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

Порогові підписи Шнорра можуть бути використані для впровадження децентралізованих Оракулів. Порогові підписи Шнорра пропонують наступні переваги:

• Підвищена безпека: Розподіляючи управління ключами, порогові підписи зменшують ризик виникнення однієї точки відмови. Навіть якщо ключі деяких учасників будуть скомпрометовані або атаковані, весь система залишається безпечною, якщо порушення не перевищує заздалегідь встановленого порогу.
• Розподілений контроль: Порогові підписи дозволяють розподілений контроль над управлінням ключами, усуваючи можливість того, що одна єдина сутність утримує всі права на підписування, тим самим зменшуючи ризики, пов'язані з концентрацією влади.
• Покращена доступність: Підписи можуть бути завершені, якщо певна кількість вузлів Oracle погоджується, що підвищує гнучкість та доступність системи. Навіть якщо деякі вузли недоступні, надійність загальної системи не постраждає.
• Гнучкість та масштабованість: Протокол підпису порога може встановлювати різні пороги за потреби, щоб відповідати різним вимогам щодо безпеки та сценаріям. Крім того, він підходить для мереж великого масштабу та має хорошу масштабованість.
• Відповідальність: Кожен вузол Оракула генерує частку підпису на основі своєї приватної ключової частки, і інші учасники можуть перевірити правильність цієї частки підпису, використовуючи відповідну публічну ключову частку, що забезпечує відповідальність. Якщо правильно, ці частки підпису накопичуються для створення повного підпису.

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

3.3 Зв'язок децентралізації та управління ключами

У технології управління ключами Oracle має повний ключ z і, використовуючи BIP32 разом з приростами ω, може отримати множину дочірніх ключів z+ω^{(1)} та онуківських ключів z+ω^{(1)}+ω^{(2)}. Для різних подій Oracle може використовувати різні онуківські приватні ключі z+ω^{(1)}+ω^{(2)} для генерації відповідних підписів σ для відповідних подій msg.

У децентралізованому сценарії Оракулу є n учасників, і для підпису порогу потрібно t+1 учасників, де t

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

Стаття "Розподілений похідний ключ для багатостороннього управління цифровими активами блокчейну«Пропонує розподілену схему виведення ключа в сценаріях підпису порогового значення. Основна ідея ґрунтується на поліномах інтерполяції Лагранжа, де приватна частка ключа z_i та повний приватний ключ z задовольняють наступний відношення інтерполяції:

Додавання приросту ω до обох сторін рівняння дає:

Це рівняння показує, що приватний ключ частка z_i плюс приріст ω все ще задовольняє відношення інтерполяції з повним приватним ключем z плюс ω. Іншими словами, дочірній приватний ключ частка z_i+ω та дочірній ключ z+ω задовольняють відношенням інтерполяції. Тому кожен учасник може використовувати свою приватну ключову частку z_i плюс приріст ω для похідної приватної ключової частки z_i+ω, яку використовує для генерації часток підпису та перевірки їх за допомогою відповідного дочірнього публічного ключа Z+ω⋅G.

Проте слід взяти до уваги зміцнені та незміцнені BIP32. Зміцнений BIP32 бере приватний ключ, код ланцюжка та шлях як вхідні дані, виконує SHA512 та виводить приріст та дитячий код ланцюжка. Незміцнений BIP32, з іншого боку, бере публічний ключ, код ланцюжка та шлях як вхідні дані, виконує SHA512 та виводить приріст та дитячий код ланцюжка. У сценарії підпису порогової вартості приватний ключ не існує, тому можна використовувати лише незміцнений BIP32. Або, використовуючи гомоморфну хеш-функцію, можна застосовувати зміцнений BIP32. Однак гомоморфна хеш-функція відрізняється від SHA512 та несумісна з оригінальним BIP32.

3.4 OP-DLC: Oracle Trust-minimized

У DLC контракт між Алісою та Бобом виконується на основі підписаного результату Оракула, що вимагає певного рівня довіри до Оракула. Тому правильна поведінка Оракула - це головна передумова для функціонування DLC.

Для зменшення довіри до Оракула було проведено дослідження з виконання DLC на основі результатів n Оракулів, зменшуючи залежність від одного Оракула.

• Модель "n-з-n" передбачає використання n Оракулів для підпису контракту та виконання контракту на підставі результатів всіх Оракулів. Ця модель передбачає, що всі Оракули повинні бути онлайн для підпису. Якщо який-небудь Оракул вийде з мережі або буде розбіжність в результатах, це впливає на виконання контракту DLC. Тут припущення довіри полягає в тому, що всі Оракули є чесними.
• Модель “k-of-n” передбачає використання n оракулів для підписання контракту, виконання контракту на підставі результатів будь-яких k оракулів. Якщо співпрацюють більше, ніж k оракулів, це впливає на справедливе виконання контракту. Крім того, кількість CETs, потрібних у моделі “k-of-n”, в C_n^k разів перевищує кількість одного Оракула або моделі “n-of-n”. Припущення про довіру в цій моделі полягає в тому, що принаймні k з n Оракулів є чесними.

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

Таким чином, ми пропонуємо OP-DLC, який включає оптимістичний механізм виклику в DLC. Перед участю в налаштуванні DLC n Оракули повинні заставити і створити дозволений онлайн-OP-гру наперед, зобов'язуючись не діяти зловмисно. Якщо будь-який Оракул діє зловмисно, то Еліс, Боб, будь-який інший чесний Оракул або будь-який інший чесний спостерігач-спостерігач може ініціювати виклик. Якщо викликач перемагає в грі, система на ланцюжку покарає зловмисний Оракул, конфіскуючи його депозит. Додатково, OP-DLC також може прийняти модель «k-of-n» для підпису, де значення k може бути навіть 1. Таким чином, припущення про довіру зводиться до необхідності лише одного чесного учасника в мережі для ініціювання OP виклику та покарання зловмисного вузла Оракула.

При розрахунку OP-DLC на основі результатів обчислень рівня 2:

• Якщо Оракул підписується з неправильними результатами, що призводить до збитків для Еліс, Еліс може використовувати правильні результати обчислень на рівні 2 для виклику на гру Оракула з підвищеним дозволом без дозволу на ланцюжку OP. Виграючи гру, Еліс може покарати зловживання Оракула та компенсувати свої збитки.
• Так само, Боб, інші чесні вузли Oracle та чесні спостерігачі з третіх сторін також можуть ініціювати виклики. Однак, щоб запобігти зловмисним викликам, викликач також повинен зобов'язатися.

Отже, OP-DLC сприяє взаємному контролю серед вузлів оракулів, мінімізуючи довіру, яка надається оракулам. Цей механізм вимагає лише одного чесного учасника та має 99% витривалість до відмов, ефективно вирішуючи ризик колюсії оракулів.

3.5 OP-DLC + БітVM Двохпрохідний міст

Коли використовується DLC для крос-ланцюжкових мостів, розподіл коштів повинен відбуватися під час укладення договору DLC:

• Для цього потрібно попередньо встановити через CET, що означає, що гранулярність розрахунків фондів DLC обмежена, наприклад, 0,1 BTC в мережі Bison. Це породжує проблему: взаємодія активів 2-го рівня для користувачів не повинна обмежуватися гранулярністю фондів CET DLC.
• Коли Еліс хоче вирішити свою активи Layer 2, це змушує вирішити активи користувача Боба Layer 2 на рівень 1. Це породжує проблему: кожен користувач Layer 2 повинен мати можливість вибирати свої депозити та виводи незалежно від дій інших користувачів.
• Аліса і Боб ведуть перемови про витрати. Тут проблема полягає в тому, що це вимагає готовності обох сторін співпрацювати.

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

У OP-DLC Oracle — це федерація BitVM, де Аліса є звичайним користувачем, а Боб — федерацією BitVM. При налаштуванні OP-DLC, побудовані CET дозволяють негайно витрачати вихідні дані Аліси на рівень 1, в той час як вихідні дані Боба включають «DLC-гру, яку Аліса може кинути виклик» з періодом блокування часу. Коли Аліса хоче вивести кошти:

• Якщо федерація BitVM, діючи як Оракул, підписує правильно, Еліс може зняти на Шарі 1. Однак Боб може зняти на Шарі 1 після періоду затримки часу.
• Якщо федерація BitVM, діючи як Оракул, обманює, призводячи до втрат для Еліс, вона може викликати UTXO Боба. Якщо виклик виявиться успішним, сума Боба може бути конфіскована. Зауважте: ще один член федерації BitVM також може ініціювати виклик, але Еліс, яка є ображеною стороною, найбільше мотивована зробити це.
• Якщо федерація BitVM, діючи як Оракул, обманює, що призводить до втрати для Боба, чесний член федерації BitVM може викликати "гру BitVM" для покарання обманюючого вузла Оракула.

Крім того, якщо користувач Аліса хоче знятися з рівня 2, але заздалегідь встановлені CET у контракті OP-DLC не відповідають сумі, Аліса може вибрати наступні методи:

• Виведення через BitVM, з оператором BitVM, що фронтить суму на Рівні 1. Міст BitVM вважає, що в федерації BitVM є принаймні один чесний учасник.
• Зняття через конкретний CET в OP-DLC, з рештою здачі, наданою оператором BitVM на рівні 1. Зняття через OP-DLC закриє канал DLC, але залишкові кошти в каналі DLC перейдуть до пулу BitVM рівня 1, не змушуючи інших користувачів рівня 2 знімати. Міст OP-DLC передбачає, що в каналі є принаймні один чесний учасник.
• Еліс та Боб узгоджують витрати без залучення Оракула, потребує співпраці з Бобом.

Отже, подвійний міст OP-DLC + BitVM має наступні переваги:

• BitVM вирішує проблему зміни каналу DLC, зменшує кількість необхідних CET та не піддається впливу від дрібності фонду CET;
• Поєднуючи міст OP-DLC з мостом BitVM, він надає користувачам кілька каналів для зарахувань та виведень, покращуючи користувацький досвід;
• Встановлення консорціуму BitVM як Боба, так і оракула та використання механізму OP мінімізує довіру до оракула;
• Інтегруючи зайвий виведення з каналу DLC в басейн моста BitVM підвищує використання коштів.

4. Висновок

DLC виникло до активації Segwit v1 (Taproot) і вже було інтегровано з мережею Lightning, що дозволяє розширення DLC для оновлення та виконання постійних контрактів в межах одного того ж каналу DLC. З використанням технологій, таких як Taproot та BitVM, можна реалізувати більш складні перевірки та розрахунки контрактів поза ланцюжком у межах DLC. Крім того, шляхом інтеграції механізму виклику OP можливо зменшити довіру до Оракулів.

Заява:

1. Ця стаття перепечатана з середній, спочатку під назвою "Бітлейер Основна технологія: DLC та її оптимізаційні аспекти". Авторське право належить оригінальному автору, Бітлейер. Якщо є будь-які зауваження стосовно цього видруку, будь ласка, зв'яжіться з Команда Gate LearnКоманда буде вирішувати це відповідно до відповідних процедур якнайшвидше.

2. Попередження: Погляди та думки, висловлені у цій статті, відображають лише особисті погляди автора і не є жодним інвестиційним порадою.

3. Інші мовні версії статті були перекладені командою Gate Learn. Без згадки про Gate, перекладені статті не можуть бути скопійовані, поширені або ухвалені у власність.