Компонентная структура Arbitrum в интерпретации бывшего технического посла Arbitrum (часть 1)

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

Обзор секвенсора Rollup Sequencer

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

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

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

(Источник: BNB Chain)

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

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

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

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

Механизмы проверки состояния для предотвращения злонамеренных действий со стороны секвенсоров Rollup делятся на две категории: Доказательство мошенничества и Доказательство достоверности. Решения, использующие доказательство мошенничества, называются OP Rollup (Optimistic Rollup, OPR), а решения, использующие доказательство достоверности, часто называют ZK Rollup (Zero-knowledge Proof Rollup, ZKR), а не Validity 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 и т.д. Они будут подробно описаны в следующих разделах.

Секвенсор:

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

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

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

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

Протокол свертывания арбитров:

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

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

Валидатор:

Узлы-валидаторы Arbitrum на самом деле являются специальным подмножеством полных узлов Уровня 2, и в настоящее время они имеют доступ к белому списку.

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

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

Вызов:

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

Период вызова:

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

ArbOS, Geth, WAVM：.

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

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

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

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

1. Пользователи отправляют секвенсору торговые инструкции.

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

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

4. Секвенсор сильно сжимает предварительно обработанные исходные данные транзакции и заключает их в пакет (Batch).

5. Время от времени (на это влияют такие факторы, как объем данных и перегруженность ETH) секвенсор будет публиковать пакеты транзакций в контракте Sequencer Inbox на L1. На этом этапе можно считать, что сделка имеет жесткую завершенность.

Sequencer Inbox Contract

Контракт получит пакет транзакций, отправленный секвенсором, чтобы обеспечить доступность данных. Если посмотреть на это глубже, то пакетные данные в Sequencer Inbox полностью записывают входную информацию транзакции Layer2. Даже если секвенсор постоянно не работает, любой может восстановить текущее состояние Уровня 2 на основе записи партии и заменить неисправный/работающий секвенсор.

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

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

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

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

（Секвенсор постоянно отправляет партии в Sequencer Inbox）

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

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

Добавить секвенсор L2Batch из Origin()

Секвенсор будет вызывать эту функцию каждый раз, когда будет отправлять данные о партиях в контракт Sequencer Inox.

принудительное включение()

Эта функция может быть вызвана кем угодно и используется для реализации транзакций, устойчивых к цензуре. Как эта функция действует, будет подробно описано позже, когда мы будем говорить о контракте Delayed Inbox.

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

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

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

Расходы на публикацию данных, связанные с использованием ресурсов уровня 1

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

Стоимость, которую несут пользователи, занимающие ресурсы уровня 2

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

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

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

Вспоминая вышесказанное, L2 на самом деле является проекцией входной партии транзакций, представленной секвенсором в быстрой коробке, т.е:

Транзакционные входы -> STF -> Государственные выходы. Вход был определен, а STF не изменилась, поэтому результат на выходе также определен. Система доказательства обмана и протокол Arbitrum Rollup - это система, которая публикует корень состояния на выходе в виде RBlock (он же assertion) на L1 и выполняет оптимистическое доказательство на нем.

На L1 есть входные данные, публикуемые секвенсором, и состояние выхода, публикуемое верификатором. Давайте внимательно рассмотрим этот вопрос: Нужно ли публиковать статус уровня 2 в цепочке?

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

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

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

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

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

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

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

У ZKR нет такой проблемы, потому что ZK Proof лаконичен. Ему нужно проверить только очень маленькое доказательство, и нет необходимости выполнять множество транзакций, соответствующих этому доказательству. Поэтому ЗКР не работает оптимистично. Каждый раз, когда статус выпускается, появляется контракт Verifier для математической проверки.

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

Протокол сворачивания

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

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

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

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

Это показывает запись серии RBlocks (они же утверждения) в RollupProxy, представленных различными валидаторами, которые представляют собой квадратики на рисунке ниже: Зеленый - подтвержденные, синий - неподтвержденные, желтый - фальсифицированные.

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

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

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

Кроме того, верификатор A предложил блок сворачивания № 106, но B не согласился и оспорил его.

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

1. Сегментация - это процесс, в котором обе стороны взаимодействуют по очереди. Одна сторона сегментирует исторические данные, содержащиеся в определенном блоке Rollup Block, а другая сторона указывает, какая часть фрагмента данных является проблемной, - процесс, похожий на дихотомию (на самом деле 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/etc .).

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

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

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

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

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

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

Во второй части мы проанализируем Arbitrum и даже контрактный модуль, выполняющий функции межцепочечного обмена сообщениями/моста между Layer2 и Layer1, а также проясним, как настоящий Layer2 должен обеспечивать устойчивость к цензуре.

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

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