Сводка: Мосты ZK развертывают смарт-контракты на Chain A для непосредственного получения и проверки заголовков блоков и соответствующих доказательств в нулевом знании от Chain B, подтверждая действительность межцепочечных сообщений. Это самая безопасная схема моста.

• Оптимистичные/OP мосты используют доказательства мошенничества для оспаривания недействительных межцепных сообщений на цепи. Наличие только одного надежного оспаривателя может обеспечить безопасность фонда пула межцепного моста.
• Из-за технических ограничений биткойн-основная сеть не может напрямую развертывать ZK-мосты, но может достичь оптимистичных мостов через BitVM и доказательства мошенничества. Команды, такие как Bitlayer и Citrea, приняли схему BitVM-моста, внедрив предварительное подписание и включив концепции каналов, позволяя пользователям предопределить процесс обработки после выполнения депозита, предотвращая недобросовестное использование депозитов пользователей через мост межцепочного взаимодействия.
• Мост BitVM в основном работает по модели "предоплата-возмещение", при этом конкретные узлы оператора предоставляют средства пользователям для вывода. Операторы могут периодически подавать заявки на возмещение с общего адреса депозита. Если оператор подает ложное заявление о возмещении, его можно оспаривать и сокращать любым пользователем.
• Хотя теоретически безопасный, мост BitVM имеет проблемы с живучестью/используемостью и не удовлетворяет конкретные потребности пользователей в независимости от фонда и противодействии отмыванию денег (поскольку по сути использует модель фондового пула). Bitlayer решает эту проблему с помощью мостового решения OP-DLC. Это решение, аналогичное DLC.link, вводит доказательства мошенничества на основе каналов и DLC, чтобы предотвратить злоупотребление оракулом.
• Учитывая сложность внедрения BitVM и доказательств мошенничества, мосты DLC будут развернуты первыми в качестве временной замены. Пока не будут решены риски доверия к оракулам и не будут интегрированы более надежные и зрелые оракулы сторонних разработчиков, мосты DLC могут стать более безопасной схемой подтверждения вывода, чем мосты с мультиподписью на текущем этапе.

Введение:С момента увлечения надписями в прошлом году экосистема Биткойна вошла в период быстрого роста. За полгода количество проектов под эгидой BTC Layer2 достигло почти 100. Это просто стало новым континентом, полным хаоса, где возможности и мошенничества сосуществуют. Не преувеличено сказать, что нынешняя экосистема Биткойна уже является «многонациональным плавильным котлом» Эфириума, Космоса и Целестии, CKB и родной экосистемы Биткойна. Вместе с отсутствием авторитетных голосов экосистема Биткойна просто похожа на XIX век. Как Соединенные Штаты, она стала новым миром, привлекающим силы из всех сфер жизни. Это приносит процветание и живость всей рассказу Web3, но также вносит огромные риски.

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

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

Можно сказать, что Монанаут и Виталик откровенно указали на технические проблемы Bitcoin Уровень 2: многие мосты вывода L2 по сути являются мостами с мультиподписью. Либо несколько известных институтов держат каждый свой ключ, либо используется децентрализованная подпись на основе POS, но в любом случае его модель безопасности основана на предположении о честности большинства, то есть по умолчанию предполагается, что большинство участников мультиподписи не сговариваются сделать зло.

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

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

Оптимистичный мост: схема верификации моста на основе доказательства мошенничества

На самом деле суть кросс-цепочечного моста очень проста, это доказательство для цепи B того, что определенное событие действительно произошло на цепи A. Например, если вы переносите активы с ETH на Polygon, вам нужен кросс-цепочечный мост, чтобы помочь вам доказать, что вы действительно передали активы на определенный адрес на цепи ETH, а затем вы сможете получить ту же сумму средств на цепи Polygon.

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

Модель безопасности этого типа кросс-цепного моста в основном такая же, как у кошельков с мультиподписями. Модель доверия должна быть определена в соответствии с методом настройки мультиподписи, таким как M/N, но в конечном итоге она в основном следует предположению о честном большинстве, что означает, что большинство нотариусов по умолчанию не злонамеренны, и уровень отказоустойчивости относительно ограничен. Многие кражи на крупномасштабных кросс-цепных мостах, которые произошли ранее, в основном произошли на этом типе мостов с мультиподписью, либо из-за кражи, либо со стороны хакеров.

