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

1. Огляд

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

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

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

Однак DLC все ще має певні ризики та проблеми:

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

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

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

Як приклад, візьмемо угоду про парі між Алісою та Бобом, де ставкою є парність хеш-значення n+k блоку. Якщо воно непарне, виграє Аліса, в іншому випадку виграє Боб. DLC передає інформацію про блоки через оракули для створення умовного підпису, що дозволяє вигравшій стороні отримати всі активи.

Конкретні кроки такі:

1. Ініціалізація: встановити генератор еліптичної кривої G, порядок якого дорівнює q.

2. Генерація ключів: оракул, Аліса та Боб кожен генерують свої приватні та публічні ключі. Оркестратор: приватний ключ z, публічний ключ Z = z·G Alice:приватний ключ x, публічний ключ X = x·G Bob: приватний ключ y, публічний ключ Y = y·G

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

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

5. Обчислення зобов'язань оракула: Р := к· G S := R - hash(НепарнеЧисло,R)·Z S' := R - hash(ПарнеЧисло,R)· Z трансляція (R,S,S')

6. Аліса та Боб обчислюють новий публічний ключ: PK^Alice := X + S PK^Bob := Y + S'

7. Розрахунок: оракул генерує s або s' на основі хеш-значення n+k блоку. Непарні: s := k - hash(OddNumber, R)·z Парне число: s': = k - hash(EvenNumber, R)·z

8. Виведення коштів: виграшна сторона обчислює новий приватний ключ на основі s або s' та виводить активи. Аліса:ск^Аліса := х + с Bob:sk^Bob := y + s'

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

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

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

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

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

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

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

• Використовуйте 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 для вирішення проблеми з рештою, зменшення кількості CET
• Забезпечити різноманітні канали для виведення та вводу коштів, реалізуючи здачу в будь-якому обсязі
• Встановити альянс BitVM як Bob та oracle, мінімізуючи довіру
• Канал DLC для виведення коштів вводить пул фінансів BitVM, підвищуючи ефективність використання

4. Висновок

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