Начиная с «Лета надписей» в 2023 году, технологии Layer2 биткоина находятся в авангарде революции Web3. Несмотря на то, что Биткойн вышел на рынок позже, чем решения уровня 2 Ethereum, он воспользовался уникальной привлекательностью POW и плавным запуском спотовых ETF, которые свободны от рисков «секьюритизации», чтобы привлечь миллиарды долларов инвестиций в этот растущий сектор всего за шесть месяцев. Среди них Merlin выделяется как наиболее значимая и популярная организация в ландшафте Bitcoin Layer2, обладающая миллиардами заблокированных средств (TVL). Благодаря четким стимулам для стейкинга и впечатляющей доходности Merlin быстро завоевал известность, превзойдя даже известную экосистему Blast за считанные месяцы. В связи с растущим ажиотажем вокруг Merlin, изучение его технической инфраструктуры привлекло все большую аудиторию. В этой статье Geek Web3 фокусируется на расшифровке технических стратегий, лежащих в основе Merlin Chain. Распаковывая общедоступные документы и обоснование дизайна протокола, мы стремимся развеять мифы об операционных процессах Merlin и улучшить понимание его структуры безопасности, предоставив более четкое представление о том, как функционирует это ведущее решение Bitcoin Layer2.

Децентрализованная сеть оракулов Мерлина: Открытый оффчейн комитет ДАК

Для каждой технологии Layer2 вопрос доступности данных (DA) и стоимости публикации данных остаются критическими вызовами, будь то Ethereum Layer2 или Bitcoin Layer2. Учитывая врожденные ограничения сети Bitcoin, с которыми сталкивается большой объем данных, стратегическое планирование эффективного использования ценного пространства DA является значительным испытанием для творчества разработчиков Layer2.

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

Среди тех, кто использует первую стратегию, выделяется Citrea. Они стремятся загружать изменения в состояниях Layer2 через определенные интервалы, что включает запись результатов изменения состояний по нескольким счетам, а также соответствующих доказательств в нулевом знании (ZKPs) на блокчейне Bitcoin. По этой схеме любой может получить доступ к разницам в состояниях и ZKPs с Bitcoin mainnet, чтобы отслеживать изменения состояний Citrea. Такой подход позволяет эффективно сократить объем данных, загружаемых на блокчейн, более чем на 90%.

Хотя это может значительно сжать объем данных, узкое место все равно очевидно. Если большое количество учетных записей меняют свой статус в короткий период времени, Layer 2 должен суммировать и загружать все изменения в этих учетных записях в цепочку Bitcoin. Окончательная стоимость выпуска данных не может быть очень низкой. Это верно для многих Эфиров. Это можно увидеть в ZK Rollup.

Многие уровни Bitcoin Layer 2 просто берут второй путь: непосредственно используют решение DA под цепочкой Bitcoin, либо строят собственный уровень DA, либо используют Celestia, EigenDA и т. д. B^Square, BitLayer и главный герой этой статьи, Merlin, все используют это решение расширения DA вне цепи.

Предыдущая статья на гик веб3——«Анализ дорожной карты технологии новой версии B^2: необходимость уровня DA и верификации под цепочкой Bitcoin», мы упомянули, что B^2 напрямую имитировал Celestia и построил сеть DA, которая поддерживает функцию сэмплирования данных под цепью, называемую B^2 Hub. “DA данные’’ такие как данные транзакции или разница состояний хранятся под цепью Bitcoin, и только datahash / merkle root загружается на основную сеть Bitcoin.

Это в сущности рассматривает Биткоин как децентрализованную доску объявлений: любой может прочитать datahash из цепочки Биткоина. После получения данных от поставщика данных вне цепочки, можно проверить, соответствует ли оно datahash, то есть hash(data1) == datahash1? . Если между ними есть соответствие, это означает, что данные, предоставленные вам поставщиком данных вне цепочки, верны.

DA Layer in Bitcoin’s Layer2 Объяснено:

(Источник изображения: Geek web3)

Эта система гарантирует, что данные от внеланцетных узлов коррелируют с определенными «уликами» или доказательствами на уровне 1, защищая от потенциальной проблемы, когда уровень DA предоставляет ложную информацию. Однако возникает значительная проблема, если источник данных - Секвенсор - не распространяет фактические данные, связанные с datahash. Предположим, что Секвенсор передает только datahash на блокчейн Bitcoin, умышленно утаивая соответствующие данные от общественного доступа. Что происходит дальше?