В отличие от этого, основанный на протоколе защиты от мошенничества «Оптимистичный мост» и основанный на ZK «ZK мост» являются намного безопаснее. Возьмем в качестве примера ZK мост, который установит специальный контракт валидатора на целевой цепи для прямой проверки сертификата вывода на цепи, исключая необходимость зависимости от внецепных свидетелей.

Например, ZK-мост между ETH и Polygon развернет контракт верификатора на Polygon, давайте пока назовем его Верификатор. Узел ретранслятора ZK-моста пересылает последний заголовок блока Ethereum и доказательство ZK, подтверждающее его правильность, Верификатору, который его проверит. Это эквивалентно тому, что контракт Верификатора синхронизируется с цепочкой Polygon и проверяет последний заголовок блока Ethereum. Меркловский корень, записанный в заголовке блока, связан с набором транзакций, содержащихся в блоке, и может использоваться для проверки, включена ли определенная транзакция в блок.

Если блок Ethereum с высотой блока 101 содержит 10 заявлений о кросс-цепных трансферах от ETH к Polygon, Релейер создаст доказательство Меркля, связанное с этими 10 транзакциями, и представит доказательство контракту Верификатора на цепочке Polygon:

Блок Ethereum № 101 содержит 10 кросс-цепных транзакций от ETH к Polygon. Конечно, ZK-мост может преобразовать доказательство Меркла в ZK и напрямую отправить доказательство ZK в контракт Верификатора. В течение всего этого процесса пользователям нужно только доверять тому, что смарт-контракт кросс-цепного моста не имеет уязвимостей, и что сама технология доказательства нулевого знания безопасна и надежна. Нет необходимости вводить слишком много доверительных предположений, как в традиционных мультиподписных мостах.

И “Оптимистичный мост” немного отличается. Некоторые оптимистичные мосты сохраняют настройки, похожие на свидетелей, но вводят доказательства мошенничества и окна вызова., после того как свидетель создает мультиподпись для межцепочечного сообщения, хотя оно будет отправлено в целевую цепь, его действительность не будет сразу признана. Ему необходимо пройти период ожидания, и никто не подвергает сомнению, прежде чем он может быть признан действительным. Это на самом деле в некотором смысле похоже на идею Оптимистичного Rollup. Конечно, у Оптимистичного моста есть другие модели продуктов, но в конечном анализе безопасность гарантируется протоколом доказательства мошенничества.

Предположение о доверии моста M/N с несколькими подписями имеет вид N-(M-1)/N. Вы должны исходить из того, что количество злоумышленников в сети не более M-1, а количество честных людей не менее N-(M-1). Предположение о доверии моста ZK пренебрежимо мало, в то время как предположение доверия оптимистичного моста, основанного на доказательстве мошенничества, равно 1/N, только один из N свидетелей должен быть честным и готовым оспорить недействительные кроссчейн-сообщения, отправленные в целевую цепочку, чтобы обеспечить безопасность моста.

В настоящее время из-за технических ограничений может быть реализован только ZK-мост в направлении внесения биткойнов на Уровень 2. Если направление изменится, и с Уровня 2 будут сделаны выводы на цепочку биткойнов, поддерживаются только мосты с мультиподписями или оптимистичные мосты или модели, подобные каналам (описанный ниже мост OP-DLC больше похож на канал). Чтобы реализовать оптимистичный мост на цепочке биткойнов, необходимо ввести доказательство мошенничества, и BitVM создал хорошие условия для реализации этой технологии.

в предыдущих статьях«Минималистическая интерпретация BitVM: Как проверить доказательства мошенничества на цепи BTC», мы кратко рассмотрели, Суть доказательства мошенничества BitVM заключается в том, чтобы разбить сложные расчетные задачи, выполняемые вне цепи, на большое количество простых шагов, а затем выбрать определенный шаг для прямой проверки на цепи Bitcoin.. Эта идея аналогична оптимистическим роллапам Ethereum, таким как Arbitrum и Optimism.

