Знакомство:

Нынешняя сцена Bitcoin Layer2 кишит разнообразными технологическими решениями, сходящимися в плавильном котле экосистемы BTC. Учитывая быстрый темп итераций в области блокчейна, где профессиональный словарь и стандарты постоянно развиваются благодаря исследованиям, инновациям и инженерным внедрениям, многие проекты прибегают к «созданию концепций» или «концептуальному автостопу» для дифференциации и внимания, становясь негласным правилом в отрасли. Например, несколько модульных блокчейн-проектов, первоначально активных в экосистеме Ethereum/Celestia, вскочили на подножку «Bitcoin Layer2», назвав себя «роллапами», несмотря на то, что их технические решения часто не соответствуют стандартам Rollup. Тем не менее, термин «Роллап» несет в себе значительную узнаваемость, что делает его выгодным для рекламных целей. Многие операторы проектов либо принудительно маркируют себя как Rollups, либо разветвляют основную концепцию Rollup с помощью расплывчатых квалификаторов, таких как «Sovereign Rollup». Отслаивая слои этих «XX Rollups», многие проекты, по сути, основаны на «валидации на стороне клиента» или «сайдчейнах», просто используя слоган «XX Rollup» для удобства. Хотя эта рекламная стратегия распространена, она, как правило, вводит в заблуждение, принося больше вреда, чем пользы тем, кто ищет истину.

(Этот подход, подытоженный министром пропаганды нацистов Геббельсом как "пропаганда на основе лжи", часто наблюдается среди операторов проекта.) Как тогда мы можем различить такое поведение, как "поддержка концепции Rollup"? Возможно, начиная с первичных принципов, определение различных категорий проектов Layer2 и их уровней безопасности и функциональности на основе широко принятых стандартов на Западе и в отрасли, можно предложить ясность. Здесь не обязательно выбранное решение; основа заключается в том, обеспечивает ли механизм проекта безопасность и надежность сети Layer2 и действительно усиливает основную сеть BTC.

Эта статья будет использовать Chainway, проект Bitcoin Layer2, в качестве кейс-стади для анализа скрытой природы «валидации с клиентской стороны», заложенной в некоторых проектах под лозунгом «Rollup». Мы стремимся четко различить между «Sovereign Rollup» и «валидацией с клиентской стороны», а также значительные различия от стандартных в индустрии ZKRollups или OPRollups, которые зависят от смарт-контрактов. Это не означает, что Sovereign Rollups или валидации с клиентской стороны уступают ZK Rollups в безопасности и надежности; все зависит от конкретных деталей их реализации. Chainway, как правило, использует валидацию с клиентской стороны Layer2, предложил схему транзакций против цензуры, запущенную на BTC с валидацией за пределами цепи, используя рекурсивные ZK-доказательства, аналогичные тем, которые использует общедоступная цепь MINA, что позволяет ему опережать многие проекты Bitcoin Layer2. Мы считаем, что исследование технологии Chainway ценно и предлагает значительные идеи для наблюдателей Bitcoin Layer2. (Промо-изображения Chainway позиционируют его как ZK Rollup, но его старое решение было валидацией с клиентской стороны, а ZKR — еще один их проект. В настоящее время он не достиг согласия клиентов за пределами цепи или надежного обмена сообщениями.)

Основной текст: Chainway — это хорошо известный в западном сообществе проект Bitcoin Layer2, который многие лидеры мнений часто называют «ZK Rollup», а его техническая документация позиционирует его как «Sovereign Rollup». Недавно Chainway также объявила о своем новом проекте Citrea, утверждая, что это ZK Rollup, основанный на BitVM. Однако, поскольку Citrea еще не детализировала свое решение для верификации ZK на основе BitVM, в этой статье мы сосредоточимся на технической интерпретации предыдущих решений Chainway. Таким образом, публично раскрытое техническое решение Chainway включает в себя публикацию данных DA через протокол Ordinals, использование BTC в качестве уровня DA и публикацию сведений об изменении состояния (State diff) + ZK Proof, проверяющих правильность изменений состояния на уровне 1, что эквивалентно публикации полных, проверяемых данных о транзакциях. Однако, поскольку Layer1 не проверяет ZK Proofs напрямую, а проверка проводится независимыми клиентами/узлами вне сети, а текущая кодовая база Chainway не достигла консенсуса среди клиентов вне сети, и она не утверждала, что решает эту проблему в социальных сетях, публично раскрытое техническое решение Chainway, по сути, относится к категории «проверки на стороне клиента», даже напоминая криптографически индексированный протокол, поддерживающий мост активов. В следующих разделах мы познакомимся с конкретной технической реализацией Chainway и проанализируем ее модель безопасности.

