Переслать оригинальный заголовок:

В этой статье предоставлена техническая интерпретация Arbitrum One от Луо Бенбен (罗奔奔), бывшего технического посланника Arbitrum и бывшего соучредителя компании по аудиту автоматизации смарт-контрактов Goplus Security.

Из-за отсутствия профессиональной интерпретации Arbitrum и даже OP Rollup в китайских статьях или материалах, связанных с Layer 2, настоящая статья пытается заполнить этот пробел, популяризируя рабочий механизм Arbitrum. Поскольку структура самого Arbitrum слишком сложна, хотя полный текст был упрощен настолько, насколько это возможно, он все равно превышает 10 000 слов, поэтому он разделен на две части. Рекомендуется собрать и переслать его в качестве справки!

Краткое введение в секвенсор Rollup

Принцип расширения Rollup можно свести к двум точкам:

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

Секвенсор в некотором смысле близок к централизованному серверу. В «невозможном треугольнике блокчейна» отказываются от «децентрализации» в обмен на TPS и преимущества по стоимости. Пользователи могут позволить L2 обрабатывать инструкции по транзакциям вместо Ethereum, и стоимость будет намного ниже, чем при торговле на Ethereum.

(Источник: Цепочка BNB)

Гарантия безопасности: Содержимое транзакции и полученное состояние на уровне 2 синхронизируются с уровнем 1 Ethereum, где их допустимость проверяется через контракты. Тем временем Ethereum сохраняет исторические записи L2, так что даже если последователь окончательно выйдет из строя, другие могут восстановить полное состояние L2 из записей на Ethereum.

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

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

(Протокол Loopring устанавливает функцию принудительного вывода в исходном коде контракта на уровне L1 для вызова пользователей)

Для предотвращения злонамеренного поведения последователей Rollup существуют два типа методов проверки состояния: Доказательство обмана и Доказательство действительности. Решения Rollup, использующие Доказательство обмана, называются Оптимистичным Rollup (OPR), в то время как те, которые используют Доказательство действительности, часто называются ZK Rollup (Rollup с нулевым доказательством, ZKR), а не Доказательство Rollup, вследствие исторического багажа.

Arbitrum One - это типичный OPR, развернутый на контрактах L1, которые не активно проверяют представленные данные, но оптимистично предполагают, что данные верны. Если в представленных данных есть ошибки, валидаторы L2 инициируют вызовы.

Следовательно, OPR также подразумевает доверительное предположение: в любой момент времени есть как минимум один честный узел валидатора L2. С другой стороны, ZKR контракты проактивно и экономично проверяют данные, предоставленные последователем, с помощью криптографических вычислений.

(Метод работы оптимистичного Rollup)

(Метод операции ZK Rollup)

Эта статья предоставит подробное введение в ведущий проект в Optimistic Rollup — Arbitrum One, охватывая все аспекты системы. После тщательного прочтения вы приобретете глубокое понимание Arbitrum и Optimistic Rollup (OPR).

Основные компоненты и рабочий процесс Arbitrum:

Основные контракты:

Самые важные контракты в Arbitrum включают SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge и т. д. Об этом будет рассказано позже.

Последователь:

Получает транзакции пользователей и упорядочивает их, вычисляет результаты транзакций и быстро (обычно <1с) возвращает квитанции пользователям. Пользователи обычно могут видеть подтверждение своих транзакций на уровне L2 в течение нескольких секунд, обеспечивая опыт, подобный Web2.

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

Каждые несколько минут секвенсор сжимает упорядоченные данные транзакций L2, агрегирует их в пакеты и отправляет их в контракт SequencerInbox на Уровне 1, чтобы гарантировать доступность данных и работу протокола Rollup. Обычно данные L2, отправленные на Уровень 1, не могут быть откачены и могут иметь окончательность.

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

Протокол Arbitrum Rollup:

Определяет структуру блоков, называемых RBlocks, на цепи Rollup, продолжение цепи, публикацию RBlocks, процесс вызова и т. д., через серию контрактов. Важно отметить, что упомянутая здесь цепь Rollup не является книгой учета, обычно понимаемой как Уровень 2, а скорее абстрактная «подобная цепи структура данных», созданная независимо Arbitrum One для реализации механизмов доказательства мошенничества.

RBlock может содержать результаты нескольких блоков L2, и его данные, RBlock, хранятся в серии контрактов в RollupCore. Если возникнут проблемы с RBlock, валидаторы будут оспаривать его на основе представлений от создателя RBlock.

Валидаторы:

Валидаторы в Arbitrum фактически являются особым подмножеством полных узлов уровня 2, в настоящее время с допуском в белый список.

Валидаторы создают новые RBlocks (Rollup blocks, также называемые утверждениями) на основе пакетов транзакций, отправленных в контракт SequencerInbox секвенсором, и отслеживают текущее состояние цепочки Rollup, чтобы оспаривать неверные данные, отправленные секвенсором.

Активные валидаторы должны заранее ставить активы на цепи Ethereum и иногда называются стейкерами. Хотя узлы уровня 2, которые не ставят активы, могут отслеживать работу Rollup и отправлять предупреждения пользователям об аномалиях, они не могут напрямую вмешиваться в неправильные данные, представленные сиквенсором на цепи Ethereum.

Challenge:

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

Период испытаний:

Из-за оптимистичной природы OP Rollup после каждого RBlock, отправленного в цепь, контракт не активно проверяет его, оставляя период времени для валидаторов фальсифицировать его. Это временное окно - период вызова, который составляет одну неделю на основной сети Arbitrum One. После окончания периода вызова RBlock будет окончательно подтвержден, и сообщения, соответствующие транзакциям с L2 на L1 (например, операции вывода, выполненные через официальный мост), могут быть опубликованы.

ArbOS, Geth, WAVM:

Arbitrum использует виртуальную машину под названием AVM, которая состоит из Geth и ArbOS. Geth является наиболее часто используемым клиентским программным обеспечением для Ethereum, и Arbitrum внес в него облегченные изменения. ArbOS отвечает за все специальные функции, связанные с L2, такие как управление сетевыми ресурсами, генерация L2-блоков и работа в координации с EVM. Мы рассматриваем комбинацию того и другого как нативную AVM, которая является виртуальной машиной, используемой Arbitrum. WAVM является результатом компиляции кода AVM в Wasm. В процессе оспаривания Arbitrum окончательное «одношаговое доказательство» проверяет инструкции WAVM.

Здесь мы можем представить отношения и рабочие процессы между различными компонентами, используя приведенную ниже диаграмму:

Жизненный цикл транзакции L2

Поток обработки транзакции L2 выглядит следующим образом:

1. Пользователь отправляет инструкции по транзакции секвенсору.
2. Первым делом секвенсор проверяет данные, включая цифровые подписи, транзакций на обработку, фильтрует недопустимые транзакции, а затем упорядочивает и обрабатывает их.
3. Последователь отправляет пользователю квитанцию о транзакции (обычно очень быстро), но это только «предварительная обработка», сделанная последователем на цепочке Ethereum, и она находится в состоянии мягкой окончательности и не надежна. Однако для пользователей, доверяющих последователю (большинство пользователей), они могут оптимистично предположить, что транзакция завершена и не будет отменена.
4. Секвенсор инкапсулирует предварительно обработанные данные транзакции в Пакет после их высококачественного сжатия.
5. На регулярных интервалах (подверженных факторам, таким как объем данных и захламление Ethereum), последователь публикует пакет транзакций в контракт Sequencer Inbox на уровне L1. На этом этапе можно считать, что транзакция имеет жесткую финальность.

Контракт Sequencer Inbox

Смарт-контракт получает пакеты транзакций, представленных секвенсером, чтобы обеспечить доступность данных. Подробно, данные пакета во входящих данных секвенсера полностью записывают информацию о вводе транзакций Layer2. Даже если секвенсер окончательно выйдет из строя, любой может восстановить текущее состояние Layer2 на основе записей пакета и взять под контроль отказавший/пропавший секвенсер.

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

Контракт Sequencer Inbox также называется быстрым ящиком, и конкретный секвенсор представляет предварительно обработанные транзакции, и только секвенсор может отправлять данные в него. Соответствующим медленным ящиком является Delayer Inbox, функция которого будет описана в последующем процессе.

Валидаторы будут непрерывно отслеживать контракт Sequencer Inbox. Каждый раз, когда последователь публикует пакет в этот контракт, на цепи запускается событие. Обнаружив это событие, валидатор загрузит данные пакета, выполнит их локально, а затем опубликует RBlock в контракт протокола Rollup на цепи Ethereum.

Контракт моста Arbitrum имеет параметр, называемый аккумулятором, который записывает информацию о только что отправленной пакетной L2 и количестве полученных транзакций на медленном почтовом ящике, среди прочего.

(Последователь постоянно отправляет пакеты в SequencerInbox)

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

Контракт SequencerInbox имеет две основные функции:

Добавить Sequencer L2Batch From Origin()，Секвенсор будет вызывать эту функцию каждый раз для передачи пакетных данных в контракт Sequencer Inox.

force Inclusion()，Эта функция может быть вызвана любым и используется для реализации транзакций, устойчивых к цензуре. Способ действия этой функции будет подробно объяснен позже, когда мы будем говорить о контракте Delayed Inbox.

Вышеперечисленные две функции вызовут “bridge.enqueueSequencerMessage()”, чтобы обновить параметр аккумулятора в контракте моста.

Ценообразование на газ

Очевидно, транзакции L2 не могут быть бесплатными, потому что это приведет к атакам DoS. Кроме того, существуют операционные расходы для самого секвенсора L2, и будет накладываться дополнительная нагрузка при отправке данных на L1. Когда пользователь инициирует транзакцию в сети Layer 2, структура комиссии за газ следующая:

Стоимость публикации данных, генерируемая захватом ресурсов Layer1, в основном происходит от пакетов, отправляемых сиквенсором (каждый пакет содержит транзакции многих пользователей), и в конечном итоге распределяется между инициаторами транзакций. Алгоритм ценообразования для комиссий за транзакции, генерируемых публикацией данных, является динамическим. Сиквенсор корректирует ценообразование на основе недавних условий прибыли и убытков, размера пакета и текущей цены газа Ethereum.

Затраты, понесенные пользователями за занятие ресурсами Layer2, определяются установкой максимального лимита газа, обрабатываемого в секунду, чтобы обеспечить стабильную работу системы (в настоящее время Arbitrum One составляет 7 миллионов). Цены на направление газа как для L1, так и для L2 отслеживаются и корректируются ArbOS, и здесь формула не разъясняется.

Хотя процесс расчета конкретной цены газа относительно сложен, пользователям не нужно знать об этих деталях, и им ясно чувствовать, что комиссии за транзакции Rollup намного дешевле, чем на основной сети ETH.

Оптимистическое доказательство мошенничества

Взглянув на предыдущий текст, становится очевидным, что Layer2 (L2) по сути является всего лишь проекцией пакетов входных транзакций, отправленных упорядочивателем во Входящий ящик упорядочивателя:

Входные данные транзакции -> Функция перехода состояния (STF) -> Выходные данные состояния

Входные данные уже определены, а STF неизменен, поэтому результат также определен. Доказательство мошенничества и система протокола Arbitrum Rollup публикуют состояние вывода, представленное RBlock (также известное как утверждение), на Layer1 и предоставляют оптимистические доказательства для этого.

На уровне L1 есть как входные данные, опубликованные последователем, так и выходные состояния, опубликованные валидаторами. При тщательном рассмотрении возникает вопрос: необходимо ли публиковать состояние Layer2 на цепи? Поскольку входные данные уже полностью определили выходные данные, а входные данные общедоступны, представление результатов вывода или состояния кажется избыточным. Однако это представление не учитывает того факта, что необходимо проведение расчетов состояний между системами L1 и L2. Это особенно важно для действий по выводу с L2 на L1, требующих доказательства состояния.

При построении Rollup основная идея заключается в том, чтобы перенести большую часть вычислений и хранения на уровень L2, чтобы избежать высоких затрат на уровне L1. Это означает, что L1 не знает состояния L2; он только помогает последователю L2 опубликовать входные данные для всех транзакций, но не несет ответственности за вычисление состояния L2.

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

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

Следовательно, если мы создадим Rollup без функции вывода, теоретически возможно не синхронизировать состояние с L1, и нет необходимости в системе доказательства состояния, такой как доказательство мошенничества (хотя это может вызвать другие проблемы). Но в реальных приложениях это, очевидно, невозможно.

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

Преимущество этого дизайна заключается в том, что нет необходимости активно проверять каждый RBlock, выпущенный на L1, чтобы избежать излишнего расхода газа. Фактически, для OPR нереально проверять каждое утверждение, потому что каждый RBlock содержит один или несколько L2 блоков, и каждая транзакция должна быть повторно выполнена на L1. Это ничем не отличается от выполнения транзакций L2 непосредственно на L1, что лишает смысла масштабируемость Уровня 2.

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

Хотя доказательства мошенничества не могут достичь такого высокого уровня краткости, как доказательства нулевого знания, Arbitrum использует интерактивный процесс "многократного подразделения - одношаговое доказательство", в результате которого в конечном итоге требуется доказать только один виртуальный оператор машины, что приводит к относительно более низким затратам.

протокол Rollup