(Документация BitVM2 упоминает, что вычислительная задача будет разбита на большое количество промежуточных шагов с помощью подписей Лямпорта, и затем любой может оспорить промежуточный шаг)

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

Мы кратко рассмотрим BitLayer, Citrea, BOB и даже официально разработанный BitVM мост от GateVM с точки зрения дизайна продукта и механизма, а также как Bitlayer смягчает узкое место моста BitVM через мост OP-DLC., чтобы показать вам, как разработать передовое решение моста вывода на цепочке Bitcoin.

(Принципиальная схема мостового решения Bitlayer)

Краткий анализ принципа моста BitVM между Bitlayer и Citrea

ниже мы используем решение моста BitVM, объявленное Bitlayer, Citrea и Bob, в качестве материала для иллюстрации общего процесса работы моста BitVM.

В своих официальных документах и технических блогах вышеупомянутая проектная сторона четко объяснила идеи дизайна продукта BitVM Withdrawal Bridge (в настоящее время на теоретической стадии). Во-первых, когда пользователь выводит деньги через мост BitVM, ему необходимо использовать контракт моста на Уровне 2 для создания заявления о выводе. В заявлении о выводе указаны следующие ключевые параметры:

Количество сопоставленных BTC, которые нужно уничтожить в L2 (например, 1 BTC);

Комиссия за обработку межцепных транзакций, которую намеревается заплатить выводящая сторона (предполагается, что это 0,01 BTC);

Адрес вывода выводящего в L1: L1_receipt;

Сумма вывода выводителя (т. е. 1 — 0.01 = 0.99BTC)

После этого выписка о выводе, указанная выше, будет включена в блок Layer2. Мост BitVMРетрансляторный узел будет синхронизировать блок Layer2, отслеживать включенную в него выписку о выводе и пересылать ее на узел оператора, который осуществит выплату пользователю, сделавшему вывод.

Важно отметить здесь, что Оператор сначала оплачивает пользователей на цепи Биткойн за свой счет, то есть «предоставляет» средства для моста BitVM, а затем подает заявку на компенсацию из фонда пула моста BitVM.

При подаче заявки на возмещение Оператор должен предоставить доказательство предварительной оплаты на цепи Биткойн (то есть доказать, что он перевел деньги на адрес, указанный пользователем для вывода на L1, и извлечь конкретную запись о переводе, содержащуюся в блоке Биткойн). В то же время Оператор также должен выдать заявление на вывод, сгенерированное выводителем на L2 (через Merkle Proof доказывается, что выданное заявление на вывод происходит из блока L2 и не является выдумкой). после, Оператор должен доказать следующее:

Средства, выделенные Оператором тиражирующему лицу от имени моста BitVM, равны запрошенной сумме тиражирующим лицом в заявлении;

Когда Оператор подает заявку на возмещение, сумма возмещения не должна превышать сумму уничтоженных сопоставленных BTC, выведенных пользователем на уровне 2;

Оператор действительно обработал все заявления на вывод L2-L1 в течение определенного периода времени, и каждое заявление на вывод можно сопоставить с записью о выводе на цепи Биткойна;

Это в основном наказание для Оператора за ложь относительно суммы аванса или отказ обработать заявление на вывод (что может решить проблему цензурирования моста вывода). Оператору необходимо сравнить и проверить ключевые поля свидетельства об авансовом платеже и заявления на вывод вне цепи, чтобы доказать, что сумма BTC, участвующая в обоих случаях, равна.

Если оператор моста вывода ложно сообщает о сумме аванса, это означает, что оператор утверждает, что доказательство платежа на L1 соответствует выписке о выводе, выданной выводчиком L2, но на самом деле они не совпадают.

Таким образом, это доказывает, что ZKP Payment Proof = Statement Withdrawal должен быть неверным. До тех пор, пока этот ZKP выпущен, Challanger может указать, какой шаг является неправильным, и оспорить его через протокол защиты от мошенничества BitVM2.

Что следует подчеркнуть, это то, что Bitlayer, Citrea, BOB, ZKBase и т. д. все приняли последний маршрут BitVM2, который является новой версией решения BitVM. Это решение будет ZKize внешние вычислительные задачи, то есть генерировать ZK Proof для процесса внешних вычислений, затем проверять доказательство, а затем преобразовывать процесс проверки ZKP в адаптированный к форме BitVM для облегчения последующих вызовов.

