Эта статья представляет собой техническую интерпретацию Arbitrum One Луо Бенбена, бывшего технического представителя Arbitrum и бывшего сооснователя компании Goplus Security, занимающейся аудитом автоматизации смарт-контрактов.
Написано: Луо Бенбен, бывший технический представитель Arbitrum и компьютерный участник Web3
**Эта статья представляет собой техническую интерпретацию Arbitrum One Луо Бенбена, бывшего технического представителя Arbitrum и бывшего сооснователя компании Goplus Security, занимающейся аудитом автоматизации смарт-контрактов. **
Поскольку в статьях и материалах, касающихся Уровня 2, в китайских кругах отсутствует профессиональная интерпретация Arbitrum и даже OP Rollup, эта статья пытается заполнить пробел в этой области путем популяризации механизма работы Arbitrum. Поскольку структура самого Арбитрума слишком сложна, полный текст, несмотря на максимальное упрощение, все равно превышает 10 000 слов, поэтому он разделен на две части.Рекомендуется собрать и переслать в качестве справочного материала! **
Краткое описание сортировщика Rollup
Принцип расширения Rollup можно свести к двум пунктам:
**Оптимизация затрат. Перенесите большинство задач вычислений и хранения в цепочку L1, то есть L2. **L2 — это в основном цепочка, работающая на одном сервере, то есть секвенсоре/операторе.
Сортировщик выглядит и ощущается как централизованный сервер.В «невозможных трёх аспектах блокчейна» от «децентрализации» отказываются в обмен на TPS и ценовые преимущества. Пользователи могут позволить L2 обрабатывать инструкции по транзакциям вместо Ethereum, и стоимость будет намного ниже, чем торговля на Ethereum.
(Источник: Сеть BNB)
Гарантия безопасности: **Содержимое транзакции и статус после транзакции на уровне L2 будут синхронизированы с Ethereum L1, а достоверность перехода статуса будет проверена посредством контракта. **В то же время исторические записи L2 будут сохранены в Ethereum. Даже если секвенсор постоянно отключен, другие могут восстановить все состояние L2 через записи в Ethereum.
**По сути, безопасность Rollup основана на Ethereum. **Если секвенсор не знает закрытый ключ учетной записи, он не может инициировать транзакции от имени учетной записи или не может вмешиваться в баланс активов учетной записи (даже если он знает, это будет быстро обнаружено).
Несмотря на то, что сортировщик централизован как системный хаб**, в относительно зрелом решении объединения централизованный сортировщик может реализовывать только мягкое злонамеренное поведение, такое как просмотр транзакций или злонамеренное время простоя**, но в идеальном решении объединения существуют соответствующие средства. для сдерживания (например, механизмы, устойчивые к цензуре, такие как принудительное изъятие или сортировка доказательств).
(Протокол Loopring устанавливает функцию принудительного вывода средств в исходном коде контракта на уровне L1 для вызова пользователей)
Методы государственной проверки, позволяющие предотвратить злодеяния секвенатора Rollup, делятся на две категории: «Доказательство мошенничества» и «Доказательство достоверности». Схема объединения, использующая доказательство мошенничества, называется OP Rollup (Оптимистическое объединение, OPR), хотя из-за некоторого исторического багажа схема объединения, использующая доказательство достоверности, часто называется ZK Rollup** (Свертывание доказательства с нулевым разглашением, ZKR) вместо Validity Rollup. .
Arbitrum One — типичный OPR. Он разворачивает контракты на L1 и не осуществляет активную проверку предоставленных данных. Есть оптимизм, что с данными проблем нет. Если отправленные данные неверны, узел верификатора L2 активно инициирует запрос.
Таким образом, **OPR также подразумевает предположение о доверии: в любой момент времени существует хотя бы один честный узел-верификатор L2. **В контракте ZKR используются криптографические вычисления для активной, но экономичной проверки данных, отправленных секвенатором.
(Метод операции оптимистического объединения)
(Режим работы ZK Rollup)
В этой статье дается подробное представление об 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, чтобы гарантировать доступность данных и работу протокола Rollup. Вообще говоря, данные L2, отправленные на уровень 1, не могут быть отменены и могут быть окончательными.
Из вышеописанного процесса можно подвести итог: **Уровень 2 имеет собственную сеть узлов, но число этих узлов невелико, и, как правило, не существует протокола консенсуса, обычно используемого публичными цепочками, поэтому безопасность очень низкая и должна быть гарантирована. полагаясь на Ethereum.Надежность выпуска данных и эффективность переходов между состояниями. **
Протокол объединения арбитражных решений:
Ряд контрактов, определяющих структуру блока RBlock цепочки Rollup, метод продолжения цепочки, выпуск RBlock и процесс режима вызова. **Обратите внимание, что упомянутая здесь цепочка Rollup — это не реестр уровня 2, который всем понятен, а абстрактная «цепочечная структура данных», независимо созданная Arbitrum One для реализации механизма защиты от мошенничества. **
Один RBlock может содержать результаты нескольких блоков L2, причем данные также сильно различаются.Его объект данных RBlock хранится в серии контрактов в RollupCore. Если возникнет проблема с RBlock, Валидатор бросит вызов отправителю RBlock.
Валидатор:
Узлы-валидаторы Arbitrum на самом деле представляют собой специальное подмножество полных узлов уровня 2 и в настоящее время имеют доступ к белому списку.
Валидатор создает новый RBlock (блок Rollup, также называемый утверждением) на основе пакета транзакций, отправленных секвенсором в контракт SequencerInbox,** и отслеживает состояние текущей цепочки Rollup, а также оценивает транзакции, отправленные секвенсор.Вызов с неверными данными. **
Активному валидатору необходимо заранее заложить активы в цепочке ETH, иногда мы также называем его стейкером. Хотя узлы уровня 2, которые не выполняют залог, также могут отслеживать динамику работы Rollup и отправлять пользователям аномальные сигналы тревоги, они не могут напрямую вмешиваться в данные об ошибках, отправленные секвенсором в цепочке ETH.
испытание:
Основные шаги можно резюмировать как несколько раундов интерактивной сегментации и одношагового доказательства. В процессе сегментации стороны сначала проводят несколько раундов сегментации данных проблемной транзакции, пока не разложат инструкции кода проблемной операции и не проведут проверку. Разработчики Arbitrum считают парадигму «**Многораундное подразделение-одноэтапное доказательство» наиболее экономичной реализацией доказательства мошенничества. **Все аспекты находятся под контролем контракта, и ни одна сторона не может обмануть.
Период испытания:
Из-за оптимистичного характера OP Rollup после того, как каждый RBlock отправляется в цепочку, контракт не проверяется активно, оставляя период окна для фальсификации верификатора. **Этот временной интервал представляет собой период испытания, который составляет 1 неделю в основной сети Arbitrum One. После окончания периода вызова RBlock будет окончательно подтвержден, и соответствующие сообщения, передаваемые с L2 на L1 в блоке ** (например, операции вывода средств, выполняемые через официальный мост), могут быть освобождены.
АрбОС, Гет, 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 полностью записывают входную информацию транзакции Layer 2. **Даже если секвенсор постоянно не работает, любой может восстановить текущее состояние Layer2 на основе пакетной записи и заменить неисправный/работающий секвенсор. . **
Чтобы понять это физически, видимый нами L2 — это просто проекция пакета в SequencerInbox, а источником света является STF. Поскольку STF источника света не меняется легко, форма тени определяется только партией, выступающей в качестве объекта.
**Контракт Sequencer Inbox также называется быстрым ящиком. Секвенсор специально отправляет в него предварительно обработанные транзакции, и только секвенсор может отправлять в него данные. **Соответствующий быстрый ящик — это медленный ящик «Входящие» отсрочки, его функции будут описаны в последующем процессе.
Валидатор всегда будет отслеживать контракт SequencerInbox. **Каждый раз, когда секвенсор выпускает пакет в контракт, создается событие в цепочке. После того, как валидатор прослушивает возникновение этого события, он загружает данные пакета и выполняет его. Наконец, выполните RBlock для контракта протокола Rollup в цепочке ETH.
В мостовом контракте Arbitrum есть параметр, называемый аккумулятором, который записывает вновь отправленный пакет L2, а также количество и информацию о новых полученных транзакциях в медленном почтовом ящике «Входящие».
(Секвенатор постоянно отправляет пакеты в SequencerInbox)
*
(Информация о пакете, поле данных соответствует данным пакета, эта часть данных очень большая, скриншот отображается не полностью)
Контракт SequencerInbox имеет две основные функции:
добавить Sequencer L2Batch From Origin(), секвенсор будет вызывать эту функцию каждый раз для отправки данных Batch в контракт Sequencer Inox.
force Inclusion(), Эту функцию может вызывать кто угодно, и она используется для реализации транзакций, устойчивых к цензуре. То, как эта функция действует, будет подробно объяснено позже, когда мы будем говорить о контракте «Отложенные входящие».
Две вышеупомянутые функции вызовут Bridge.enqueueSequencerMessage() для обновления аккумулятора параметра аккумулятора в контракте моста.
Цены на газ
Очевидно, что транзакции L2 не могут быть бесплатными, поскольку это приведет к DoS-атакам, кроме того, возникают затраты на эксплуатацию самого сортировщика L2, а также возникнут накладные расходы на отправку данных на L1. Когда пользователи инициируют транзакции внутри сети уровня 2, структура комиссии за газ выглядит следующим образом:
Затраты на публикацию данных, связанные с использованием ресурсов уровня 1, в основном берутся из пакета, отправленного сортировщиком (каждый пакет содержит множество пользовательских транзакций), и в конечном итоге затраты поровну распределяются между инициаторами транзакций. Алгоритм ценообразования, генерируемый при выпуске данных, является динамическим, и сортировщик будет оценивать цену на основе недавнего статуса прибылей и убытков, размера партии и текущей цены на газ Ethereum.
Затраты, понесенные пользователями из-за занятия ресурсов уровня 2, устанавливают лимит газа, который может обрабатываться в секунду для обеспечения стабильной работы системы (в настоящее время Arbitrum One составляет 7 миллионов). Ориентировочные цены на газ L1 и L2 отслеживаются и корректируются ArbOS, и формулы здесь пока описываться не будут.
Хотя процесс расчета конкретной цены на газ относительно сложен, пользователям не нужно знать эти детали, и они могут ясно почувствовать, что комиссии за транзакции Rollup намного дешевле, чем в основной сети ETH.
Оптимистическое доказательство мошенничества
Вспоминая вышесказанное, L2 на самом деле представляет собой просто проекцию входного пакета транзакции, отправленного сортировщиком в быстрый блок, то есть:
Входные данные транзакции -> STF -> Выходные данные состояния. Входные данные определены, а STF не изменен, поэтому выходной результат также определен.**Система защиты от мошенничества и протокол Arbitrum Rollup публикуют корень выходного состояния в L1 в форме RBlock (также известного как утверждение). система оптимистических доказательств. **
На L1 имеются входные данные, публикуемые секвенсором, и выходной статус, публикуемый верификатором. Давайте внимательно рассмотрим, нужно ли публиковать в цепочке статус Layer 2?
Поскольку вход уже полностью определяет выход, а входные данные общедоступны, то отправка выходного результата — состояния кажется избыточной? Но эта идея игнорирует фактическую необходимость урегулирования состояния между двумя системами L1-L2, то есть поведение вывода L2 в L1 требует доказательства состояния.
При создании Rollup одна из основных идей состоит в том, чтобы перенести большую часть вычислений и хранилища на L2, чтобы избежать высокой стоимости L1. Это означает, что L1 не знает состояния L2, он только помогает L2. Секвенсор публикует входные данные. всех транзакций, но не отвечает за расчет состояния L2.
**Поведение вывода средств, по сути, заключается в том, чтобы следовать межсетевому сообщению, предоставленному L2, разблокировать соответствующие средства из контракта L1, перевести их на учетную запись пользователя L1 или выполнить другие действия. **
В это время в контракте Layer1 будет задан вопрос: **Каков ваш статус на Layer2 и как доказать, что вы действительно владеете активами, о передаче которых вы заявляете. В это время пользователь должен предоставить соответствующее доказательство Меркла и т. д. **
Следовательно, если мы построим накопительный пакет без функции вывода средств, теоретически можно не синхронизировать состояние с L1, и нет необходимости в системе проверки состояния, такой как доказательство мошенничества (хотя это может вызвать другие проблемы). Но в реальных приложениях это явно неосуществимо.
В так называемом оптимистическом доказательстве контракт не проверяет правильность статуса вывода, отправленного на L1, и оптимистично полагает, что все верно. **Система оптимистичного подтверждения предполагает, что в любой момент времени существует хотя бы один честный валидатор. Если возникает неправильное состояние, оно будет оспорено с помощью доказательства мошенничества. **
Преимущество этой конструкции заключается в том, что нет необходимости активно проверять каждую блокировку RBlock, выданную L1, чтобы избежать потери газа. На самом деле для OPR нереально проверить каждое утверждение, поскольку каждый Rblock содержит один или несколько блоков L2, и каждую транзакцию необходимо повторно выполнить на L1. Это ничем не отличается от выполнения транзакций L2 непосредственно на L1, что проигрывает смысл расширения уровня 2.
ZKR не имеет этой проблемы, поскольку ZK Proof прост и требует проверки только очень небольшого доказательства. Нет необходимости фактически выполнять множество транзакций, соответствующих доказательству. Поэтому ZKR работает не оптимистично: каждый раз, когда статус будет выпущен, будет контракт Verfier на математическую проверку.
**Хотя доказательство мошенничества не может быть таким кратким, как доказательство с нулевым разглашением, Arbitrum использует пошаговый интерактивный процесс «многоэтапное доказательство в один шаг». В конце концов, необходимо доказать только одну виртуальную машину. код операции, стоимость относительно невелика. **
Протокол объединения
Давайте сначала посмотрим, как работает протокол Rollup, который является отправной точкой для инициирования проблем и инициирования доказательств.
**Основным контрактом протокола Rollup является RollupProxy.sol. **При условии обеспечения согласованной структуры данных используется редкая структура с двумя агентами.Один агент соответствует двум реализациям RollupUserLogic.sol и RollupAdminLogic.sol.В инструментах такие как Scan It, пока не могут быть хорошо проанализированы.
Существует также контракт **ChallengeManager.sol, отвечающий за управление проблемами, и серия контрактов OneStepProver для определения доказательств мошенничества. **
(Источник фото: официальный сайт L2BEAT)
В RollupProxy записывается серия RBlocks (так называемых утверждений), отправленных разными Валидаторами, которые обозначены квадратами на рисунке ниже: зеленый — подтверждено, синее — неподтверждено, желтое — фальсифицировано.
**RBlock содержит конечное состояние после выполнения одного или нескольких блоков L2 с момента последнего RBlock. **Эти RBlocks образуют формальную цепочку объединения (обратите внимание, что сам реестр L2 отличается). При оптимистических обстоятельствах эта цепочка объединения не должна иметь разветвлений, поскольку разветвление означает, что валидатор отправил конфликтующие блоки объединения.
Чтобы предложить утверждение или согласиться с ним, верификатору необходимо сначала поставить определенную сумму ETH на это утверждение и стать стейкером. Таким образом, когда происходит оспаривание/доказательство мошенничества, залог проигравшего будет конфискован.Это экономическая основа для обеспечения честного поведения проверяющего.
Синий блок № 111 в правом нижнем углу рисунка в конечном итоге будет подделан, поскольку его родительский блок № 104 неправильный (желтый).
**Кроме того, верификатор А предложил агрегированный блок № 106, но Б не согласился и оспорил его. **
После того, как B инициирует испытание, контракт ChallengeManager отвечает за проверку разбивки этапов испытания:
-
Сегментация — это процесс, в котором обе стороны по очереди взаимодействуют: одна сторона сегментирует исторические данные, содержащиеся в определенном Rollup Block, а другая сторона указывает, какая часть фрагмента данных является проблемной. Процесс, похожий на дихотомию (на самом деле N/K), который постоянно и постепенно сужает область применения.
-
После этого вы можете продолжить поиск проблемной транзакции и результата, а затем дополнительно разделить ее на спорную машинную инструкцию в транзакции.
-
Контракт ChallengeManager проверяет только корректность «фрагментов данных», сгенерированных после сегментации исходных данных.
-
После того, как претендент и вызываемый объект обнаружили машинную инструкцию, которую нужно оспорить, претендент вызывает функцию oneStepProveution() и отправляет одноэтапное доказательство мошенничества, чтобы доказать, что существует проблема с результатом выполнения этой машинной инструкции. **
Одноэтапное доказательство
Одноэтапное доказательство является основой доказательства мошенничества 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 для моделирования виртуальной машины виртуальной машины, которая может обрабатывать определенный набор наборов инструкций, а WASM легко реализовать симуляцию. по контракту.
Однако WASM работает немного медленнее, чем собственный машинный код, поэтому узлы/контракты Arbitrum будут использовать WAVM только при создании и проверке доказательств мошенничества.
**После предыдущих раундов интерактивного разделения одношаговое доказательство наконец подтверждает одношаговую инструкцию в наборе команд WAVM. **
Как видно из приведенного ниже кода, OneStepProofEntry должен сначала определить, к какой категории принадлежит код операции проверяемой инструкции, а затем вызвать соответствующий проверяющий модуль, например Mem, Math и т. д., чтобы передать одношаговую инструкцию в контракт на доказывание.
Окончательный результат afterHash будет возвращен в ChallengeManager.Если хэш не соответствует хешу после операции инструкции, записанной в блоке Rollup, вызов считается успешным. Если они согласованы, это означает, что нет проблем с результатом выполнения этой команды, записанным в блоке объединения, и вызов не выполнен.
В следующей статье мы проанализируем Arbitrum и даже модуль контракта, который обрабатывает межсетевые сообщения/функции моста между Layer2 и Layer1, а также выясним, как настоящий Layer2 должен обеспечивать устойчивость к цензуре.