Рассмотрим сценарии, когда общедоступны только ZK-Proof и StateRoot, но сопроводительные данные DA (например, различия состояний или данные транзакций) не раскрываются. Хотя можно проверить ZK-Proof и убедиться в том, что переход от Prev_Stateroot к New_Stateroot точен, остается неизвестным, состояния каких счетов изменились. В этих обстоятельствах, хотя активы пользователей остаются безопасными, фактическое состояние сети остается неясным. Никто не знает, какие транзакции были включены в блокчейн или какие состояния контрактов были обновлены, что фактически делает Layer2 неэффективным, почти как будто он отключился.

Эта практика называется «отказ от данных». В августе 2023 года Данкрад из Фонда Эфириума начал обсуждение на Twitter о концепции, известной как «DAC».

Во многих настройках Ethereum Layer2, использующих решения для доступности данных (DA) вне цепи, часто есть несколько узлов с особыми привилегиями, которые формируют комитет, известный как Комитет доступности данных (DAC). Этот комитет служит гарантом, обеспечивая, что Секвенсор действительно выпустил полные данные DA (данные транзакции или разницу в состоянии) вне цепи. Затем участники DAC создают коллективную мультиподпись. Если эта мультиподпись достигает необходимого порога (например, 2 из 4), соответствующие контракты на Layer1 разработаны так, чтобы предполагать, что Секвенсор соответствовал стандартам проверки DAC и действительно выпустил полные данные DA вне цепи.

Комитеты DAC Ethereum Layer2 в основном придерживаются модели Proof of Authority (POA), ограничивая членство выбранным кругом узлов, прошедших KYC или официально назначенных. Такой подход эффективно превратил DAC в знак "централизации" и "консорциумного блокчейна". Кроме того, в определенных Ethereum Layer2, использующих подход DAC, секвенсор распространяет данные DA исключительно узлам-членам DAC, с минимальной внешней диссеминацией. Следовательно, любой, кто ищет данные DA, должен получить одобрение DAC, подобно работе в консорциумном блокчейне.

Очевидно, что DAC должны быть децентрализованными. Хотя, возможно, для загрузки данных DA непосредственно на Layer1 не требуется Layer2, доступ к членству в DAC должен быть общедоступным, чтобы избежать сговора и злоупотреблений отдельными лицами. (Дополнительные сведения по этому вопросу см. в предыдущих обсуждениях Dankrad в Twitter.)

Предложение Celestia о BlobStream в основном направлено на замену централизованного DAC на Celestia. По этой модели L2-последователь Ethereum будет публиковать данные DA в блокчейне Celestia. Если две трети узлов Celestia подтвердят эти данные, то специализированный контракт Layer2 на Ethereum проверит, что последователь точно опубликовал данные DA, тем самым позиционируя узлы Celestia как гарантов. Учитывая, что Celestia работает с сотнями узлов-валидаторов, этот более крупный конфигурация DAC считается относительно децентрализованной.

Решение DA, принятое Merlin, фактически довольно близко к BlobStream Celestia, оба из которых открывают доступ к DAC через POS, делая его более децентрализованным. Любой может запустить узел DAC, если он заложил достаточно активов. В документации Merlin вышеупомянутый узел DAC называется Оракулом, и отмечается, что он будет поддерживать залоги на BTC, MERL и даже токены BRC-20 для реализации гибкого механизма залогов, а также поддерживать доверительные залоги, аналогичные Lido. (Соглашение о залоге POS машинного оракула в основном является одним из следующих ключевых повествований Merlin, и предлагаемые процентные ставки по залогу относительно высокие)

Здесь мы кратко описываем рабочий процесс Merlin (см. рисунок ниже):

1. После того как секвенсор получает большое количество запросов на транзакции, он агрегирует их и генерирует пакет данных (пакет данных), который передается узлу доказательства и узлу Оракула (децентрализованный DAC).

2. Узел Merlin’s Prover децентрализован и использует Prover as a Service сервис от lumoz. После получения нескольких пакетов данных, пул майнинга Prover сгенерирует соответствующие доказательства нулевого знания. Затем ZKP будет отправлен в оракул узла для верификации.

3. Узел Oracle будет проверять, соответствует ли ZK Proof, отправленный ZK-пулом Lmuoz, данным Batch, отправленным Sequencer. Если два элемента могут быть сопоставлены и не содержат других ошибок, верификация пройдена. Во время этого процесса децентрализованные узлы Oracle будут генерировать мультиподписи через пороговые подписи и объявлять внешнему миру, что секвенсор полностью отправил данные DA, и соответствующий ZKP действителен и прошел верификацию узлов Oracle.

4. Секвенсор собирает результаты мультиподписи от узлов Oracle. Когда количество подписей соответствует требованиям порога, информация о подписи отправляется в цепочку биткоинов вместе с datahash DA-данных (пакет данных) и передается во внешний мир для чтения и подтверждения.

(Источник диаграммы принципа работы Merlin: Geek web3)