В то же время, используя Лампорта и предварительное подписание, многокруговой интерактивный вызов оригинального BitVM можно оптимизировать до однокругового неинтерактивного вызова, что значительно снижает сложность вызова.

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

Мы можем приблизительно понимать Обязательство как хэш большого объема данных вне цепи блоков. Сам размер Обязательства часто сжимается до очень маленького, но его можно привязать к большому объему данных вне цепи блоков через методы, такие как Дерево Меркля, и эти связанные данные вне цепи не нужно загружать на цепь.

В решении моста BitVM между BitVM2 и Citrea и BitLayer, если кто-то считает, что есть проблема с обязательством, выпущенным Оператором моста вывода на цепочке, и что обязательство связано с недопустимым процессом верификации ZKP, он или она может инициировать вызов, и власть вызова - безразрешительная. (Процесс взаимодействия внутри довольно сложен и здесь не будет объясняться)

Поскольку Оператор предоставляет средства для фонда BitVM для оплаты вывода, а затем обращается в фонд для возврата средств, при подаче заявки Оператор должен выдать Обязательство, чтобы доказать, что деньги, которые он переводит на вывод на L1, равны выводу. Плательщик объявляет на L2, что хочет получить деньги. Если Обязательство прошло окно доказательства мошенничества и не было оспорено, Оператор может вывести сумму возмещения, которая ему необходима.

Здесь мы хотим объяснить, как поддерживается публичный фонд пула моста BitVM, и это именно самая критическая часть кросс-цепного моста. Как известно, средства, которые кросс-цепной мост может выплатить тому, кто выиграл, поступают из активов, внесенных депозитариями или другими LP, а деньги, выданные Оператором, в конечном итоге будут изъяты из общественного фонда, поэтому все зависит исключительно от средств. В результате передачи сумма депозита, поглощенная мостом BitVM, должна быть равна сумме вывода. Поэтому вопрос о том, как сохранить денежные средства депозита, является очень важным.

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

Мост Bitlayer и BitVM Citrea принимает идеи, аналогичные молнии и каналам. Прежде чем сделать депозит, пользователь сначала свяжется с альянсом BitVM и попросит последнего предварительно подписать для достижения следующих эффектов:

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

В мостовом решении BitVM существует федерация BitVM (Федерация BitVM), сформированная из N членов, которые планируют депозиты пользователей. Тем не менее, эти N члены не могут незаконно присваивать депозиты пользователей в частном порядке, потому что пользователи потребуют от BitVM Alliance предварительной подписи перед переводом денег на указанный адрес, чтобы гарантировать, что эти депозиты могут быть законно востребованы только Оператором.

(Диаграмма оптимистического моста BitVM2)

Для краткого изложения на высоком уровне BitVM Bridge использует идеи, аналогичные каналам и молниям, позволяя пользователям «проверить сами» и предотвращая манипуляции со стороны BitVM Alliance с депозитным пулом без разрешения через предварительное подписание. Деньги в депозитном пуле могут использоваться только для возмещения Оператору. Если оператор искажает сумму аванса, любой может предъявить доказательство мошенничества и оспорить его.

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

Однако реализация моста BitVM относительно сложна. Более того, он не может удовлетворить потребности некоторых крупных инвесторов, которые имеют довольно высокие требования к прозрачности фондов: эти люди могут быть замешаны в вопросах борьбы с отмыванием денег и не хотят смешивать свои собственные средства с средствами других людей, но мост BitVM будет равномерно принимать деньги депозитариев, в каком-то смысле это пул, где смешивается много денег.

Для решения вышеупомянутой проблемы активности моста BitVM и предоставления независимого и чистого канала ввода и вывода средств для людей с конкретными потребностями команда BitLayer добавила дополнительное кросс-цепной мостовой решение под названием OP-DLC. Кроме оптимистичного моста BitVM2, используется мостик DLC, аналогичный DLC.link. Пользователям предоставляются два входа и выхода: мост BitVM и мост OP-DLC, чтобы уменьшить зависимость от моста BitVM и даже от Альянса BitVM.

