Обговорення принципів та оптимізаційних підходів технології DLC

1. Огляд

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

У порівнянні з Lightning Network, DLC має такі переваги:

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

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

• Ризики безпеки ключів
• Проблема централізації оракула
• Децентралізовані оракули не можуть безпосередньо виконувати похідні ключі
• Ризики змови оракула
• Обмеження на здачу фіксованого номіналу

У цій статті буде проаналізовано принципи DLC та запропоновано кілька оптимізаційних рішень для вирішення вищезазначених проблем.

2. Принцип роботи DLC

Приклад ставки між Алісою та Бобом щодо парності хеш-значення n+k-го блоку:

1. Ініціалізація: генерування параметрів еліптичної кривої

2. Генерація ключів: оракул, Аліса та Боб генерують свої приватні та публічні ключі

3. Інвестиційна транзакція: Аліса та Боб створюють інвестиційну транзакцію, кожен блокує 1 BTC в мультипідписному виході.

4. Виконання угоди: створити дві угоди виконання ( CET ) для витрат на інвестиційні угоди

5. Обчислення зобов'язання оракула: обчисліть R, S та S' і транслюйте

6. Аліса та Боб обчислюють новий публічний ключ

7. Розрахунок: Оракул генерує s або s' на основі хеш-значення блоку та транслює його

8. Виведення коштів: Переможець обчислює новий приватний ключ на основі s або s' та виводить активи

Крім того, потрібно додати механізм тайм-лок, щоб забезпечити, що одна сторона зможе вивести кошти в установлені терміни, інакше інша сторона зможе забрати активи за допомогою оригінального приватного ключа.

3. Оптимізація DLC

3.1 Управління ключами

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

1. Втрата приватного ключа оракула: неможливо здійснити розрахунок, потрібно виконати контракт на повернення коштів
2. Витік приватного ключа оракула: всі контракти піддаються ризику шахрайства
3. Витік або повторне використання випадкових чисел оракула: можна вивести приватний ключ
4. Втрата випадкового числа оракула: неможливо виконати конкретний контракт

Рекомендується вжити наступних заходів:

• Використовуйте BIP32 для похідних підключів або ключів онуків для підпису
• Використовуйте приватний ключ та хеш-значення лічильника як випадкове число

3.2 децентралізовані оракули

Використання порогового підпису Schnorr для реалізації децентралізованого оракула має такі переваги:

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

3.3 Децентралізація та управління ключами

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

• Використовуючи поліном Лагранжа для інтерполяції, фрагменти приватного ключа та повний приватний ключ задовольняють умови інтерполяції.
• Фрагментація приватного ключа та повний приватний ключ, після додавання приросту, все ще задовольняють умову інтерполяції
• Усі учасники можуть створювати фрагменти дочірніх закритих ключів для генерації фрагментів дочірніх підписів

Потрібно врахувати проблеми сумісності між покращеними та непокращеними BIP32.

3.4 OP-DLC: мінімізація довіри до оракула

Запропоновано механізм OP-DLC, впровадження оптимістичного виклику:

• Оракул заздалегідь закладає для побудови онлайнової гри OP
• Будь-яка чесна сторона може ініціювати виклик
• Успішний виклик карає злочинного оракула
• Можна використовувати підпис "k-of-n" моделі, значення k може бути 1
• Гіпотеза довіри знижена до лише одного чесного учасника

3.5 OP-DLC + BitVM двохмост

Поєднуючи OP-DLC та BitVM, вирішуючи проблеми DLC у міжланцюгових мостах:

• Використання BitVM для вирішення проблеми з рештою
• Надання різних каналів для внесення та виведення коштів
• Зменшення довіри до оракула через механізм OP
• Підвищення ефективності використання капіталу

4. Висновок

DLC поєднує технології Taproot та BitVM, що дозволяє реалізувати більш складну верифікацію та розрахунок офлайн-контрактів. Завдяки механізму виклику OP можна додатково реалізувати мінімізацію довіри до оракулів, що відкриває більше можливостей для екосистеми Bitcoin.