Анализ принципов DLC и соображения по оптимизации

Оригинальное название: «Bitlayer Core Technology: DLC и соображения по его оптимизации».

Источник: Lynndell & Mutourend, Bitlayer Research Group.

Оригинальная ссылка:

1. Введение

Discreet Log Contract (DLC) — это набор решений по исполнению контрактов на основе Oracle, предложенный Таджем Дрийей из Массачусетского технологического института в 2018 году. DLC позволяет двум сторонам совершать условные платежи на основе заранее определенных условий. Каждая сторона определяет и предварительно подписывает возможные результаты и использует эти предварительные подписи для выполнения платежа, когда оракул подписывает результаты. Таким образом, DLC позволяет создавать новые децентрализованные финансовые приложения, обеспечивая при этом безопасность депозитов в биткойнах.

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

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

Хотя DLC имеет большие преимущества в экологических приложениях Биткойна, все же существуют некоторые риски и проблемы, такие как:

• Риск ключа: закрытый ключ машины оракула и обещанное случайное число подвержены риску утечки или потери, что приведет к потере пользовательских активов;
• Риск централизованного доверия: проблемы централизации Oracle могут легко привести к атакам типа «отказ в обслуживании»;
• Децентрализация предотвращает получение ключей: если оракул децентрализован, узел оракула владеет только фрагментом закрытого ключа. Однако децентрализованные узлы-оракулы не могут напрямую использовать BIP32 для получения ключей на основе сегментирования закрытого ключа;
• Риск сговора: если узлы оракула вступают в сговор друг с другом или с участвующими сторонами, проблема доверия машины оракула все еще не решена. Необходим надежный механизм надзора, чтобы минимизировать доверие к оракулам;
• Исправлена проблема изменения номинала: условные подписи требуют детерминированного набора перечислимых событий перед созданием контракта для создания транзакции. Таким образом, будет установлен минимальный лимит суммы DLC, который будет использоваться для перераспределения активов, что приведет к проблеме изменения фиксированного номинала.

С этой целью в этой статье предлагаются некоторые решения и идеи по оптимизации для устранения рисков и проблем DLC и повышения безопасности экосистемы Биткойн.

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 по вычислениям

$R:=k ⋅ G$

Затем вычислите S и S’

$S:=R-хэш(OddNumber,R) ⋅ Z,$

$S’:=R-хэш(EvenNumber,R) ⋅ Z$

трансляция(R,S,S’).

Алиса и Боб вычисляют соответствующий новый открытый ключ.

$PK^{Алиса}:=X+ S,$

$PK^{Боб}:=Y+ S’.$

Расчет: когда появляется n+k-й блок, машина-оракул генерирует соответствующие s или s на основе хеш-значения блока.

• Если хэш-значение блока n+k нечетное, оракул вычисляет и передает s

$s:=k-hash(OddNumber,R) ⋅ z$

• Если хэш-значение блока n+k четное, оракул вычисляет и передает s’

$s’:=k-хэш(EvenNumber,R) ⋅ z$

Вывод монет: один из участников, Алиса или Боб, может вывести активы на основании сообщений оракула или сообщений.

• Если оракул передает s, Алиса может вычислить новый закрытый ключ sk^{Alice} и вывести заблокированные 2 BTC.

$sk^{Алиса}:= x + s.$

• Если оракул передает s’, Боб может вычислить новый закрытый ключ sk^{Bob} и вывести заблокированные 2 BTC.

$sk^{Боб}:= y + s’.$

Анализ: новый закрытый ключ sk^{Алиса}, рассчитанный Алисой, и новый открытый ключ PK^{Алиса} удовлетворяют соотношению дискретного логарифма.

$sk^{Алиса} ⋅ G= (x+s) ⋅ G=X+S=PK^{Алиса}$

В этом случае вывод валюты Алисы пройдет успешно.

Таким же образом новый закрытый ключ sk^{Bob}, вычисленный Бобом, и новый открытый ключ PK^{Bob} удовлетворяют соотношению дискретного логарифма.