1. Оракул узлы выполняют специальную обработку процесса вычисления проверки ZK Proof, генерируют обязательства Commitment и отправляют их в цепочку Bitcoin, позволяя любому вызвать вызов "обязательство". Процесс здесь в основном такой же, как у протокола доказательства мошенничества bitVM. Если вызов успешен, оракульный узел, который выпустил обязательство, будет финансово наказан. Конечно, данные, которые Оракул хочет опубликовать в цепочке Bitcoin, также включают хэш текущего состояния уровня 2 - StateRoot, а также сам ZKP, который должен быть опубликован в цепочке Bitcoin для внешнего обнаружения.

Ссылки:«Минималистичная интерпретация BitVM: как проверить доказательства мошенничества в цепочке BTC»

Здесь нужно разъяснить несколько деталей. Прежде всего, в дорожной карте Мерлина упоминается, что Оракл в будущем будет резервировать данные DA в Celestia. Таким образом, узлы Оракла могут правильно удалять локальные исторические данные без необходимости сохранения данных локально. В то же время, Коммит, сгенерированный сетью Оракла, на самом деле является корнем дерева Меркля. Недостаточно раскрывать корень внешнему миру. Полный набор данных, соответствующих Коммиту, должен быть общедоступным. Для этого требуется найти стороннюю платформу DA. Этой платформой может быть Celestia или EigenDA, или другие уровни DA.

References:“Анализ B^2 Новой Версии Технологической Дорожной Карты: Необходимость DA и Уровня Проверки под Цепью Биткойна”

Анализ модели безопасности: Оптимистичный ZKRollup + MPC-сервис Cobo

Выше мы кратко описали рабочий процесс Merlin, и я уверен, что вы уже освоили его основную структуру. Не трудно заметить, что Merlin, B^Square, BitLayer и Citrea в основном следуют одной и той же модели безопасности — оптимистичный ZK-Rollup.

Когда многие энтузиасты Ethereum впервые встречают это слово, им может показаться странным. Что такое «оптимистичный ZK-Rollup»? По пониманию сообщества Ethereum, «теоретическая модель» ZK Rollup полностью основана на надежности криптографических вычислений и не требует введения доверительных предположений. Слово «оптимистичный» точно вводит доверительное предположение, что означает, что люди в большинстве случаев оптимистично считают, что у Rollup нет ошибок и он надежен. Как только происходит ошибка, оператор Rollup может быть наказан путем доказательства мошенничества. В этом и заключается происхождение названия Optimistic Rollup, также известного как OP Rollup.

Для экосистемы Ethereum, на основе Rollup, оптимистичный ZK-Rollup может показаться немного неконкретным, но он идеально подходит для текущей ситуации Bitcoin Layer 2. Из-за технических ограничений цепь Bitcoin не может полностью проверить ZK Proof. Под определенными обстоятельствами она может только проверить определенный шаг вычислительного процесса ZKP. На основе этого предположения цепь Bitcoin фактически может только поддерживать протокол доказательства мошенничества. Люди могут указать на ошибку в определенном шаге вычислительного процесса ZKP в процессе внеланцевой верификации и оспаривать ее с помощью доказательства мошенничества. Конечно, это нельзя сравнивать с ZK Rollup в стиле Ethereum, но это уже лучшее, чего в настоящее время может достичь Bitcoin Layer 2. Надежная и наиболее безопасная модель безопасности.

При оптимистичной схеме ZK-Rollup, описанной выше, предположим, что в сети Layer 2 есть N людей, у которых есть право инициировать вызовы. Пока один из N вызывающих честен и надежен, и может обнаружить ошибки и инициировать доказательство мошенничества в любое время, переход состояния Layer 2 безопасен.. Конечно, оптимистичный Rollup с относительно высокой степенью завершенности должен также гарантировать, что его мост для вывода также защищен протоколом доказательства мошенничества. Однако почти все Bitcoin Layer 2 в настоящее время не могут обеспечить выполнение этого предположения и должны полагаться на многоадресную/МПК. Так как выбрать многоадресную подпись? Подписание решения МПК стало проблемой, тесно связанной с безопасностью Layer 2.

Мерлин выбрал MPC-сервис Cobo для мостового решения. С использованием мер таких как изоляция горячего и холодного кошелька, мостовые активы совместно управляются Cobo и Merlin Chain. Любое поведение вывода должно быть обработано совместно участниками MPC Cobo и Merlin Chain. По сути, надежность мостового вывода гарантируется через кредитное подтверждение учреждения. Конечно, это только временная мера на этом этапе. По мере улучшения проекта мостовой вывод может быть заменен «оптимистическим мостом» с предположением доверия 1/N путем введения BitVM и протокола доказательства мошенничества. Однако реализация этого будет более сложной. Большие (почти все официальные мосты Layer 2 в настоящее время полагаются на мультиподпись).