Что такое Суверенный Роллап: Публикация слоя доступности данных (DA) + Верификация вне цепи

В технической документации Chainway используется концепция Суверенного Роллапа от Celestia. Суверенный Роллап фундаментально отличается от основной концепции Роллапа в сообществе Ethereum и широкой индустрии (Роллап смарт-контрактов). Так что же именно представляет из себя структура Суверенного Роллапа?

По сути, суверенный роллап на основе биткоина чем-то похож на «внецепочечную клиентскую группу/сайдчейн, публикующий данные DA в блокчейне BTC». Его основная характеристика заключается в том, что он не требует смарт-контрактов на уровне 1 для проверки переходов состояний/межсетевых действий для уровня 2. По сути, он использует BTC в качестве уровня DA, а его модель безопасности во многом похожа на «проверку на стороне клиента». Конечно, некоторые более безопасные решения Sovereign Rollup полагаются на сторонний расчетный уровень вне цепочки Биткойна (аналогично сайдчейну) для выполнения проверок перехода состояния. Кроме того, между различными независимыми клиентами/полными узлами существует уровень консенсуса или надежной передачи сообщений для достижения «соглашения» по определенным спорным действиям. Тем не менее, некоторые проекты Sovereign Rollup основаны исключительно на «проверке на стороне клиента», не имея какого-либо надежного обмена сообщениями между независимыми клиентами/узлами.

Чтобы лучше понять уникальную концепцию «Sovereign Rollup», полезно сравнить его с его аналогом, смарт-контрактом Rollup. На Ethereum решения уровня 2 — это преимущественно роллапы смарт-контрактов, такие как Arbitrum и StarkNet. Структуру смарт-контракта Rollup можно визуализировать на следующей схеме:

(Представьте здесь диаграмму)

На диаграмме мы видим несколько терминов, связанных с модульным блокчейн-рассказом, объясненных следующим образом:

• Слой исполнения: Выполняет транзакции пользователей, обновляет состояние блокчейна и отправляет данные на уровень DA и расчетный уровень.

• Слой расчетов: Проверяет переходы между состояниями на уровне исполнения, разрешает споры (например, доказательства мошенничества) и предоставляет модуль моста для работы с промежуточными активами L1-L2.

• Уровень доступности данных (DA): Действует как большая доска объявлений, получая данные о переходе состояний, отправленные уровнем исполнения, и предоставляя эти данные в доверительном режиме любому желающему.

• Слой консенсуса: Обеспечивает окончательность порядка транзакций. Его функция кажется несколько близкой к слою DA (подход сообщества Ethereum к модульному слою блокчейна не включает слой консенсуса).
  
  Из архитектуры умных контрактов Rollups мы видим, что Ethereum играет роль последних трех слоев, помимо слоя исполнения. Другая диаграмма может предоставить более детальное представление о ролях, которые Ethereum играет в умных контрактах Rollups.
  
  В отличие от этого, Суверенные Роллапы значительно отличаются тем, что децентрализуют часть этих обязанностей от монолитного блокчейна, такого как Ethereum. В частности, они не полагаются на смарт-контракты на базовом уровне (Уровень 1) для верификации переходов состояний или разрешения споров. Вместо этого эти задачи управляются клиентами вне цепи или через сторонний слой расчетов, подчеркивая другой подход к достижению масштабируемости и безопасности в блокчейн-системах.

Смарт-контракты Rollup на Ethereum получают либо доказательства действительности, либо доказательства мошенничества для проверки действительности переходов состояния уровня 2. Следует отметить, что смарт-контракты Rollup действуют как сущности слоя расчетов в модульной архитектуре блокчейна. Контракты расчетного слоя часто включают модули моста для обработки активов, перенесенных с Ethereum на уровень 2. Для доступности данных (DA) контракты расчетного слоя могут обязать Секвенсора размещать на цепи последние данные о транзакциях/деталях изменения состояния. Без размещения DA на цепи невозможно успешно обновить состояние L2, записанное в контрактах Rollup.

