Бывший технический амбассадор Arbitrum объясняет структуру компонентов Arbitrum (Часть I)

Автор: Бенбен Луо, бывший технический амбассадор Arbitrum и гик-участник web3

**Эта статья является технической интерпретацией Arbitrum One Бенбеном Луо, бывшим техническим амбассадором Arbitrum и бывшим соучредителем Goplus Security, аудиторской компании по автоматизации смарт-контрактов. **

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

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

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

Оптимизация затрат: переложите большую часть задач по вычислениям и хранению данных на L1 off-chain, т. е. L2. **L2 — это в основном цепочка, работающая на одном сервере, т.е. секвенсоре/операторе.

Секвенсор выглядит близко к централизованному серверу, отказавшись от «Децентрализации» в «Blockchain Impossible Three Times» в обмен на TPS и ценовые преимущества. Пользователи могут позволить L2 обрабатывать транзакционные инструкции вместо Ethereum с гораздо меньшими затратами, чем торговля на Ethereum.

**Безопасность: Содержимое транзакции на L2 и состояние после транзакции будут синхронизированы с Ethereum L1, а валидность перехода состояния будет проверена через контракт. При этом история L2 будет сохранена в Ethereum, и даже если секвенсор навсегда не работает, другие могут восстановить все состояние L2 через записи в Ethereum.

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

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

Методы проверки состояния для предотвращения вредоносности секвенсора свертки делятся на два типа: защита от мошенничества и проверка валидности. Роллапы, использующие доказательства мошенничества, называются OP роллапами (оптимистичные накопители, OPR), и из-за некоторого исторического багажа роллапы с использованием доказательств действительности часто называются ZK Rollups (Zero-knowledge Proof Rollups, ZKR) вместо Validity Rollups.

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

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

В этой статье мы подробно представим Arbitrum One, ведущий проект в области оптимистичных роллапов, охватывающий все аспекты всей системы, и после внимательного прочтения у вас будет глубокое понимание Arbitrum и оптимистичного роллапа/OPR.

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

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

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

Секвенсор:

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

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

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

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

Протокол Arbitrum Rollup:

Серия контрактов, определяющих структуру блока RBlock в цепочке объединения, продолжение цепочки, выпуск RBlock и процесс в режиме вызова. Обратите внимание, что упомянутая здесь цепочка Rollup — это не реестр уровня 2, как мы его понимаем, а абстрактная «структура данных цепочки», созданная Arbitrum One для реализации механизма защиты от мошенничества.

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

Валидатор:

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

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

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

Вызов:

Основные шаги можно свести к многоступенчатой интерактивной сегментации и одношаговым доказательствам. В сеансе сегментации обеим сторонам предлагается выполнить несколько раундов пошагового разделения проблемных данных транзакции до тех пор, пока инструкция Operation Code для проблемного шага не будет разбита и проверена. Парадигма “многораундовая сегментация - одношаговое доказательство” рассматривается разработчиками 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 цепочки секвенсора, которая находится в состоянии Soft Finality и не является надежной. Но для пользователей, которые доверяют секвенсору (а их большинство), оптимистично то, что транзакция завершена и откат не будет.

4. Секвенсор инкапсулирует предварительно обработанные необработанные данные транзакции в пакет после сильного сжатия.

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

Контракт “Входящие” секвенсора

Контракт получит пакет транзакций, отправленных секвенсором для обеспечения доступности данных. Если заглянуть глубже, пакетные данные в SequencerInbox полностью записывают входную информацию о транзакциях уровня 2, даже если секвенсор постоянно не работает, любой может восстановить текущее состояние уровня 2 на основе пакетной записи, заменив неисправный секвенсор / секвенсор Rug pull.

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

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

Валидатор всегда будет прослушивать контракт SequencerInbox, и всякий раз, когда секвенсор выпускает пакет в контракт, он будет генерировать ончейн-событие, и после того, как валидатор услышит это событие, он загрузит пакетные данные, а после локального выполнения он выпустит RBlock в контракт протокола Rollup в цепочке ETH.

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

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

добавьте Sequencer L2Batch From Origin(), который секвенсор вызывает каждый раз для отправки пакетных данных в контракт Sequencer Inox.

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

Обе функции вызывают bridge.enqueueSequencerMessage() для обновления параметра аккумулятора accumulator в контракте моста.

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

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

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

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

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

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

Напомним, что L2 на самом деле является просто проекцией пакетного ввода транзакций, отправленных секвенсором в Fastbox, т.е.:

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

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

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

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

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

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

Таким образом, если мы создадим роллап без функции вывода, теоретически можно не синхронизировать состояние с L1, и нет необходимости в системе proof-of-state, такой как fraud proof (хотя это может вызвать другие проблемы). Но на практике это явно неосуществимо.

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

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

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

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

Протокол объединения

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

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

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

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

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

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

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

Кроме того, валидатор А предлагает Rollup Block 106, в то время как Б не соглашается, оспаривая его.

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

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

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

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

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

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

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

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

Таким образом, переходы между состояниями на L2 на самом деле являются общей особенностью ArbOS+Geth Core.

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

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

Основная причина заключается в том, что контракт, который проверяет одноэтапное доказательство мошенничества, использует EthereumSmart Contract для имитации виртуальной машины VM, которая может обрабатывать определенный набор наборов инструкций, а WASM легко реализовать в контракте.

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

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

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

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

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