Давайте сначала посмотрим на вход, чтобы начать вызовы и запустить подтверждения, то есть, как работает протокол Rollup.

Основной контракт протокола Rollup - RollupProxy.sol. Обеспечивается согласованная структура данных, используется редкая двойная структура агента. Один агент соответствует двум реализациям RollupUserLogic.sol и RollupAdminLogic.sol, которые не могут быть хорошо разобраны инструментами, такими как Scan.

Кроме того, контракт ChallengeManager.sol отвечает за управление вызовами, а серия контрактов OneStepProver используется для определения доказательств мошенничества.

(Источник: официальный сайт L2BEAT)

В RollupProxy регистрируется серия RBlocks (также известных как утверждения), представленных различными валидаторами, изображенных блоками на диаграмме: зеленый для подтвержденных, синий для неподтвержденных и желтый для опровергнутых.

RBlock содержит окончательное состояние, полученное в результате выполнения одного или нескольких блоков L2 с момента предыдущего RBlock. Эти RBlocks формируют цепочку Rollup по виду (обратите внимание на отличие от самого учетного реестра L2). В оптимистичном сценарии эта цепочка Rollup не должна иметь вилок, поскольку ветвление подразумевает, что валидаторы представляют конфликтующие блоки Rollup.

Для того чтобы предложить или согласиться с утверждением, валидаторы должны поставить определенное количество ETH, став Стейкером. Это обеспечивает экономическую основу для честного поведения среди валидаторов, поскольку ставка проигравшего будет утрачена в случае оспаривания/доказательства мошенничества.

Синий блок с номером 111 в правом нижнем углу диаграммы в конечном итоге будет опровергнут, потому что его родительский блок, блок номер 104, неверен (желтый).

Кроме того, Валидатор A предложил Rollup Block 106, с чем не согласен и оспаривает Валидатор B.

После того, как B инициирует вызов, контракт ChallengeManager отвечает за проверку сегментации шагов вызова:

1. Сегментация - это процесс, в ходе которого обе стороны поочередно взаимодействуют. Одна сторона сегментирует исторические данные, содержащиеся в определенном блоке Rollup, а другая сторона указывает на ту часть фрагмента данных, которая вызывает проблемы. Процесс, аналогичный дихотомии (фактически N/K), который постоянно и постепенно сужает область.

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

3. Контракт ChallengeManager проверяет только, является ли "сегмент данных", сгенерированный после разделения исходных данных, действительным.

4. Когда вызывающая сторона и вызываемая сторона определяют машинную инструкцию, которую следует оспорить, вызывающая сторона вызывает oneStepProveExecution(), чтобы отправить доказательство мошенничества на один шаг, демонстрируя, что результат выполнения этой машинной инструкции недостоверен.

Одношаговое доказательство

Одношаговое доказательство является основой всего мошеннического доказательства Arbitrum. Давайте посмотрим, что конкретно доказывает одношаговое доказательство.

Для начала необходимо понять WAVM. Wasm Arbitrum Virtual Machine - это виртуальная машина, скомпилированная модулем ArbOS и ядром Geth (клиент Ethereum). Поскольку L2 очень отличается от L1, оригинальное ядро Geth пришлось слегка модифицировать и совместно использовать с ArbOS.

Следовательно, переход состояния на L2 фактически представляет собой совместную работу ArbOS + Geth Core.

Клиентский узел Arbitrum (последователь, валидатор, полный узел и т. д.) компилирует упомянутую выше программу обработки ArbOS+Geth Core в машинный код, который узел-хост может обрабатывать непосредственно (для x86/ARM/PC/Mac и т. д.).

Если вы измените целевой язык, полученный после компиляции, на Wasm, вы получите WAVM, используемый верификатором при генерации доказательств мошенничества, а контракт для проверки одношагового доказательства также имитирует функции виртуальной машины WAVM.

Почему при генерации доказательств мошенничества его нужно компилировать в байт-код Wasm? Главная причина заключается в том, что для проверки контракта одношагового доказательства мошенничества необходимо использовать смарт-контракт Ethereum для моделирования виртуальной машины VM, способной обрабатывать определенный набор инструкций, а WASM легко реализовать симуляцию на контракте.

Однако WASM работает немного медленнее, чем нативный машинный код, поэтому узлы/контракты Arbitrum будут использовать WAVM только при генерации и проверке доказательств мошенничества.

После предыдущих раундов интерактивных подразделений одношаговое доказательство наконец доказало одношаговую инструкцию в наборе инструкций WAVM.

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

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

Disclaimer：

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