С лета надписей в 2023 году и по настоящее время Биткойн Уровень 2 всегда был изюминкой всего Web3. Несмотря на то, что рост этой области намного позже, чем у Уровень 2 в Ethereum году, при уникальном шарме POW и плавной посадке Спот ETF, Биткойн без учета риска «секьюритизации» всего за полгода привлекла внимание десятков миллиардов долларов капитала для деривативного трека Уровень 2.
В Биткойн Уровень 2 треке Merlin, у которого миллиарды долларов в TVL, несомненно, имеет самую большую объем и самое лонг последователей. Благодаря четким стимулам для ставок и достойной доходности, Merlin появился почти за несколько месяцев, создав экологический миф, который выходит за рамки Blast. С ростом популярности Merlin обсуждение его технических решений становится все более лонг темой.
В этой статье Geek Web3 сосредоточится на технических решениях Merlin Chain, интерпретирует ее опубликованные документы и Протокол дизайнерские идеи, и мы стремимся к тому, чтобы как можно больше лонг людей понимали общий рабочий процесс Merlin и имели более четкое представление о его модели безопасности, чтобы каждый мог понять, как работает этот «головной Биткойн Уровень 2», более интуитивно понятным способом.
Децентрализованная сеть оракулов Merlin: открытый совет DAC вне блокчейна
Для всех уровней 2, будь то Ethereum Уровень 2 или Биткойн Уровень 2, затраты на DA и публикацию данных являются одной из наиболее важных проблем, которые необходимо решить. Из-за самых длительных проблем самой сети Биткойн, которая по своей поддержке не обеспечивает большую пропускную способность данных, как использовать эти шорты DA, стало сложной проблемой для проверки воображения проектов уровня 2.
Один вывод очевиден: если Уровень 2 «напрямую» публикует в Биткойн Блок необработанные данные о транзакциях, он не сможет добиться высокой пропускной способности или низких комиссий. Наиболее популярным решением является либо сжатие как можно меньшего размера данных за счет высокой степени сжатия и выгрузка их в Биткойн Блок, либо публикация данных непосредственно на Биткойн вне блокчейна. **
Вероятно, наиболее известным из Уровень 2 слоев, использующих первый подход, является Citrea, которая намеревается загрузить в Биткойн в блокчейне diff состояния Уровень 2 за определенный период времени, т.е. результаты изменения состояния на лонг счет вместе с соответствующими доказательствами ZK. В этом случае любой желающий может скачать state diff и ZKP с Биткойн Основная сеть для отслеживания результатов изменения состояния Citrea. Этот метод позволяет уменьшить размер данных в цепочке более чем на 90%.
Несмотря на то, что это может значительно уменьшить размер данных, узкое место все равно остается значительным. Если за шорт промежуток времени происходит большое количество изменений состояния счет, Уровень 2 необходимо суммировать и выгружать все изменения этих счет в Биткойн в блокчейне, а конечная стоимость выпуска данных не может быть очень низкой, что видно по самому лонг Ethereum ZK Rollup.
Очень лонг Биткойн Уровень 2 просто пойти по второму пути: напрямую использовать решение Биткойн вне блокчейна DA, либо построить слой DA самостоятельно, либо использовать Celestia, EigenDA и т.д. B^Square, BitLayer и Merlin, главный герой этой статьи, следуют этой схеме масштабирования DA вне блокчейна.
В предыдущей статье Geek web3 - "Анализ новой версии дорожной карты технологии B^2: необходимость Биткойн вне блокчейна DA и уровня верификации" мы упоминали, что **B^2 напрямую имитирует Celestia и строит сеть DA, которая поддерживает функцию выборки данных в вне блокчейна под названием B^2 Hub. «Данные DA», такие как данные транзакции или различия состояния, хранятся в Биткойн вне блокчейна, и в Биткойн Основная сеть загружается только корень datahash/merkle. **
На самом деле он рассматривает Биткойн как доску объявлений Ненадежный: любой может прочитать хэш данных из Биткойн в блокчейне. Когда вы получаете данные DA от поставщика данных вне блокчейна, вы можете проверить, соответствуют ли они в блокчейне datahash, то есть хеш(data1) == datahash1 ?. Если между ними есть соответствие, это означает, что поставщик данных вне блокчейна предоставил вам правильные данные.
Описанный выше процесс может гарантировать, что данные, предоставленные вам вне блокчейна Узел, связаны с определенными «подсказками» на уровне 1, предотвращая злонамеренное предоставление ложных данных на уровне DA. Но здесь есть очень важный сценарий: что, если источник данных, Sequencer, вообще не отправляет соответствующие данные datahash, а только отправляет datahash в Биткойн в блокчейне, но намеренно скрывает соответствующие данные от кого-либо, чтобы прочитать их?
Подобные сценарии включают, помимо прочего, только публикацию ZK-Proof и StateRoot, но не публикацию соответствующих данных DA (данных о различиях в состоянии или транзакциях), хотя люди могут проверить, что процесс вычисления ZKProof действителен, и убедиться, что процесс вычисления от Prev_Stateroot до New_Stateroot действителен, но они не знают, какое счет состояние (состояние) изменилось. В этом случае, несмотря на то, что активы пользователя находятся в безопасности, вы вообще не можете определить фактическое состояние сети, и вы не знаете, какие транзакции были упакованы в цепочке и какие контракты были обновлены.
На самом деле это «сокрытие данных», и Данкрад из Ethereum Foundation кратко обсудил аналогичную проблему в Твиттере в августе 2023 года, конечно, он в основном свеча с длинным фитилем для чего-то под названием «DAC».
Longest Ethereum Layer2, который использует решения DA вне блокчейна, часто создает несколько узлов со специальными разрешениями для формирования комитета, полное название Комитета по доступности данных (DAC). Этот комитет DAC выступает в качестве гаранта, утверждая, что Sequencer публикует полные данные DA (данные о транзакциях или различиях состояния) вне блокчейна. Затем Узел ЦАП коллективно генерирует лонгующий, лонг самый длинный из них соответствует пороговым требованиям (например, 2/4), соответствующий контракт на уровне 1 будет дефолтным, а секвенсор прошел проверку комитета DAC и правдиво выпустил полный вне блокчейна данных DA.
Комитет DAC Ethereum Уровень 2 в основном следует модели POA, позволяя только нескольким KYC или официально назначенным узлам присоединиться к комитету DAC, что делает DAC синонимом «централизованного» и «консорциумного блокчейна». Кроме того, в некоторых Ethereum Уровень 2, использующих модель ЦАП, секвенсор отправляет данные ДАП только узлам-членам ЦАП, и почти никогда не загружает данные в другие места, и любой, кто хочет получить данные ЦАП, должен получить разрешение комитета ЦАП, которое принципиально не отличается от Блокчейн консорциума.
Нет никаких сомнений в том, что DAC должен быть децентрализацией, и уровень 2 не может загружать данные DA непосредственно на уровень 1, но полномочия доступа комитета DAC должны быть открыты для внешнего мира, чтобы предотвратить сговор нескольких людей с целью совершения зла. (Для обсуждения сценария злодеяний DAC, пожалуйста, обратитесь к предыдущему заявлению Данкрада в Twitter)
**BlobStream, ранее предложенный Celestia, по сути, должен заменить централизованный DAC на Celestia, **Ethereum L2-секвенсор может публиковать данные DA в в блокчейне Celestia, если 2/3 узла Celestia подписывает его, эксклюзивный контракт Layer2, развернутый на Ethereum, считает, что секвенсор правдиво высвобождает данные DA, что на самом деле позволяет Узел Celestia выступать в качестве гаранта. Учитывая, что Celestia имеет сотни узлов-валидаторов, можно считать этот большой DAC относительно децентрализованным.
** Решение DA, используемое Merlin, на самом деле близко к BlobStream от Celestia, которое открывает права доступа к DAC в виде POS, чтобы сделать его децентрализованным. Любой человек может запустить DAC Узел лонг, если у него застейкать достаточно ресурсов. В документации Merlin вышеупомянутый узел DAC упоминается как Oracle, и указывается, что будет поддерживаться стейкинг активов BTC, MERL и даже токенов BRC-20, что обеспечивает гибкий механизм стейкинга, а также прокси-стейкинг, аналогичный Lido. (POS-застейкать Протокол Машина Oracle, по сути, является одним из следующих основных сюжетов Мерлина, и застейкать Процентная ставка относительно высоки)
Вот краткое описание рабочего процесса Merlin (картинка ниже):
После получения большого количества запросов на транзакцию секвенсор агрегирует их и генерирует пакет данных, который передается в узел Prover и узел Oracle (DAC децентрализации).
Узел Прувера Мерлина - это децентрализация с использованием услуги Прувер как услуги lumoz. После получения самых длинных пакетов данных майнинг-пул Prover сгенерирует соответствующие zk-SNARKs, после чего ZKP будет отправлен на узел Oracle для проверки.
Узел Oracle проверит, соответствует ли доказательство ZK, отправленное майнинговым пулом Lmuoz ZK, пакету данных, отправленному Sequencer. Если они могут быть соотнесены, и нет других ошибок, это проверяется. В этом процессе Децентрализация Oracle Nodes будут генерировать лонгующий подписи через пороговые подписи, и объявлять внешне - секвенсор полностью выдал данные DA, и валидным является соответствующий ZKP, прошедший проверку Oracle Узел.
Секвенсор собирает результаты подписей лонг из Узел Oracle, и когда количество подписей достигает пороговых требований, он отправляет информацию о подписи Биткойн в блокчейне с хэшем пакета данных DA и передает ее внешнему миру для чтения и подтверждения.
Oracle Узел специальную обработку своего процесса вычислений для проверки ZK Proof, создания обязательства Commit, отправки его в Биткойн в блокчейне и предоставления любому желающему возможности оспорить «обязательство», и процесс в этом процессе в основном такой же, как и доказательство мошенничества Протокол bitVM. Если оспаривание будет успешным, узел Oracle, опубликовавший Обязательство, будет подвергнут финансовому штрафу. Конечно, данные, которые Oracle хочет опубликовать в Биткойн в блокчейне, включая хеш текущего состояния Уровень 2 StateRoot и сам ZKP, должны быть опубликованы в Биткойн в блокчейне, чтобы внешний мир мог их обнаружить.
Есть еще несколько деталей, которые необходимо проработать, прежде всего, в дорожной карте Merlin упоминается, что в будущем Oracle будет создавать резервные копии данных DA в Celestia, чтобы Oracle Узел могли должным образом удалять локальные исторические данные и не должны были хранить данные локально вечно. При этом Обязательство, сгенерированное Oracle Network, на самом деле является корнем дерева Меркла, и недостаточно раскрыть корень внешнему миру, но чтобы раскрыть все полные наборы данных, соответствующие Обязательству, необходимо найти стороннюю платформу DA, которой могут быть Celestia, EigenDA или другие слои DA.
Анализ модели безопасности: оптимистичный сервис MPC ZKRollup+Cobo
Выше мы вкратце описали рабочий процесс Merlin, и я думаю, что вы уже хорошо понимаете его базовую структуру. Нетрудно заметить, что Merlin в основном следует той же модели безопасности, что и B^Square, BitLayer и Citrea - оптимистичный ZK-Rollup.
При первом прочтении этого слова многие энтузиасты лонг Ethereum могут почувствовать себя странно, что такое «оптимистичный ZK-Rollup»? В познании Ethereum сообщества «теоретическая модель» ZK Rollup полностью основана на достоверности расчетов Криптография, и нет необходимости вводить предположения доверия, а слово оптимизм как раз и вводит предположения доверия, а это значит, что люди должны быть оптимистами в том, что роллапы не ошибаются и надежны, когда они лонг большое количество раз. И как только возникает ошибка, оператор Rollup может быть наказан доказательством мошенничества, что является источником названия Optimistic Rollup, также известного как OP Rollup.
Для Ethereum экосистемы домашней базы Rollup оптимистичный ZK-Rollup может показаться немного необычным, но это точно соответствует текущей ситуации Биткойн Уровень 2. Из-за технических ограничений, Биткойн в блокчейне не можете полностью проверить ZK Proof, можете проверить только определенный шаг процесса расчета ZKP при особых обстоятельствах, в соответствии с этой предпосылкой, Биткойн в блокчейне на самом деле можете только поддержка доказательство мошенничества Протокол, люди могут указать, что ZKP в процессе проверки вне блокчейна, определенный шаг вычисления имеет ошибку, и через доказательство мошенничества способ оспорить, конечно, это не может сравниться с ZK Rollup в стиле Ethereum, но он уже Биткойн самый надежный и Самая надежная модель безопасности.
В соответствии с приведенной выше оптимистичной схемой ZK-Rollup, предполагающей, что в сети Уровень 2 есть N авторизованных претендентов, лонг, поскольку 1 из этих N претендентов является честным и надежным и может обнаруживать ошибки и инициировать доказательство мошенничества в любое время, переход состояния Уровень 2 безопасен. Конечно, оптимистичные роллапы с относительно высокой степенью готовности должны обеспечить, чтобы их мосты вывода также были защищены доказательство мошенничества Протокол, и в настоящее время почти все Биткойн Уровень 2 не могут достичь этой предпосылки и должны полагаться на лонг подпись/MPC, поэтому выбор решения лонг подписи/MPC стал проблемой, тесно связанной с безопасностью Уровень 2.
Merlin выбрала сервис MPC Cobo по схеме моста, используя такие меры, как изоляция холодного и горячего кошелька, активы мостов совместно управляются Cobo и Merlin Chain, и любой вывод средств должен обрабатываться совместно участниками MPC Cobo и Merlin Chain, что по существу обеспечивает надежность моста вывода средств через кредитное одобрение учреждения. Конечно, на данном этапе это лишь временная мера, и с постепенным улучшением проекта мост на выход может быть заменен «оптимистичным мост» предположения о доверии 1/N путем внедрения BitVM и доказательство мошенничества Протокол, но приземлиться будет сложнее (в настоящее время почти все официальные мосты Layer2 полагаются на лонг знак).
В целом можно разобраться, что Merlin внедрил ЦАП на основе POS, оптимистичный ZK-Rollup на базе BitVM и MPC решение для хранения активов на базе Cobo, решил проблему DA, открыв разрешения DAC, обеспечил безопасность смены состояния, внедрив BitVM и доказательство мошенничества Протокол, и обеспечил надежность мост вывода, внедрив MPC сервис известной платформы хранения активов Cobo.
Схема отправки ZKP с двухэтапной верификацией на основе Lumoz
Ранее мы прочесали модель безопасности Merlin и ввели концепцию оптимистичного ZK-роллапа. В технологической дорожной карте Merlin также обсуждается доказательство децентрализации. Как мы все знаем, Prover играет ключевую роль в архитектуре ZK-Rollup, которая отвечает за генерацию ZKProofs для пакетов, выпущенных Sequencer, а процесс генерации zk-SNARKs является очень ресурсоемким и очень сложной проблемой.
Для ускорения генерации ZK-доказательств распараллеливание задачи является одной из самых простых операций. ** Так называемая распараллеливание на самом деле заключается в разделении задачи генерации доказательства ZK на разные части, которые выполняются отдельно разными доказательствами, и, наконец, агрегатор-агрегатор агрегирует самые длинные доказательства в единое целое.
В ордер, чтобы ускорить процесс генерации ZK-доказательств, Merlin будет использовать Lumoz Prover как сервисное решение, которое на самом деле заключается в том, чтобы собрать большое количество аппаратных устройств вместе для формирования майнинг-пула, а затем назначать вычислительные задачи различным устройствам и назначать соответствующие стимулы, аналогично майнингу POW.
В этой схеме проверки децентрализации существует класс сценариев атак, широко известных как атаки с опережением: предположим, агрегатор сформировал ZKP и отправляет ZKP в надежде получить вознаграждение. После того, как другие агрегаторы увидели контент ЗКП, они бросились выкладывать перед ним такой же контент, утверждая, что этот ЗКП сделал их же муж, как решить эту ситуацию?
Одно из самых инстинктивных решений, которое может прийти в голову, — присвоить каждому агрегатору определенный номер задачи, например, только агрегатор А может взять задачу 1, а все остальные не получат награду, даже если выполнят задачу 1. Но одна из проблем этого подхода заключается в том, что он не защищает от единой точки риска. Если в агрегаторе А произойдет сбой производительности или произойдет отключение, задача 1 зависнет и не сможет быть завершена. Более того, такая практика распределения задач по одному объекту не является хорошим способом повышения производительности с помощью конкурентных стимулов.
Polygon zkEVM предложил метод под названием Proof of efficiency в сообщении в блоге, в котором говорится, что различные агрегаторы должны поощряться, чтобы конкурировать друг с другом конкурентным образом, и что поощрения должны распределяться в порядке живой очереди, и что первые агрегаторы, отправившие ZK-Proof в цепочку, могут получить вознаграждение. Конечно, он не упомянул, как решить проблему опережения MEV.
Lumoz использует метод отправки доказательства ZK с двухэтапной проверкой, после того, как агрегатор генерирует доказательство ZK, ему не нужно отправлять полный контент, а только публикует хеш ZKP, другими словами, публикует хеш (адрес ZKP+Aggregator). Таким образом, даже если другие видят значение хеша, они не знают соответствующего содержимого ZKP и не могут напрямую ускорить его;
Если кто-то просто скопирует весь хеш и опубликует его первым, это не имеет смысла, потому что хеш содержит Адрес конкретного агрегатора X, и даже если агрегатор А опубликует хеш первым, когда будет раскрыто исходное изображение хеша, все увидят, что содержащийся в нем адрес агрегатора — X, а не A.
Благодаря этой схеме подачи заявок ZKP с двухэтапной проверкой Merlin (Lumoz) может решить проблему опережения в процессе подачи заявок ZKP, а затем реализовать высококонкурентные стимулы для генерации zk-SNARKs, тем самым повышая скорость генерации ZKP.
Призрак Мерлина: самая длинная цепочка взаимодействия
Согласно технической дорожной карте Merlin, они также обеспечат поддержку взаимодействия между Merlin и другими цепочками EVM, и путь ее реализации в основном такой же, как и предыдущая идея Zetachain, если Merlin используется в качестве исходной цепочки, а другие цепочки EVM используются в качестве целевой цепочки, когда узел Merlin воспринимает запрос на кросс-чейн совместимость, сделанный пользователем, он запустит последующий рабочий процесс на целевом блокчейне.
Например, счет EOA, контролируемый сетью Merlin, может быть развернут на Polygon, ** Когда пользователь публикует инструкцию кроссчейн взаимодействия в Merlin Chain, сеть Merlin сначала анализирует ее содержимое и генерирует данные транзакции, выполняемые на целевом блокчейне, а затем обработка подписи MPC Oracle Network для транзакции генерирует цифровую подпись транзакции. Затем узел ретранслятора Merlin освобождает транзакцию ** на Polygon, завершая последующие операции через активы Merlin в счете EOA на целевом блокчейне.
Когда операция, требуемая пользователем, будет завершена, соответствующий актив будет перенаправлен непосредственно на адрес пользователя в блокчейне и теоретически также может напрямую перейти в цепочку Merlin. У этого решения есть несколько очевидных преимуществ: оно позволяет избежать изнашивания комиссий, генерируемых традиционными контрактами на кросс-чейн активов и кроссчейн мост, и оно напрямую гарантируется сетью Oracle Network Merlin, что обеспечивает безопасность кросс-чейн операций, и лонгующий не нужно полагаться на внешнюю инфраструктуру. Поскольку лонг пользователи доверяют Merlin Chain, нет никаких проблем с тем, чтобы по умолчанию использовать такую кросс-чейн совместимости.
Резюме
В этой статье мы даем краткое объяснение общего технического решения Merlin Chain, которое, как считается, поможет большему количеству людей лонг понять общий рабочий процесс Merlin и иметь более четкое представление о его модели безопасности. Учитывая нынешнюю экологию Биткойна в полном разгаре, мы считаем, что такого рода популяризация технических наук ценна и необходима широкой публике, В будущем мы будем проводить лонг мониторинг Merlin и bitLayer, B^Square и других проектов, а также проводить более глубокий анализ его технических решений, так что оставайтесь на связи!
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Техническая интерпретация рабочего механизма Merlin
Автор: Faust, geek web3
С лета надписей в 2023 году и по настоящее время Биткойн Уровень 2 всегда был изюминкой всего Web3. Несмотря на то, что рост этой области намного позже, чем у Уровень 2 в Ethereum году, при уникальном шарме POW и плавной посадке Спот ETF, Биткойн без учета риска «секьюритизации» всего за полгода привлекла внимание десятков миллиардов долларов капитала для деривативного трека Уровень 2.
В Биткойн Уровень 2 треке Merlin, у которого миллиарды долларов в TVL, несомненно, имеет самую большую объем и самое лонг последователей. Благодаря четким стимулам для ставок и достойной доходности, Merlin появился почти за несколько месяцев, создав экологический миф, который выходит за рамки Blast. С ростом популярности Merlin обсуждение его технических решений становится все более лонг темой.
В этой статье Geek Web3 сосредоточится на технических решениях Merlin Chain, интерпретирует ее опубликованные документы и Протокол дизайнерские идеи, и мы стремимся к тому, чтобы как можно больше лонг людей понимали общий рабочий процесс Merlin и имели более четкое представление о его модели безопасности, чтобы каждый мог понять, как работает этот «головной Биткойн Уровень 2», более интуитивно понятным способом.
Децентрализованная сеть оракулов Merlin: открытый совет DAC вне блокчейна
Для всех уровней 2, будь то Ethereum Уровень 2 или Биткойн Уровень 2, затраты на DA и публикацию данных являются одной из наиболее важных проблем, которые необходимо решить. Из-за самых длительных проблем самой сети Биткойн, которая по своей поддержке не обеспечивает большую пропускную способность данных, как использовать эти шорты DA, стало сложной проблемой для проверки воображения проектов уровня 2.
Один вывод очевиден: если Уровень 2 «напрямую» публикует в Биткойн Блок необработанные данные о транзакциях, он не сможет добиться высокой пропускной способности или низких комиссий. Наиболее популярным решением является либо сжатие как можно меньшего размера данных за счет высокой степени сжатия и выгрузка их в Биткойн Блок, либо публикация данных непосредственно на Биткойн вне блокчейна. **
Вероятно, наиболее известным из Уровень 2 слоев, использующих первый подход, является Citrea, которая намеревается загрузить в Биткойн в блокчейне diff состояния Уровень 2 за определенный период времени, т.е. результаты изменения состояния на лонг счет вместе с соответствующими доказательствами ZK. В этом случае любой желающий может скачать state diff и ZKP с Биткойн Основная сеть для отслеживания результатов изменения состояния Citrea. Этот метод позволяет уменьшить размер данных в цепочке более чем на 90%.
Несмотря на то, что это может значительно уменьшить размер данных, узкое место все равно остается значительным. Если за шорт промежуток времени происходит большое количество изменений состояния счет, Уровень 2 необходимо суммировать и выгружать все изменения этих счет в Биткойн в блокчейне, а конечная стоимость выпуска данных не может быть очень низкой, что видно по самому лонг Ethereum ZK Rollup.
Очень лонг Биткойн Уровень 2 просто пойти по второму пути: напрямую использовать решение Биткойн вне блокчейна DA, либо построить слой DA самостоятельно, либо использовать Celestia, EigenDA и т.д. B^Square, BitLayer и Merlin, главный герой этой статьи, следуют этой схеме масштабирования DA вне блокчейна.
В предыдущей статье Geek web3 - "Анализ новой версии дорожной карты технологии B^2: необходимость Биткойн вне блокчейна DA и уровня верификации" мы упоминали, что **B^2 напрямую имитирует Celestia и строит сеть DA, которая поддерживает функцию выборки данных в вне блокчейна под названием B^2 Hub. «Данные DA», такие как данные транзакции или различия состояния, хранятся в Биткойн вне блокчейна, и в Биткойн Основная сеть загружается только корень datahash/merkle. **
На самом деле он рассматривает Биткойн как доску объявлений Ненадежный: любой может прочитать хэш данных из Биткойн в блокчейне. Когда вы получаете данные DA от поставщика данных вне блокчейна, вы можете проверить, соответствуют ли они в блокчейне datahash, то есть хеш(data1) == datahash1 ?. Если между ними есть соответствие, это означает, что поставщик данных вне блокчейна предоставил вам правильные данные.
Описанный выше процесс может гарантировать, что данные, предоставленные вам вне блокчейна Узел, связаны с определенными «подсказками» на уровне 1, предотвращая злонамеренное предоставление ложных данных на уровне DA. Но здесь есть очень важный сценарий: что, если источник данных, Sequencer, вообще не отправляет соответствующие данные datahash, а только отправляет datahash в Биткойн в блокчейне, но намеренно скрывает соответствующие данные от кого-либо, чтобы прочитать их?
Подобные сценарии включают, помимо прочего, только публикацию ZK-Proof и StateRoot, но не публикацию соответствующих данных DA (данных о различиях в состоянии или транзакциях), хотя люди могут проверить, что процесс вычисления ZKProof действителен, и убедиться, что процесс вычисления от Prev_Stateroot до New_Stateroot действителен, но они не знают, какое счет состояние (состояние) изменилось. В этом случае, несмотря на то, что активы пользователя находятся в безопасности, вы вообще не можете определить фактическое состояние сети, и вы не знаете, какие транзакции были упакованы в цепочке и какие контракты были обновлены.
На самом деле это «сокрытие данных», и Данкрад из Ethereum Foundation кратко обсудил аналогичную проблему в Твиттере в августе 2023 года, конечно, он в основном свеча с длинным фитилем для чего-то под названием «DAC».
Longest Ethereum Layer2, который использует решения DA вне блокчейна, часто создает несколько узлов со специальными разрешениями для формирования комитета, полное название Комитета по доступности данных (DAC). Этот комитет DAC выступает в качестве гаранта, утверждая, что Sequencer публикует полные данные DA (данные о транзакциях или различиях состояния) вне блокчейна. Затем Узел ЦАП коллективно генерирует лонгующий, лонг самый длинный из них соответствует пороговым требованиям (например, 2/4), соответствующий контракт на уровне 1 будет дефолтным, а секвенсор прошел проверку комитета DAC и правдиво выпустил полный вне блокчейна данных DA.
Комитет DAC Ethereum Уровень 2 в основном следует модели POA, позволяя только нескольким KYC или официально назначенным узлам присоединиться к комитету DAC, что делает DAC синонимом «централизованного» и «консорциумного блокчейна». Кроме того, в некоторых Ethereum Уровень 2, использующих модель ЦАП, секвенсор отправляет данные ДАП только узлам-членам ЦАП, и почти никогда не загружает данные в другие места, и любой, кто хочет получить данные ЦАП, должен получить разрешение комитета ЦАП, которое принципиально не отличается от Блокчейн консорциума.
Нет никаких сомнений в том, что DAC должен быть децентрализацией, и уровень 2 не может загружать данные DA непосредственно на уровень 1, но полномочия доступа комитета DAC должны быть открыты для внешнего мира, чтобы предотвратить сговор нескольких людей с целью совершения зла. (Для обсуждения сценария злодеяний DAC, пожалуйста, обратитесь к предыдущему заявлению Данкрада в Twitter)
**BlobStream, ранее предложенный Celestia, по сути, должен заменить централизованный DAC на Celestia, **Ethereum L2-секвенсор может публиковать данные DA в в блокчейне Celestia, если 2/3 узла Celestia подписывает его, эксклюзивный контракт Layer2, развернутый на Ethereum, считает, что секвенсор правдиво высвобождает данные DA, что на самом деле позволяет Узел Celestia выступать в качестве гаранта. Учитывая, что Celestia имеет сотни узлов-валидаторов, можно считать этот большой DAC относительно децентрализованным.
** Решение DA, используемое Merlin, на самом деле близко к BlobStream от Celestia, которое открывает права доступа к DAC в виде POS, чтобы сделать его децентрализованным. Любой человек может запустить DAC Узел лонг, если у него застейкать достаточно ресурсов. В документации Merlin вышеупомянутый узел DAC упоминается как Oracle, и указывается, что будет поддерживаться стейкинг активов BTC, MERL и даже токенов BRC-20, что обеспечивает гибкий механизм стейкинга, а также прокси-стейкинг, аналогичный Lido. (POS-застейкать Протокол Машина Oracle, по сути, является одним из следующих основных сюжетов Мерлина, и застейкать Процентная ставка относительно высоки)
Вот краткое описание рабочего процесса Merlin (картинка ниже):
Oracle Узел специальную обработку своего процесса вычислений для проверки ZK Proof, создания обязательства Commit, отправки его в Биткойн в блокчейне и предоставления любому желающему возможности оспорить «обязательство», и процесс в этом процессе в основном такой же, как и доказательство мошенничества Протокол bitVM. Если оспаривание будет успешным, узел Oracle, опубликовавший Обязательство, будет подвергнут финансовому штрафу. Конечно, данные, которые Oracle хочет опубликовать в Биткойн в блокчейне, включая хеш текущего состояния Уровень 2 StateRoot и сам ZKP, должны быть опубликованы в Биткойн в блокчейне, чтобы внешний мир мог их обнаружить.
Есть еще несколько деталей, которые необходимо проработать, прежде всего, в дорожной карте Merlin упоминается, что в будущем Oracle будет создавать резервные копии данных DA в Celestia, чтобы Oracle Узел могли должным образом удалять локальные исторические данные и не должны были хранить данные локально вечно. При этом Обязательство, сгенерированное Oracle Network, на самом деле является корнем дерева Меркла, и недостаточно раскрыть корень внешнему миру, но чтобы раскрыть все полные наборы данных, соответствующие Обязательству, необходимо найти стороннюю платформу DA, которой могут быть Celestia, EigenDA или другие слои DA.
Анализ модели безопасности: оптимистичный сервис MPC ZKRollup+Cobo
Выше мы вкратце описали рабочий процесс Merlin, и я думаю, что вы уже хорошо понимаете его базовую структуру. Нетрудно заметить, что Merlin в основном следует той же модели безопасности, что и B^Square, BitLayer и Citrea - оптимистичный ZK-Rollup.
При первом прочтении этого слова многие энтузиасты лонг Ethereum могут почувствовать себя странно, что такое «оптимистичный ZK-Rollup»? В познании Ethereum сообщества «теоретическая модель» ZK Rollup полностью основана на достоверности расчетов Криптография, и нет необходимости вводить предположения доверия, а слово оптимизм как раз и вводит предположения доверия, а это значит, что люди должны быть оптимистами в том, что роллапы не ошибаются и надежны, когда они лонг большое количество раз. И как только возникает ошибка, оператор Rollup может быть наказан доказательством мошенничества, что является источником названия Optimistic Rollup, также известного как OP Rollup.
Для Ethereum экосистемы домашней базы Rollup оптимистичный ZK-Rollup может показаться немного необычным, но это точно соответствует текущей ситуации Биткойн Уровень 2. Из-за технических ограничений, Биткойн в блокчейне не можете полностью проверить ZK Proof, можете проверить только определенный шаг процесса расчета ZKP при особых обстоятельствах, в соответствии с этой предпосылкой, Биткойн в блокчейне на самом деле можете только поддержка доказательство мошенничества Протокол, люди могут указать, что ZKP в процессе проверки вне блокчейна, определенный шаг вычисления имеет ошибку, и через доказательство мошенничества способ оспорить, конечно, это не может сравниться с ZK Rollup в стиле Ethereum, но он уже Биткойн самый надежный и Самая надежная модель безопасности.
В соответствии с приведенной выше оптимистичной схемой ZK-Rollup, предполагающей, что в сети Уровень 2 есть N авторизованных претендентов, лонг, поскольку 1 из этих N претендентов является честным и надежным и может обнаруживать ошибки и инициировать доказательство мошенничества в любое время, переход состояния Уровень 2 безопасен. Конечно, оптимистичные роллапы с относительно высокой степенью готовности должны обеспечить, чтобы их мосты вывода также были защищены доказательство мошенничества Протокол, и в настоящее время почти все Биткойн Уровень 2 не могут достичь этой предпосылки и должны полагаться на лонг подпись/MPC, поэтому выбор решения лонг подписи/MPC стал проблемой, тесно связанной с безопасностью Уровень 2.
Merlin выбрала сервис MPC Cobo по схеме моста, используя такие меры, как изоляция холодного и горячего кошелька, активы мостов совместно управляются Cobo и Merlin Chain, и любой вывод средств должен обрабатываться совместно участниками MPC Cobo и Merlin Chain, что по существу обеспечивает надежность моста вывода средств через кредитное одобрение учреждения. Конечно, на данном этапе это лишь временная мера, и с постепенным улучшением проекта мост на выход может быть заменен «оптимистичным мост» предположения о доверии 1/N путем внедрения BitVM и доказательство мошенничества Протокол, но приземлиться будет сложнее (в настоящее время почти все официальные мосты Layer2 полагаются на лонг знак).
В целом можно разобраться, что Merlin внедрил ЦАП на основе POS, оптимистичный ZK-Rollup на базе BitVM и MPC решение для хранения активов на базе Cobo, решил проблему DA, открыв разрешения DAC, обеспечил безопасность смены состояния, внедрив BitVM и доказательство мошенничества Протокол, и обеспечил надежность мост вывода, внедрив MPC сервис известной платформы хранения активов Cobo.
Схема отправки ZKP с двухэтапной верификацией на основе Lumoz
Ранее мы прочесали модель безопасности Merlin и ввели концепцию оптимистичного ZK-роллапа. В технологической дорожной карте Merlin также обсуждается доказательство децентрализации. Как мы все знаем, Prover играет ключевую роль в архитектуре ZK-Rollup, которая отвечает за генерацию ZKProofs для пакетов, выпущенных Sequencer, а процесс генерации zk-SNARKs является очень ресурсоемким и очень сложной проблемой.
Для ускорения генерации ZK-доказательств распараллеливание задачи является одной из самых простых операций. ** Так называемая распараллеливание на самом деле заключается в разделении задачи генерации доказательства ZK на разные части, которые выполняются отдельно разными доказательствами, и, наконец, агрегатор-агрегатор агрегирует самые длинные доказательства в единое целое.
В ордер, чтобы ускорить процесс генерации ZK-доказательств, Merlin будет использовать Lumoz Prover как сервисное решение, которое на самом деле заключается в том, чтобы собрать большое количество аппаратных устройств вместе для формирования майнинг-пула, а затем назначать вычислительные задачи различным устройствам и назначать соответствующие стимулы, аналогично майнингу POW.
В этой схеме проверки децентрализации существует класс сценариев атак, широко известных как атаки с опережением: предположим, агрегатор сформировал ZKP и отправляет ZKP в надежде получить вознаграждение. После того, как другие агрегаторы увидели контент ЗКП, они бросились выкладывать перед ним такой же контент, утверждая, что этот ЗКП сделал их же муж, как решить эту ситуацию?
Одно из самых инстинктивных решений, которое может прийти в голову, — присвоить каждому агрегатору определенный номер задачи, например, только агрегатор А может взять задачу 1, а все остальные не получат награду, даже если выполнят задачу 1. Но одна из проблем этого подхода заключается в том, что он не защищает от единой точки риска. Если в агрегаторе А произойдет сбой производительности или произойдет отключение, задача 1 зависнет и не сможет быть завершена. Более того, такая практика распределения задач по одному объекту не является хорошим способом повышения производительности с помощью конкурентных стимулов.
Polygon zkEVM предложил метод под названием Proof of efficiency в сообщении в блоге, в котором говорится, что различные агрегаторы должны поощряться, чтобы конкурировать друг с другом конкурентным образом, и что поощрения должны распределяться в порядке живой очереди, и что первые агрегаторы, отправившие ZK-Proof в цепочку, могут получить вознаграждение. Конечно, он не упомянул, как решить проблему опережения MEV.
Lumoz использует метод отправки доказательства ZK с двухэтапной проверкой, после того, как агрегатор генерирует доказательство ZK, ему не нужно отправлять полный контент, а только публикует хеш ZKP, другими словами, публикует хеш (адрес ZKP+Aggregator). Таким образом, даже если другие видят значение хеша, они не знают соответствующего содержимого ZKP и не могут напрямую ускорить его;
Если кто-то просто скопирует весь хеш и опубликует его первым, это не имеет смысла, потому что хеш содержит Адрес конкретного агрегатора X, и даже если агрегатор А опубликует хеш первым, когда будет раскрыто исходное изображение хеша, все увидят, что содержащийся в нем адрес агрегатора — X, а не A.
Благодаря этой схеме подачи заявок ZKP с двухэтапной проверкой Merlin (Lumoz) может решить проблему опережения в процессе подачи заявок ZKP, а затем реализовать высококонкурентные стимулы для генерации zk-SNARKs, тем самым повышая скорость генерации ZKP.
Призрак Мерлина: самая длинная цепочка взаимодействия
Согласно технической дорожной карте Merlin, они также обеспечат поддержку взаимодействия между Merlin и другими цепочками EVM, и путь ее реализации в основном такой же, как и предыдущая идея Zetachain, если Merlin используется в качестве исходной цепочки, а другие цепочки EVM используются в качестве целевой цепочки, когда узел Merlin воспринимает запрос на кросс-чейн совместимость, сделанный пользователем, он запустит последующий рабочий процесс на целевом блокчейне.
Например, счет EOA, контролируемый сетью Merlin, может быть развернут на Polygon, ** Когда пользователь публикует инструкцию кроссчейн взаимодействия в Merlin Chain, сеть Merlin сначала анализирует ее содержимое и генерирует данные транзакции, выполняемые на целевом блокчейне, а затем обработка подписи MPC Oracle Network для транзакции генерирует цифровую подпись транзакции. Затем узел ретранслятора Merlin освобождает транзакцию ** на Polygon, завершая последующие операции через активы Merlin в счете EOA на целевом блокчейне.
Когда операция, требуемая пользователем, будет завершена, соответствующий актив будет перенаправлен непосредственно на адрес пользователя в блокчейне и теоретически также может напрямую перейти в цепочку Merlin. У этого решения есть несколько очевидных преимуществ: оно позволяет избежать изнашивания комиссий, генерируемых традиционными контрактами на кросс-чейн активов и кроссчейн мост, и оно напрямую гарантируется сетью Oracle Network Merlin, что обеспечивает безопасность кросс-чейн операций, и лонгующий не нужно полагаться на внешнюю инфраструктуру. Поскольку лонг пользователи доверяют Merlin Chain, нет никаких проблем с тем, чтобы по умолчанию использовать такую кросс-чейн совместимости.
Резюме
В этой статье мы даем краткое объяснение общего технического решения Merlin Chain, которое, как считается, поможет большему количеству людей лонг понять общий рабочий процесс Merlin и иметь более четкое представление о его модели безопасности. Учитывая нынешнюю экологию Биткойна в полном разгаре, мы считаем, что такого рода популяризация технических наук ценна и необходима широкой публике, В будущем мы будем проводить лонг мониторинг Merlin и bitLayer, B^Square и других проектов, а также проводить более глубокий анализ его технических решений, так что оставайтесь на связи!