(Схема DLC)

DLC: Осторожный Журнальный Контракт

DLC (Discreet Log Contracts) называется дискретным контрактом журнала. Он был предложен Инициативой по цифровой валюте Массачусетского технологического института. Эта технология впервые была использована для реализации облегченного смарт-контракта на Bitcoin. Он не требует, чтобы контент контракта был загружен в цепочку. С помощью таких методов, как интерактивное общение вне сети и предварительное подписание, в цепочке биткоина реализуются функции смарт-контрактов, защищающие конфиденциальность. Ниже мы используем игровой кейс, чтобы проиллюстрировать принцип работы DLC.

Предположим, что Алиса и Боб хотят поспорить на результат матча между Реал Мадридом и Барселоной, который состоится через три дня, и каждый из них платит 1 BTC. Если побеждает Реал Мадрид, то Алиса может получить 1,5 BTC, а Боб может вернуть только 0,5 BTC, что эквивалентно заработку для Алисы в 0,5 BTC, а для Боба убытку в 0,5 BTC; если побеждает Барселона, то Алиса может вернуть только 0,5 BTC, а Боб может унести с собой 1,5 BTC. В случае ничьей оба игрока получат по 1 BTC обратно.

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

Возьмем предыдущих Алису и Боба в качестве примера. Сначала обе стороны создают транзакцию фонда вне цепи, которая может заблокировать по 1 BTC каждого на адресе с мультиподписью 2/2. Если эта транзакция фонда вступает в силу, то 2 BTC на адресе с мультиподписью должны быть авторизованы обеими сторонами перед тем, как их можно будет потратить.

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

В первой фазе создания DLC мы можем определить, что Обе стороны заблокируют свои 1 BTC на мультиподписном адресе в будущем.

На втором этапе обе стороны продолжают выводить возможные будущие события и исходы: Например, когда объявляются результаты футбольного матча, могут возникнуть несколько вариантов, таких как победа Алисы и поражение Боба, поражение Алисы и победа Боба, ничья и т. д. Это приведет к различным результатам распределения биткойнов на упомянутом адресе с мультиподписью 2/2.

Разные результаты должны быть вызваны разными торговыми инструкциями. Эти "Инструкции по транзакциям, которые могут быть загружены в цепочку в будущем", называются CET, то есть Транзакция исполнения контракта. Алиса и Боб должны заранее вывести все CET и сгенерировать набор данных транзакций, содержащий все CET.

Например, исходя из возможных результатов ставки между упомянутыми выше Элис и Боб, Элис создает следующие CET.

CET1: Алиса может получить 1,5 BTC с мультиподписным адресом, а Боб может получить 0,5 BTC;

CET2:Алиса может получить 0.5 BTC с мультиподписным адресом, а Боб может получить 1.5 BTC;

CET3: Обе стороны могут получить по 1 BTC.

Давайте возьмем CET1 в качестве примера (Алиса получает 1,5 BTC, Боб получает 0,5 BTC):

Смысл этой транзакции заключается в передаче 1.5 BTC на мультиподписной адрес в адрес Taproot, который активируется результатами вывода Алисы и оракульной машины, а также передаче других 0.5 BTC на адрес Боба. Соответствующие события на данный момент: победа Реал Мадрида, Алиса выигрывает 0.5 BTC, а Боб проигрывает 0.5 BTC.

Конечно, чтобы потратить эти 1,5 BTC, Алиса должна получить подпись результата «Реал Мадрид выигрывает», отправленную оракулом. Другими словами, только когда оракул выдаст сообщение «Реал Мадрид выигрывает», Алиса сможет перевести 1,5 BTC. Что касается содержимого CET2 и CET3, то мы можем вывести их таким же образом и не будем вдаваться в подробности.

Следует отметить, что CET в основном является транзакцией, которую необходимо загрузить в цепочку для вступления в силу. Что произойдет, если Алиса предварительно транслирует CET1 или в случае "Победы Барселоны" все еще помещает CET1 в цепочку, которая может быть успешно запущена только после "Победы Реал Мадрида"?