(ZK Rollup или Optimistic Rollup может принудительно публиковать данные DA в блокчейне; без него состояние, записанное в расчетном слое, не может быть обновлено.) Из анализа модели безопасности и индикаторов риска решений Bitcoin/Ethereum Layer 2 с теорией барреля становится ясно, что роллапы смарт-контрактов в значительной степени зависят от смарт-контрактов уровня 1. Для уровня 1, такого как BTC, который изо всех сил пытается поддерживать сложную бизнес-логику, создание уровня 2, соответствующего GitHub, практически невозможно. С другой стороны, решения Sovereign Rollup не требуют контрактов на уровне 1 для государственной проверки/промежуточного подключения. Их архитектура выглядит следующим образом: (Здесь отсутствует описание архитектуры, подразумевая, что иллюстрация или дополнительные детали должны были быть включены, но не представлены в тексте.)

В суверенных Rollups узлы за пределами слоя доступности данных (DA) служат сущностями для выполнения транзакций и операций по урегулированию, обеспечивая более высокую степень свободы. Рабочий процесс следующий:

Узлы на уровне исполнения суверенного роллапа отправляют данные о транзакциях/сведения об изменении состояния на уровень DA, в то время как расчетный уровень/клиенты стремятся получить и проверить данные. Важно отметить, что, поскольку модуль расчетного уровня не расположен на уровне 1, суверенные роллапы теоретически не могут создать мосты с безопасностью, эквивалентной уровню 1. Они часто полагаются на нотариальные мосты или сторонние мостовые решения. В настоящее время реализация суверенных схем Rollup/верификации клиентов относительно проста и требует только публикации данных в цепочке Bitcoin (BTC) с использованием протокола, аналогичного Ordinals. Что касается оффчейн-верификации и консенсуса, то здесь существует большая гибкость. На самом деле, многие сайдчейны просто публикуют данные DA в цепочке BTC, по сути, становясь «суверенными роллапами на основе BTC», хотя конкретная безопасность сомнительна. Однако проблема заключается в том, что пропускная способность данных Биткойна чрезвычайно низкая, максимум 4 МБ на блок и среднее время блока 10 минут, что соответствует пропускной способности данных всего 6 КБ/с. Решения уровня 2, претендующие на статус суверенных роллапов, могут быть не в состоянии опубликовать все данные DA в цепочке BTC, поэтому они могут выбрать альтернативные методы, такие как публикация данных DA вне цепочки и хранение хэша данных в цепочке BTC в качестве формы «обязательства» или поиск способа сильного сжатия данных DA (например, используя State diff + ZK Proof, как утверждает Chainway). Очевидно, что этот режим не соответствует определению «суверенного Роллапа» или собственно Роллапа, представляя собой вариант, безопасность которого сомнительна. Мы прогнозируем, что большинство проектов уровня 2 с баннером «Rollup» в конечном итоге не опубликуют все данные DA в цепочке BTC, поэтому их практические решения, скорее всего, не будут соответствовать заявлениям «ZK Rollup» или «OP Rollup», сделанным в их технических документах.

Наконец, давайте кратко опишем различия между суверенными Rollups и Rollups на умных контрактах:

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

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

Структура BTC DA

В вышеупомянутом тексте мы упомянули, что для реализации суверенного Rollup на основе BTC ключевое значение имеет использование протокола Ordinals для того, чтобы сделать так, чтобы BTC служил в качестве слоя доступности данных (DA). Chainway приняла это решение.

Мы можем изучить представление данных DA от последователь Chainway, с хэшем транзакции:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, иллюстрировано следующим образом:

Этот сценарий транзакции заимствует подход протокола Ordinals, используя OP_0 OP_IF для записи данных, чтобы записать данные DA (доступность данных) Rollup на цепочку BTC. Это включает опубликование изменений состояния и ZK-доказательств, что эквивалентно по безопасности опубликованию исходных данных транзакции, но позволяет значительно сократить размер данных. Помимо данных DA, сиквенсор также записывает некоторые аутентификационные данные в транзакцию, наиболее важным из которых является подпись сиквенсора Rollup на данные DA своим закрытым ключом, чтобы гарантировать, что подача происходит от сиквенсора. Важно отметить, что любая транзакция, включающая подачу данных DA, имеет 16 двоичных нулей в конце хэша транзакции (т. е. два последовательных байта равны нулю). Это ограничение можно увидеть в коде:

В примере графика транзакции, упомянутом ранее, случайное число "b715" используется для корректировки хеш-значения транзакции таким образом, чтобы ее хвост содержал определенные 16 нулей. Этот принцип похож на майнинг биткойнов, где случайное число nonce добавляется, чтобы начальные N бит хэша были равными нулям, удовлетворяя определенным условиям ограничения. Эта схема призвана упростить получение данных DA (Data Availability). Когда какой-либо узел уровня 2 хочет получить доступ к данным DA, ему нужно только просканировать блок BTC (Bitcoin) на наличие всех транзакций, которые заканчиваются 16 нулями, эффективно отличая транзакции, инициированные сортировщиком Chainway при отправке данных, от других транзакций в блокчейне Биткойна. В следующем тексте такие транзакции, содержащие данные DA и удовлетворяющие требованию оканчиваться на 16 нулей, называются «стандартными транзакциями Chainway». Основное внимание в этой статье уделяется тому, как Chainway достигает устойчивости к цензуре. Поскольку сортировщик уровня 2 может намеренно отклонить запрос на транзакцию от конкретного пользователя, необходимо использовать специальную схему, позволяющую пользователям инициировать транзакции, устойчивые цензуре. В ответ на эту проблему Chainway позволяет пользователям запускать «принудительные транзакции». После того, как пользователь отправляет эту декларацию транзакции в блоке BTC, сортировщик Chainway должен обработать этот запрос транзакции на уровне 2; В противном случае он не сможет нормально создать блок, или созданный блок не будет распознан клиентами вне сети. Структура параметров принудительной транзакции выглядит следующим образом:

Эта транзакция будет отправлена в блокчейн Биткойна как «Транзакция спецификации Chainway», с хэшем транзакции, заканчивающимся на 16 нулях. Сортировщик ChainWay при генерации блоков L2 должен включать «транзакции спецификации уровня 2», которые были раскрыты в блокчейне BTC, но еще не записаны в реестре L2, и агрегировать их в дерево Меркла, записывая его корень Меркла в заголовок блока L2. После того, как пользователь инициирует принудительную транзакцию непосредственно в блокчейне BTC, сортировщик должен ее обработать; В противном случае он не сможет сгенерировать следующий допустимый блок. Клиент Chainway вне цепочки BTC может сначала проверить доказательство ZK, чтобы определить действительность блока L2, отправленного сортировщиком, проверить корень Меркла заголовка блока L2 и оценить, действительно ли сортировщик включил принудительный запрос на транзакцию. Рабочий процесс можно сослаться на следующую блок-схему. Обратите внимание, что из-за ограниченного пространства на приведенной ниже схеме отсутствует суждение об условии в verify_relevant_tx_list:

Таким образом, клиент/узел Chainway синхронизируется с блоками основной сети BTC и сканирует из них «данные DA», опубликованные сортировщиком Chainway. Он проверяет, что эти данные публикуются назначенным сортировщиком и действительно содержат все «стандартные транзакции Chainway», отправленные в цепочку BTC. Очевидно, что до тех пор, пока пользователи могут создать транзакцию, отвечающую указанным критериям, как «стандартную транзакцию», и отправить ее в цепочку BTC, эта транзакция в конечном итоге будет включена в локальный реестр L2 клиента Chainway. В противном случае блок L2, выпущенный сортировщиком Chainway, будет отвергнут клиентом. В сочетании с надежной передачей сообщений о консенсусе/предупреждениях вне сети схема транзакций Chainway по борьбе с цензурой приближается к идеальному методу борьбы с цензурой суверенных роллапов. Например, в некоторых суверенных решениях Rollup прямо указано, что в случае недействительной блокировки предупреждающие сообщения будут транслироваться среди клиентов вне сети для повышения безопасности, особенно позволяя легким клиентам, которые не могут синхронизировать полные данные DA, знать об аномалиях сети. Если блок не включает в себя «обязательные транзакции», он, очевидно, вызовет рассылку оповещения вне сети. Однако Chainway пока не реализовал этот аспект (по крайней мере, опубликованные на данный момент материалы и репозитории кода показывают, что он не взялся за техническую реализацию этой части).