В целом, мы можем разобраться, Мерлин представил POS-ориентированную DAC, оптимистичный ZK-Rollup на основе BitVM и решение по обеспечению активов через MPC на основе Cobo, решив проблему DA путем открытия разрешений DAC; обеспечивая безопасность переходов состояний путем введения BitVM и протоколов доказательства мошенничества; обеспечивая надежность моста для вывода средств путем введения службы MPC известной платформы по обеспечению активов Cobo.

Стратегия представления ZKP с двухэтапной верификацией Lumoz

В наших предыдущих обсуждениях мы погружались в безопасную структуру Мерлина и исследовали инновационную концепцию оптимистичных ZK-rollups. Ключевым элементом технологической траектории Мерлина является децентрализованный Prover. Эта роль является ключевой в архитектуре ZK-Rollup, ответственной за создание ZK-доказательств для пакетов, выпущенных Sequencer. Создание доказательств с нулевым разглашением требует значительных ресурсов и представляет собой серьезное испытание.

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

Для ускорения процесса генерации доказательства ZK Merlin примет Prover от Lumoz в качестве сервисного решения. Фактически, это сбор большого количества аппаратных устройств для формирования пула майнинга, а затем распределение вычислительных задач на различные устройства и выделение соответствующих стимулов, что в чем-то похоже на майнинг POW.

В этом децентрализованном решении Prover существует тип атаки, известный как атака фронтраннинга: Предположим, что Агрегатор установил ZKP и отправляет ZKP, чтобы получить вознаграждение. После того как другие агрегаторы видят содержимое ZKP, они публикуют то же самое содержимое перед ним, утверждая, что он сгенерировал ZKP первым. Как решить эту ситуацию?

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

Polygon zkEVM однажды предложил метод, названный Доказательство эффективности, в блоге, в котором указывалось, что для стимулирования конкуренции между различными агрегаторами следует использовать конкурентные средства, и поощрения должны распределяться по принципу "кто первый встал, того и тапки". Агрегатор, который первым отправляет ZK-доказательство на цепь, может получить награду. Конечно, он не упомянул, как решить проблему фронтраннинга MEV.

Lumoz принимает метод подтверждения ZK-сертификата в два этапа. После того как Агрегатор генерирует ZK-сертификат, ему не нужно отправлять полное содержание сразу, а только публикует хеш ZKP. Другими словами, публикует хеш (ZKP+Адрес Агрегатора). Таким образом, даже если другие видят значение хеша, они не знают соответствующего содержания ZKP и не могут прямо перейти вперед;

Если кто-то просто скопирует весь хеш и опубликует его первым, это бессмысленно, потому что хеш содержит адрес конкретного агрегатора X. Даже если агрегатор A опубликует хеш первым, когда будет раскрыто исходное изображение хеша, все также увидят, что адрес агрегатора, содержащийся в нем, принадлежит X, а не A.

Через эту схему представления ZKP с двухэтапной верификацией Мерлин (Lumoz) может решить проблему фронтраннинга, существующую в процессе представления ZKP, тем самым достигнув высокой конкурентоспособности по генерации доказательств нулевого знания, увеличив скорость генерации ZKP.

Фантом Мерлина: межцепочная совместимость

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

Например, учетная запись EOA, управляемая сетью Мерлин, может быть развернута на Polygon. Когда пользователь выдает инструкцию межцепной совместимости на цепочке Мерлин, сеть Мерлин сначала анализирует ее содержимое и генерирует данные транзакции для выполнения на целевой цепочке, а затем Сеть Оракул выполняет обработку подписи MPC по транзакции для генерации подписи. Узел-посредник Мерлин затем выпускает транзакцию на Polygon, завершает последующие операции через активы Мерлин в учетной записи EOA на целевой цепочке, такие как.

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

Подытожить

В этой статье мы кратко интерпретируем общее техническое решение Merlin Chain, которое, по нашему мнению, позволит большему количеству людей понять общий рабочий процесс Merlin и иметь более четкое представление о его модели безопасности. Учитывая, что текущая экосистема Bitcoin находится в разгаре, мы считаем, что такие мероприятия по популяризации технологий ценны и необходимы для широкой публики. Мы будем в дальнейшем вести долгосрочное наблюдение за проектами Merlin, bitLayer, B^Square и другими, чтобы провести более глубокий анализ их технических решений, так что следите за обновлениями!

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

1. Эта статья воспроизведена из [Gateгик веб3], авторские права принадлежат оригинальному автору [Faust], если у вас есть возражения против перепечатки, пожалуйста, свяжитесь Команда Gate Learn, команда обработает это как можно скорее в соответствии с соответствующими процедурами.

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

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