В предыдущей диаграмме мы упомянули, что после того как CET1 будет помещен на цепочку, 2 BTC, заблокированные в исходном мультиподписном адресе, будут переведены, 0.5 BTC перейдет к Бобу, а 1.5 BTC перейдет на адрес Taproot. Оракул выдаст «Только после победы Реал Мадрида» Алиса сможет разблокировать BTC, заблокированные на адресе Taproot. Результаты показаны ниже.

В то же время этот адрес Taproot подвержен временной блокировке. Если Алиса не сможет успешно вывести 1,5 BTC в окне, указанном временной блокировкой, у Боба будет право взять деньги напрямую.

Следовательно, пока оракул честен, Алиса не может забрать 1,5 BTC. Когда истекает срок блокировки времени, Боб может забрать 1,5 BTC. Помимо 0,5 BTC, переданных напрямую Бобу, когда CET1 был загружен в цепочку, весь этот денег в конечном итоге будет принадлежать Бобу.

Для Алисы, независимо от того, выиграет она или проиграет в итоге, самое полезное, что можно сделать, — это поставить правильный CET в цепочку. Если вы поставите недействительный CET в цепочку, она потеряет еще больше денег.

Фактически, когда был сконструирован упомянутый выше CET, сигнатура schnorr Taproot была улучшена, что можно понимать как использование открытого ключа оракула + результатов событий для создания независимых адресов для различных результатов. После этого только когда оракул объявляет сигнатуру, соответствующую определенному результату, можно потратить заблокированные BTC на адресе, соответствующем результату.

Конечно, здесь есть дополнительная возможность. Что, если Алиса знает, что проиграла, и просто не помещает построенный ею CET1 на цепь? Это легко решить, потому что Боб может построить специальный CET для ситуации "Алиса проигрывает, Боб выигрывает". Эффект, достигаемый этим CET, в основном такой же, как и CET, построенный Алисой, но конкретные детали отличаются, но результат одинаковый.

Описанный выше процесс является наиболее критическим процессом по строительству CET. Третий шаг DLC предполагает, что Алиса и Боб общаются, проверяют построенную другой стороной транзакцию CET и ставят свою собственную подпись на CET. После успешной проверки они могут доверять друг другу и каждый вкладывает 1 BTC, блокируя исходные многоадресные адреса 2/2 Алисы и Боба, а затем ждут загрузки определенного количества CET на цепочку для запуска последующего процесса.

Наконец, после того, как машина-оракул объявит результаты и получит подпись машины оракула на результатах, любая из сторон может поместить правильный CET в цепочку и позволить 2 BTC, заблокированным в адресе с мультиподписью, быть перераспределенными. Если проигравший сначала поставит в цепочку неправильный CET, если вы поставите правильный CET на цепочку, вы потеряете все свои деньги. Если вы положите в цепочку правильный CET, проигравший может получить обратно 0,5 BTC.

Кто-то может спросить, в чем разница между DLC и обычной мультиподписью 2/3? Прежде всего, если больше чем 2/3 подписаны, две стороны могут сговориться, чтобы похитить все активы, а DLC позволяет противникам ограничить все сценарии, предварительно построив набор CET. Даже если оракул участвует в сговоре, ущерб, обычно, ограничен.

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

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

Кроме того, мост DLC Bitlayer также поддерживает собственные оракул-узлы, добавляя слой защиты от мошенничества поверх этого. Когда собственный оракул помещает недействительные CET в цепь, кто угодно может вызвать его на дуэль. Что касается принципа его моста OP-DLC, мы кратко опишем его ниже.

OP-DLC Мост: Канал DLC + Доказательство мошенничества

Мы объясняем принцип работы моста OP-DLC от всего процесса внесения и вывода. Предположим, что Алиса сейчас вносит 1 BTC в L2 через мост OP-DLC. Согласно двухэтапному механизму сделки, мистер Алиса создает предварительную транзакцию по фондам, как показано ниже:

На самом деле, сначала переведите 1 BTC на адрес Taproot, совместно контролируемый Алисой и участниками альянса BitVM, затем начните серию процессов для создания CET. Если участник альянса BitVM Bridge откажется сотрудничать с запросом депозита Алисы, Алиса может сразу же снять деньги после истечения временной блокировки.

