1. Введение

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

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

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

Хотя DLC имеют значительные преимущества в экосистеме биткойна, все еще существуют определенные риски и проблемы, такие как:

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

Оракул вычисляет обязательство

а затем вычисляет S и S′

и транслирует (R, S, S′).

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

Расчет: После появления (n+k)-го блока Оракул генерирует соответствующий s или s′ на основе хеш-значения этого блока.

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

• Если хэш-значение (n+k)-го блока является четным, Oracle вычисляет и транслирует

Вывод: Алиса или Боб могут вывести активы на основе s или s′, переданных Оракулом.

• Если Оракул транслирует s, Алиса может вычислить новый закрытый ключ sk^{Алиса} и вывести заблокированные 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 ключевыми являются закрытый ключ Оракула и зафиксированный nonce. Утечка или потеря закрытого ключа Оракула и зафиксированного nonce могут привести к следующим четырем проблемам безопасности:

(1) Oracle теряет закрытый ключ z

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

(2) Утечка закрытого ключа Oracle’s z

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

(3) Утечка или повторное использование Nonce k Oracle

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

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

case 1:

case 2:

случай 3:

случай 4:

(4) Oracle теряет Nonce k

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

Для повышения безопасности закрытого ключа оракула рекомендуется использовать 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 удовлетворяют следующему интерполяционному отношению:

Добавление приращения ω к обеим сторонам уравнения приводит к:

Это уравнение показывает, что частный ключ share z_i плюс прирост ω по-прежнему удовлетворяет интерполяционному отношению со полным частным ключом z плюс ω. Другими словами, дочерний частный ключ share z_i+ω и дочерний ключ z+ω удовлетворяют интерполяционному отношению. Следовательно, каждый участник может использовать свой частный ключ share z_i плюс прирост ω для получения дочернего частного ключа share z_i+ω, используемого для генерации долей дочерних подписей и их проверки с использованием соответствующего дочернего открытого ключа Z+ω⋅G.

Однако следует учитывать закаленный и незакаленный BIP32. Закаленный BIP32 берет личный ключ, цепной код и путь в качестве входных данных, выполняет SHA512 и выдает приращение и дочерний цепной код. Незакаленный BIP32, с другой стороны, берет общедоступный ключ, цепной код и путь в качестве входных данных, выполняет SHA512 и выдает приращение и дочерний цепной код. В сценарии пороговой подписи личный ключ не существует, поэтому может использоваться только незакаленный BIP32. Или же можно применить закаленный BIP32 с использованием гомоморфной хэш-функции. Однако гомоморфная хэш-функция отличается от SHA512 и несовместима с оригинальным BIP32.

3.4 OP-DLC: Оракул Trust-minimized

В DLC контракт между Алисой и Бобом исполняется на основе подписанного результата Оракула, что требует определенного уровня доверия к Оракулу. Следовательно, правильное поведение Оракула является основной предпосылкой для работы DLC.

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

• Модель "n-of-n" включает использование n Оракулов для подписания контракта и выполнения контракта на основе результатов всех Оракулов. В этой модели требуется, чтобы все Оракулы были онлайн для подписания. Если какой-либо Оракул выходит из строя или возникает разногласие по результатам, это влияет на исполнение контракта DLC. Предположение о доверии здесь заключается в том, что все Оракулы честны.
• Модель "k-of-n" предполагает использование n Оракулов для подписания контракта, выполнение контракта на основе результатов любых k Оракулов. Если более чем k Оракулов сговорятся, это повлияет на справедливое исполнение контракта. Более того, количество CET, необходимых в модели "k-of-n", в k раз превышает количество одного Оракула или модели "n-of-n". Предположение о доверии в этой модели заключается в том, что по крайней мере k из n Оракулов являются честными.

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

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

При расчете OP-DLC на основе результатов вычислений уровня 2:

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

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

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

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

• Для этого требуется предварительная настройка через Центральные банки, что означает, что детализация расчетов фонда в DLC ограничена, например, 0.1 BTC в сети Bison. Это возникает проблема: взаимодействия активов уровня 2 для пользователей не должны быть ограничены детализацией фондов Центральных банков DLC.
• Когда Алиса хочет урегулировать свои активы уровня 2, это заставляет урегулировать активы пользователя Боба уровня 2 на уровень 1. Это вызывает проблему: каждый пользователь уровня 2 должен иметь свободу выбирать их депозиты и выводы независимо от действий других пользователей.
• Алиса и Боб ведут переговоры о расходах. Проблема здесь заключается в том, что обе стороны должны быть готовы сотрудничать.

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

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

• Если федерация BitVM, действуя как Оракул, подписывает правильно, Алиса может вывести на Уровне 1. Однако Боб может вывести на Уровне 1 после истечения временной блокировки.
• Если федерация BitVM, выступая в качестве Оракула, обманывает, вызывая ущерб для Элис, она может оспорить UTXO Боба. Если вызов успешен, сумма Боба может быть конфискована. Примечание: другой член федерации BitVM также может начать вызов, но Элис, будучи пострадавшей стороной, наиболее мотивирована сделать это.
• Если федерация BitVM, действуя в качестве Оракула, обманывает, причиняя ущерб Бобу, честный член федерации BitVM может оспорить "игру BitVM", чтобы наказать обманывающий узел Оракула.

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

• Вывод через BitVM, с оператором BitVM, фронтальным суммой на Уровне 1. Мост BitVM предполагает, что в федерации BitVM есть как минимум один честный участник.
• Вывести через конкретный CET в OP-DLC, оставшаяся сдача будет оплачена оператором BitVM на Уровне 1. Вывод через OP-DLC закроет канал DLC, но оставшиеся средства в канале DLC перейдут в пул уровня 1 BitVM, не заставляя других пользователей Уровня 2 выводить средства. Мост OP-DLC предполагает, что в канале есть как минимум один честный участник.
• Алиса и Боб ведут переговоры о расходах без участия Оракула, требуя сотрудничества со стороны Боба.

Таким образом, двойной мост OP-DLC + BitVM предлагает следующие преимущества:

• BitVM решает проблему изменения канала DLC, уменьшает количество необходимых CET и не зависит от детализации фонда CET;
• Сочетая мост OP-DLC с мостом BitVM, он обеспечивает пользователям несколько каналов для депозитов и вывода средств, улучшая опыт пользователей;
• Установка консорциума BitVM как Боба, так и оракула, и использование механизма OP минимизирует доверие к оракулу;
• Интеграция избыточного вывода из канала DLC в пул моста BitVM повышает эффективность использования средств.

4. Заключение

DLC появился до активации Segwit v1 (Taproot) и уже интегрирован с Lightning Network, позволяя расширить DLC для обновления и выполнения непрерывных контрактов в пределах того же канала DLC. С использованием технологий, таких как Taproot и BitVM, можно реализовать более сложные верификации и расчеты контрактов вне цепочки блоков в рамках DLC. Кроме того, путем интеграции механизма вызова OP можно минимизировать доверие к Оракулам.

Утверждение:

1. Эта статья перепечатана из средний, изначально называлась «Технология ядра Bitlayer: DLC и ее оптимизационные соображения». Права принадлежат оригинальному автору, Битлейер. Если есть возражения против этого повторного издания, пожалуйста, свяжитесь с Команда Gate LearnКоманда обработает это в соответствии с соответствующими процедурами как можно быстрее.

2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, представляют только личные взгляды автора и не являются инвестиционными советами.

3. Другие языковые версии статьи были переведены командой Gate Learn. Без упоминания Gate.io, переведенные статьи не могут быть скопированы, распространены или использованы в качестве плагиата.