Справочный материал: Исследователи Celestia проанализировали 6 типов вариантов Rollup: Sequencer=Aggregator+Header Generator. Даже при консенсусе, достигнутом между клиентами/узлами вне сети, эффективность борьбы с цензурой «принудительных транзакций» Chainway не так надежна, как у роллапов смарт-контрактов, таких как Arbitrum, потому что Arbitrum One в конечном итоге обеспечит включение «принудительных транзакций» в реестр Layer2 через контракты на Layer1, полностью унаследовав антицензурные свойства Layer1. Суверенные роллапы явно не могут сравниться с роллапами смарт-контрактов в этом аспекте, поскольку их эффективность против цензуры в конечном итоге зависит от компонентов вне сети. Это также определяет, что подход «суверенных роллапов» и схем «верификации клиентов» принципиально не может полностью унаследовать антицензурные свойства Layer1, такие как Arbitrum One, Loopring, dydx и Degate, потому что то, могут ли принудительные транзакции быть плавно включены в реестр Layer2, зависит от решений оффчейн-сущностей Layer2, не связанных с самим Layer1. Очевидно, что подход Chainway, который полагается исключительно на усмотрение оффчейн-клиентов, наследует только надежность DA Layer1, а не его полные антицензурные свойства. Аналогично рекурсивным ZK-доказательствам MINA.

В этом разделе мы дополнительно представим другие компоненты Chainway, которые, помимо использования BTC в качестве уровня DA, также реализовали рекурсивные ZK-доказательства, аналогичные MINA. Его общая структура показана на следующей диаграмме:

Сортировщик в сети Chainway после обработки пользовательских транзакций генерирует окончательное доказательство ZK (Zero-Knowledge) вместе с подробностями об изменениях состояния (state diff) для разных аккаунтов и публикует их в блокчейне Bitcoin (BTC). Полные узлы будут синхронизировать все исторические данные Chainway, опубликованные в блокчейне BTC. Каждое доказательство ZK должно не только доказывать процесс перехода состояния текущего блока, но и обеспечивать валидность доказательства ZK предыдущего блока. Исходя из этой схемы, мы видим, что каждый раз, когда генерируется новое доказательство, оно по существу подтверждает предыдущее доказательство рекурсивным образом, а последнее доказательство ZK может гарантировать справедливость всех доказательств ZK, начиная с генезис-блока. Эта конструкция похожа на конструкцию MINA. Когда «легкий клиент», который синхронизирует только заголовки блоков, также известный как легкий узел, присоединяется к сети, ему нужно только проверить действительность последнего ZK Proof, раскрытого в блокчейне BTC, чтобы подтвердить, что исторические данные всей цепочки и все переходы между состояниями действительны. Если сортировщик действует злонамеренно, намеренно отказываясь принимать обязательные транзакции или не используя предыдущее доказательство ZK для рекурсивного доказательства, то вновь сгенерированное доказательство ZK не может быть принято клиентом (даже если оно сгенерировано, оно не распознается), как показано на диаграмме ниже:

Сводка

Как было подытожено в начале этой статьи, Chainway в основном является суверенной схемой Rollup/проверки клиента, которая использует BTC в качестве слоя доступности данных (DA). Чтобы усилить устойчивость к цензуре Rollup, Chainway вводит концепцию принудительных транзакций. С другой стороны, Chainway использует рекурсивную технологию ZK-доказательства, позволяя новым узлам доверять выводу последователя больше и проверять точность исторических данных всей цепочки в любое время. Текущая проблема с Chainway заключается в механизме доверия его мосту межцепочной связи. Поскольку он принимает суверенный подход Rollup, не детализируя, как он планирует решать технические аспекты в своем решении моста межцепочной связи, сложно оценить его окончательную безопасность.

Сегодня, изучая техническое решение Chainway, мы обнаружили, что тип технологии, продвигаемый сообществом проекта, не является полноценным Rollup в общепринятом смысле. Учитывая, что уже существует десятки проектов Bitcoin Layer2 (которые могут достичь сотен за полгода), чтобы снизить когнитивные издержки технической терминологии, мы продолжим проводить глубокие исследования по классификации решений Layer2 и стандартам безопасности, полноты функционала и оценки. Следите за обновлениями!

Отказ:

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