$sk^{Боб} ⋅ G= (y+s’) ⋅ G=Y+S’=PK^{Боб}$

В этом случае вывод Боба пройдет успешно.

Более того, если оракул передает s, это полезно Алисе, но не Бобу. Потому что Боба нельзя использовать для вычисления соответствующего нового закрытого ключа sk^{Bob}. Точно так же, если оракул передает s’, это полезно Бобу, но не Алисе. Потому что Алису нельзя использовать для вычисления соответствующего нового закрытого ключа sk^{Alice}.

Наконец, в приведенном выше описании отсутствуют временные блокировки. Необходимо добавить временную блокировку, чтобы одна сторона могла вычислить новый закрытый ключ и вывести валюту в течение времени t. В противном случае, если время t превышено, другая сторона может вывести активы, используя исходный закрытый ключ.

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

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

В протоколе DLC решающее значение имеют закрытый ключ оракула и обещанное случайное число. Если закрытый ключ оракула и обещанное случайное число утекут или потеряются, это легко приведет к следующим четырем проблемам безопасности:

(1) Машина-оракул теряет закрытый ключ z

Если оракул теряет закрытый ключ, DLC не может быть урегулирован, что приводит к необходимости выполнения контракта на возврат DLC. Поэтому в протоколе DLC настроена транзакция возврата, чтобы оракул не потерял свой закрытый ключ.

(2) Машина-оракул передает секретный ключz

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

(3) Машина-оракул пропускает или повторно использует случайное число k

Если оракул передает случайное число k, то на этапе расчета, независимо от того, передает ли оракул s или s’, злоумышленник может вычислить закрытый ключ z оракула следующим образом:

$z:=(ks)/hash(OddNumber, R)$

$z:=(k-s’)/hash(EvenNumber, R)$

Если машина-оракул повторно использует случайное число k, то после двух расчетов злоумышленник может решить систему уравнений в соответствии с подписью, переданной машиной-оракулом, и одной из следующих четырех ситуаций, чтобы получить закрытый ключ z машины-оракула:

Дело 1:

$s_1=k-хэш(OddNumber_1, R) ⋅ z$

$s_2=k-хэш(OddNumber_2, R) ⋅ z$

Случай 2:

$s_1’=k-хеш(EvenNumber_1, R) ⋅ z$

$s_2’=k-хэш(EvenNumber_2, R) ⋅ z$

Случай 3:

$s_1=k-хэш(OddNumber_1, R) ⋅ z$

$s_2’=k-хэш(EvenNumber_2, R) ⋅ z$

Случай 4:

$s_1’=k-хеш(EvenNumber_1, R) ⋅ z$

$s_2=k-хэш(OddNumber_2, R) ⋅ z$

(4) Машина-оракул теряет случайное число k

Если оракул теряет случайное число k, соответствующий DLC не может быть урегулирован и необходимо выполнить контракт на возврат DLC.

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

3.2 Децентрализованный Oracle

В DLC решающую роль играет оракул, предоставляющий ключевые внешние данные, определяющие исход контракта. Для повышения безопасности этих контрактов необходимы децентрализованные оракулы. В отличие от централизованных оракулов, децентрализованные оракулы распределяют ответственность за предоставление точных и защищенных от несанкционированного доступа данных между несколькими независимыми узлами, что может снизить риск полагаться на единую точку отказа и уменьшить возможность манипулирования или целенаправленных атак. Благодаря децентрализованным оракулам DLC может достичь более высокой степени доверия и надежности, гарантируя, что выполнение контракта полностью зависит от объективности заранее определенных условий.

Пороговые сигнатуры Шнорра могут реализовать децентрализованные оракулы. Пороговые сигнатуры Шнорра имеют следующие преимущества:

• Повышенная безопасность: благодаря управлению децентрализованными ключами пороговые подписи снижают риск возникновения единых точек отказа. Даже если ключи некоторых участников будут украдены или атакованы, вся система по-прежнему будет в безопасности, пока не будет превышен установленный порог.
• Распределенный контроль: Пороговая подпись реализует распределенный контроль над управлением ключами. Ни один объект не обладает всеми полномочиями подписи, что снижает риск, вызванный чрезмерной концентрацией власти.
• Повышение доступности: только определенное количество узлов оракула должно дать согласие на завершение подписи, что повышает гибкость и доступность системы. Даже если некоторые узлы будут недоступны, это не повлияет на надежную работу всей системы.
• Гибкость и масштабируемость: протокол пороговой подписи может устанавливать различные пороговые значения по мере необходимости для адаптации к различным требованиям и сценариям безопасности. Кроме того, он также подходит для крупномасштабных сетей и обладает хорошей масштабируемостью.
• Подотчетность: каждый узел оракула генерирует фрагменты подписи для сообщений на основе фрагментов закрытого ключа, а другие участники могут использовать соответствующие фрагменты открытого ключа для проверки правильности фрагментов подписи для достижения подотчетности. Если все верно, фрагменты подписи накапливаются для создания полной подписи.

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

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 используют фрагменты секретного ключа z_i, i=1,…,t+1 для генерации фрагментов подписи σ_i’ для сообщения msg’ , фрагменты подписи σ_i’ объединяются в полную подпись σ’. Верификатор может проверить правильность пары подписей сообщения (msg’,σ’), используя полный открытый ключ Z. Поскольку узлы оракула t+1 должны совместно генерировать пороговую подпись, она имеет высокий уровень безопасности.

Однако в сценарии децентрализованного приложения Oracle полный закрытый ключ z не отображается, и BIP32 нельзя использовать непосредственно для получения ключа. Другими словами, технология децентрализации Oracle и технология управления ключами не могут быть напрямую связаны.

В документе «Распределенное получение ключей для многостороннего управления цифровыми активами блокчейна» предлагается метод распределенного получения ключей в сценарии пороговой подписи. Основная идея этой статьи заключается в том, что в соответствии с интерполяционным полиномом Лагранжа фрагмент закрытого ключа 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

В DLC контракт между Алисой и Бобом исполняется на основе результата подписи оракула, поэтому оракулу необходимо в определенной степени доверять. Поэтому правильное поведение машины-оракула является важнейшим условием работы DLC.

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

• Модель «n-из-n» означает использование n оракулов для подписания контракта и исполнение контракта на основе результатов n оракулов. Для этой модели требуется n оракулов, чтобы все подписывались онлайн. Если оракул отключится или у него возникнут разногласия по поводу результатов, это повлияет на выполнение контракта DLC. Допущение доверия состоит в том, что все n оракулов честны.
• Модель «k из n» означает использование n оракулов для подписания контракта и исполнение контракта на основе результатов k оракулов. Если в сговор вступит более чем k оракулов, это повлияет на честное исполнение контракта. Кроме того, при использовании модели «k-из-n» количество CET, которые необходимо подготовить, в C_n^k раз больше, чем у одного оракула или модели «n-из-n». Допущение доверия состоит в том, что по крайней мере k оракулов среди n честны.

Увеличение количества машин-оракулов не приводит к недоверию к машинам-оракулам. Потому что, когда оракул делает что-то злое, у потерпевшей стороны в контракте нет канала апелляции в цепочке.

Поэтому в этом разделе предлагается OP-DLC, который вводит в DLC оптимистичный механизм испытаний. Прежде чем n-оракулы примут участие в настройке DLC, они должны заранее пообещать создать несанкционированную сетевую OP-игру и пообещать не делать зла. Если какой-либо оракул творит зло, Алиса или Боб, или любой другой честный оракул или другой сторонний честный наблюдатель могут инициировать вызов. Если претендент выиграет игру, злой оракул будет наказан по цепочке, а его депозит будет конфискован. Кроме того, OP-DLC также можно подписать с использованием модели «k-of-n». Среди них значение k может быть даже равно 1. Поэтому предположение о доверии сводится к тому, что пока в сети есть честный участник, можно запустить ОП-вызов, чтобы наказать злой узел-оракул.

При расчете OP-DLC на основе результатов расчета Layer2:

• Если оракул использует неверную подпись результата, что наносит ущерб интересам Алисы, Алиса может использовать Layer2, чтобы правильно вычислить результат и бросить вызов неразрешенной OP-игре в цепочке, где оракул заранее пообещал. Алиса выигрывает игру, наказывает злого оракула и компенсирует поражение;
• Таким же образом Боб, другие честные узлы-оракулы и сторонние честные наблюдатели могут инициировать вызовы. Однако, чтобы предотвратить злонамеренные вызовы, претенденту также необходимо сделать ставку.

Таким образом, OP-DLC позволяет узлам оракула контролировать друг друга, сводя к минимуму доверие оракула. Этот механизм требует только одного честного участника и имеет уровень отказоустойчивости 99%, что лучше устраняет риск сговора оракулов.

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

Когда DLC используется в качестве межсетевого моста, распределение средств требуется при расчете контракта DLC:

• Требует предварительной настройки через CET. Это означает, что детализация расчетов в фонде DLC ограничена, как, например, в сети Bison с детализацией 0,1 BTC. Существует проблема: взаимодействие пользователей с активами на уровне 2 не должно ограничиваться степенью детализации фонда DLC CET.
• Когда Алиса хочет рассчитать свои активы Layer2, активы Layer2 пользователя Боба будут принудительно сопоставлены с Layer1. Существует проблема: каждый пользователь уровня 2 должен иметь возможность свободно вносить и снимать средства, не подвергаясь влиянию депозитов и снятий средств других пользователей.
• Алиса и Боб договариваются о стоимости. Есть проблема: обе стороны должны быть готовы сотрудничать.

Поэтому для решения вышеуказанных проблем в этом разделе предлагается двойной мост OP-DLC + BitVM. Это решение позволяет пользователям вносить и снимать деньги через несанкционированный мост BitVM, а также вносить и снимать деньги с помощью механизма OP-DLC, обеспечивая изменения с любой степенью детализации и улучшая ликвидность капитала.

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

• Если BitVM Alliance действует как оракул и правильно подписывает, Алиса может вывести деньги на уровне 1. Однако Боб может вывести деньги на уровне 1 после истечения периода блокировки.
• Если BitVM Alliance действует как оракул и жульничает, интересы Алисы будут повреждены. Однако Алиса может бросить вызов UTXO Боба. Если вызов будет успешным, сумма Боба может быть конфискована. Примечание. Один из других членов BitVM Alliance также может инициировать вызов, но у Алисы больше всего мотивации инициировать вызов, поскольку ее интересы затрагиваются.
• Если BitVM Alliance действует как оракул и жульничает, интересы Боба пострадают. Однако честный член Альянса BitVM может бросить вызов «Игре BitVM» и наказать узлы-оракулы за мошенничество.

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

*Вывод денег через BitVM, который поддерживается оператором BitVM на уровне 1. Мост 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 можно добиться минимизации доверия оракула.

Рекомендации

1. Спецификация контрактов дискретных журналов
2. Контракты дискретного журнала
3. Масштабирование DLC, часть 1: Контракты дискретного журнала вне цепочки
4. Масштабирование DLC, часть 2. Проблема с бесплатными опциями DLC.
5. Масштабирование DLC. Часть 3. Как избежать проблем с бесплатными опциями DLC
6. Молниеносная сеть
7. DLC на Молнию
8. Управление закрытыми ключами DLC. Часть 1.
9. Управление закрытыми ключами DLC. Часть 2. Закрытые ключи Oracle.
10. Управление ключами DLC, часть 3: Распределение открытых ключей Oracle
11. BitVM: вычисляйте что угодно на биткойнах
12. BitVM 2: несанкционированная проверка биткойнов
13. Биткойн-контракты вне сети BitVM
14. БИП32 БИП44
15. Подпись Шнорра
16. FROST: гибкие, оптимизированные по кругу сигнатуры порога Шнорра.
17. Исследование подписания порога ECDSA
18. Распределенное получение ключей для многостороннего управления цифровыми активами блокчейна
19. Отдельный свидетель
20. Оптимистичный роллап
21. Стержневой корень