Если участники альянса BitVM готовы сотрудничать с Алисой, обе стороны могут использовать внебиржевое общение для начала создания формальной транзакции депозита в Фонд (пока не в сети), а также всех CET в сценарии вывода. После завершения генерации и проверки CET обе стороны могут отправить транзакцию Фонда в сеть.

В данных свидетельства/подписи сделки Фонда, Алиса укажет свой платежный адрес на Уровне 2; После того, как сделка с Фондом загружена на цепочку, Алиса может представить вышеуказанные данные сделки с Фондом в мостовой контракт на Уровне 2, чтобы доказать, что она завершила действие по депонированию на цепочке Биткойн и имеет право на выпуск токена мостовым контрактом L2 на указанный платежный адрес.

После того, как сработала транзакция фонда, депозит фактически блокируется в мультиподписном адресе Taproot, совместно контролируемом Алисой и членами альянса BitVM. Однако следует отметить, что мультиподпись может разблокировать BTC, заблокированный адресом, только через CET, и альянс BitVM не может перевести деньги без основания.

Далее давайте проанализируем CET, заранее созданные Алисой и союзом BitVM. Эти CET используются для возможных сценариев будущих выводов. Например, Алиса могла депонировать 1 BTC, но при первом выводе она вывела только 0,3 BTC, а оставшиеся 0,7 BTC были переданы в общественный фондовый пул Альянса BitVM. Для контроля, но если вы хотите вывести деньги, вы можете сделать это только через упомянутый выше мост BitVM.

Или просто используйте эти 0.7 BTC для инициирования нового предварительного депозита. Как новый актив в мосту DLC, вы можете повторить процесс транзакции фондов и построения CET, упомянутый выше.

Вышеуказанный процесс несложно понять. На самом деле, депозитор Алиса и альянс bitVM действуют как контрагенты друг другу, создают CET для событий вывода различных сумм, а затем позволяют оракулу прочитать заявление об отзыве, инициированное Алисой на Уровне 2, чтобы определить, какую транзакцию Алиса хочет инициировать. Один CET (сколько денег вы хотите вывести).

Риск здесь заключается в том, что оракул-машина может сговориться с альянсом BitVM. Например, Алиса заявляет, что хочет вывести 0,5 BTC, но оракул-машина подделывает заявление о выводе, что в конечном итоге приводит к тому, что «Алиса выводит 0,1 BTC, а альянс BitVM получает 0,9 BTC». Ошибка CET на цепи.

Существует несколько решений этой проблемы. Первое - использовать сторонний оракул с относительно полным дизайном. Предотвратить такое сговор (в настоящее время крайне сложно для Альянса BitVM сговориться с оракулами), или позволить оракулу проводить стейкинг. Оракул должен регулярно публиковать Commitment на цепи Bitcoin, заявляя, что он честно обработал запрос на вывод средств от запросившего. Любой может оспорить Commitment с помощью протокола доказательства мошенничества BitVM. Если оспаривание успешно, злобный оракул будет наказан.

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

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

Подытожить

Решение моста BitLayer и BitVM Citrea по сути является моделью "предварительной оплаты-возмещения", есть выделенный узел Оператора для перевода денег пользователям для вывода, и Оператор может регулярно подавать заявку на возмещение на общий адрес депозита. Если оператор подает ложное заявление о возмещении, его можно оспорить и сократить кем угодно.

Решение BitVM2 вводит предварительное подписание и сочетает идею канала, позволяя пользователям ограничить процесс после внесения депозита до формального внесения депозита и не давая чиновникам моста межцепочной связи возможности присвоить средства пользователей.

В теории с этим мостом нет проблем безопасности, но есть проблемы с живостью/доступностью, и он не может удовлетворить потребности конкретных пользователей в независимости фонда и противодействии отмыванию денег (по сути, это модель фондового пула), и также очень сложно реализуем.

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

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

Отказ от ответственности:

1. Эта статья перепечатана с [гик web3]. Все авторские права принадлежат оригинальному автору [Faust & Nickqiao]. Если есть возражения по поводу этой репродукции, пожалуйста, свяжитесь с Учебник Gateкоманда, и они незамедлительно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционной рекомендацией.
3. Переводы статей на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.