Обсуждение принципов технологии DLC и идей оптимизации

1. Обзор

Дискретный логарифм контракт (DLC) является схемой выполнения смарт-контрактов на основе оракулов, предложенной Таджем Драйей из Массачусетского технологического института в 2018 году. DLC позволяет сторонам производить условные платежи на основе заранее установленных условий, участники заранее определяют возможные результаты и подписывают их, и как только оракул подписывает результат, производится платеж. Это позволяет реализовать новые децентрализованные финансовые приложения в сети Биткойн, обеспечивая при этом безопасность средств пользователей.

По сравнению с сетью Lightning, DLC имеет следующие преимущества:

• Лучшее обеспечение конфиденциальности: детали контракта делятся только между участниками, не хранятся в блокчейне.
• Поддержка сложных финансовых контрактов: возможность создания и выполнения деривативов, страхования и других сложных контрактов непосредственно в сети Биткойн
• Снижение рисков контрагента: средства блокируются в многофункциональном контракте и освобождаются только при наступлении запланированного результата события.
• Не нужно управлять платежными каналами: не требуется создавать или поддерживать платежные каналы
• Масштабируемость в определенных сценариях: обеспечивает хорошую масштабируемость в области сложных контрактов

Несмотря на то, что 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-вызова можно дополнительно реализовать минимизацию доверия к оракулам, что открывает больше возможностей для экосистемы Биткойн.