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

Как Arbitrum обрабатывает межсетевой обмен сообщениями и транзакции, устойчивые к цензуре? Какова модель перекрестного моста?

Написано: Луо Бенбен, бывший технический представитель Arbitrum и компьютерный участник Web3

В предыдущей статье* «Бывший технический посол Arbitrum интерпретирует структуру компонентов Arbitrum (часть 1)»** мы представили секвенатор, валидатор, контракт Sequencer Inbox, Rollup Block и неинтерактивное доказательство мошенничества в основных компонентах Arbitrum. В сегодняшней статье мы сосредоточимся на компонентах, связанных с межсетевым обменом сообщениями и устойчивыми к цензуре входами транзакций, среди основных компонентов Arbitrum. *

В предыдущей статье мы упоминали, что контракт Sequencer Inbox специально получает пакет данных транзакции, опубликованный секвенсором на уровне Layer1. В то же время мы отмечаем, что Входящие секвенсора также называются быстрым ящиком, в отличие от медленного ящика «Отложенные входящие» (называемого «Входящие»). Ниже мы предоставим подробное объяснение компонентов, связанных с межсетевым обменом сообщениями, таких как Delayed Inbox.

Принципы кроссчейн и мостов

Межсетевые транзакции можно разделить на L1-L2 (пополнение) и L2-L1 (вывод средств). Обратите внимание, что упомянутые здесь пополнения и снятия средств не обязательно связаны с межсетевыми активами, но могут представлять собой сообщения, которые напрямую не включают активы. Таким образом, эти два слова представляют только два направления поведения, связанного с перекрестными цепочками.

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

Кроме того, то, что мы обычно называем кросс-чейн-поведением, — это кросс-чейн в двух несвязанных сетях с использованием кросс-чейн-моста в режиме свидетеля. Безопасность этого кросс-чейна зависит от кросс-чейна. Операторы, кража кросс-чейна. Цепные мосты, основанные на модели свидетеля, часто встречались в истории.

Поведение кросс-чейна между Rollup и основной сетью ETH существенно отличается от вышеупомянутого кросс-чейна, поскольку состояние Layer2 определяется данными, записанными на Layer1**, если вы используете официальный Rollup. Поперечно-цепной мост абсолютно безопасен по своей эксплуатационной конструкции. **

Это также подчеркивает суть Rollup. Он только выглядит как независимая цепочка с точки зрения пользователя, но на самом деле так называемый «**Layer2» — это просто окно быстрого отображения, открываемое Rollup для пользователей. Его реальный тип цепочки Структура все еще сжигается на Layer1. **Итак, мы можем рассматривать L2 как половину цепочки или «цепочку, созданную на уровне Layer1».

Повторные билетыRetryables

Следует отметить, что кросс-чейны асинхронны и неатомарны: невозможно узнать результат после подтверждения транзакции, как в одной цепочке, и нельзя гарантировать, что что-то произойдет на другой стороне в определенный момент времени. . Таким образом, кросс-чейн может потерпеть неудачу из-за некоторых «мягких» проблем, но пока используются правильные средства, такие как Повторный билет, серьезных проблем, таких как заторы средств, не возникнет.

Повторные билеты являются основными инструментами, используемыми при внесении депозита через официальный мост Arbitrum. Будут использоваться депозиты как в ETH, так и в формате ERC20. Его жизненный цикл делится на три этапа:

**1. Отправьте билет на L1. **Используйте метод createRetryableTicket() в контракте Delayed Inbox, чтобы создать билет пополнения счета и отправить его.

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

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

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

Кроме того, хотя процесс вывода официального бриджа Arbitrum имеет определенное симметричное сходство с поведением пополнения счета, в нем отсутствует понятие Retryables. С одной стороны, это можно понять из самого протокола Rollup, а с другой стороны, мы можем понять это по некоторым различиям:

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

Межсетевой шлюз активов ERC-20

Межсетевые активы ERC-20 сложны. Мы можем подумать над несколькими вопросами:

• Токен развернут на L1, как его развернуть на L2?
• Необходимо ли заранее вручную развертывать соответствующий контракт L2 или система может автоматически развертывать контракты активов для токенов, которые перешли, но еще не развернули контракт?
• Для активов ERC-20 на уровне L1, каков соответствующий адрес контракта на уровне L2? Должно ли оно соответствовать L1?
• Как перенести токены, изначально выпущенные на L2, в L1?
• Как токены со специальными функциями, такие как токены перебазирования с регулируемым количеством и саморастущие токены, приносящие проценты, могут быть объединены в перекрестную цепочку?

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

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

**Arbitrum использует систему Gateway для решения большинства проблем кросс-чейна ERC20. **Она имеет следующие функции:

• Компоненты шлюза появляются парами на уровнях L1 и L2.
• **Маршрутизатор шлюза отвечает за поддержание сопоставления адресов между токеном L1<->токеном L2, ** и сопоставлением между некоторым токеном<->некоторым шлюзом.
• Сам шлюз можно разделить на стандартный шлюз ERC20, универсальный-пользовательский шлюз, индивидуальный шлюз и т. д. для решения различных типов и функций мостовых проблем ERC20.

Давайте возьмем относительно простой кросс-чейн WETH в качестве примера, чтобы проиллюстрировать необходимость настройки шлюза.

WETH — это эквивалент ETH по стандарту ERC20. В качестве основной валюты Ether не может реализовывать сложные функции во многих dApps, поэтому необходим эквивалент ERC20. Переведите немного ETH в контракт WETH, они будут заблокированы в контракте, и будет сгенерировано такое же количество WETH.

Таким же образом можно уничтожить WETH и вывести ETH. Очевидно, что количество находящихся в обращении WETH и заблокированных ETH всегда составляет 1:1. **

Если мы теперь свяжем WETH напрямую с L2, мы обнаружим некоторые странные проблемы:

• Развернуть WETH в ETH на L2 невозможно, поскольку на L2 нет соответствующего ETH для блокировки.
• Можно использовать функцию Wrap, но если эти вновь сгенерированные WETH будут возвращены в L1, их нельзя будет декапсулировать в ETH на L1, поскольку контракты WETH на L1 и L2 не являются «симметричными»**.

Очевидно, это нарушает принципы проектирования WETH. **Затем, когда WETH является перекрестным, будь то пополнение или снятие средств, его необходимо сначала развернуть в ETH, затем пересечь на другую сторону, а затем обернуть в WETH. **Это роль шлюза WETH.

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

Отложенные входящие

Соответствует быстрому ящику, также известному как SequencerInbox, медленному ящику «Входящие» (полное название «Отложенные входящие»)**. Почему должно быть различие между скоростью и медлительностью? Поскольку быстрый ящик предназначен для приема пакета транзакций L2, выдаваемого секвенсором, все транзакции, которые не были предварительно обработаны секвенсором в сети L2, не должны появляться в контракте быстрого ящика.

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

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

Вторая функция медленного ящика — сопротивление цензуре. Пользователи напрямую отправляют транзакции в контракт медленного ящика, и сортировщик обычно объединяет их в быстрый ящик в течение 10 минут. Но если сортировщик злонамеренно игнорирует ваш запрос, в медленном блоке также есть функция принудительного включения:

Если транзакция отправлена в папку «Отложенные входящие», и через 24 часа транзакция в медленном ящике не была включена секвенсором в последовательность транзакций, ** пользователь может вручную активировать функцию принудительного включения на уровне 1, ** чтобы игнорировать его секвенсором. Запросы транзакций принудительно собираются в папке «Входящие секвенсора», затем будут отслеживаться всеми узлами Arbitrum One и принудительно включаться в последовательность транзакций уровня 2. **

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

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

Несколько основных функций медленного ящика «Входящие»:

• DepositETH(), самая простая функция для внесения ETH.
• createRetryableTicket(), который можно использовать для ETH, ERC20 и пополнения баланса сообщений. По сравнению с депозитом ETH() он обладает большей гибкостью, например, вы можете указать платежный адрес L2 после депозита и т. д.
• ForceInclusion(), функция принудительного сбора данных, может быть вызвана кем угодно. Эта функция проверит, не была ли транзакция, отправленная в контракт медленного ящика, обработана через 24 часа. Если условия соблюдены, сообщения будут принудительно собраны.

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

Исходящие Исходящие

Исходящие относятся только к снятию средств и могут пониматься как система записи и управления выводами средств:

• Мы знаем, что для вывода средств с официального моста Arbitrum необходимо подождать около 7 дней до окончания периода вызова и завершения процесса объединения, прежде чем вывод можно будет осуществить. После окончания периода проверки пользователь отправляет соответствующее доказательство Меркла в контракт Outbox на уровне 1, который затем связывается с контрактами для других функций (например, разблокировка активов, заблокированных в других контрактах), и, наконец, завершает вывод средств.
• Контракт OutBox будет записывать, какие межсетевые сообщения от L2 до L1 были обработаны, чтобы предотвратить повторную отправку выполненных запросов на вывод средств. оно проходит
• маппинг(uint256 => bytes32) общедоступные траты, записывает соответствие между индексом расходов запроса на вывод и информацией, если маппинг [spentIndex] != bytes32(0) значит запрос отозван. Принцип аналогичен счетчику транзакций Nonce для предотвращения атак повторного воспроизведения.

Ниже мы возьмем ETH в качестве примера, чтобы полностью объяснить процесс пополнения и вывода средств. Единственная разница между ERC20 и Gateway заключается в том, что она не будет описываться подробно.

Депозит в ETH

1. Пользователь вызывает функцию депозита ETH() медленного ящика.

2. Эта функция продолжит вызывать Bridge.enqueueDelayedMessage(), записывать сообщение в контракт моста и отправлять ETH в контракт моста. **Все средства пополнения ETH хранятся в мостовом контракте, который эквивалентен адресу пополнения. **

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

4. Секвенсор включает запись пополнения счета в пакет транзакций и отправляет ее контракту Fast Box на L1.

Вывод ETH

1. Пользователь вызывает функцию выводаEth() контракта ArbSys на L2, чтобы уничтожить соответствующее количество ETH на L2.

2. Секвенсор отправляет запрос на вывод средств в экспресс-бокс.

3 **Узел валидатора создает новый блок объединения на основе последовательности транзакций в быстром блоке, который будет содержать указанную выше транзакцию вывода средств. **

4. После того, как блок объединения пройдет период проверки и будет подтвержден, пользователь может вызвать функцию Outbox.ute Transaction() на уровне L1, чтобы доказать, что параметры заданы контрактом ArbSys, упомянутым выше.

5. После подтверждения правильности контракта Outbox соответствующая сумма ETH в разблокированном мосте будет отправлена пользователю.

Быстрый вывод

**Если вы используете официальный мост Optimistic Rollup для вывода наличных, возникнет проблема с ожиданием периода вызова. Чтобы обойти эту проблему, мы можем использовать частный сторонний межсетевой мост: **

• Обмен атомными замками. Этот метод обменивается активами только между двумя сторонами в рамках их соответствующих цепочек и является атомарным.Пока одна сторона предоставляет прообраз, обе стороны обязательно получат активы, которых они заслуживают. Но проблема в том, что ликвидности относительно мало и контрагентов нужно искать по принципу «точка-точка».
• **Свидетель перекрестно-цепного моста. **Общие типы перекрестных мостов — это мосты-свидетели. Пользователи отправляют свои собственные запросы на вывод средств и указывают пункты назначения вывода оператору стороннего моста или пула ликвидности. После того, как свидетель обнаружит, что кросс-чейн транзакция была отправлена в контракт Fast Box L1, он может напрямую перевести деньги пользователю на стороне L1. Этот подход по существу использует другую систему консенсуса для мониторинга уровня 2 и работы на основе данных, отправленных на уровень 1. **Проблема в том, что запас прочности в этом режиме не такой высокий, как в официальном мосте Rollup. **

Принудительный вывод

Force Inclusion() Функция принудительного включения используется для предотвращения проверки секвенсора. С помощью этой функции можно реализовать любую локальную транзакцию L2, транзакцию L1-L2 и транзакцию L2-L1. Вредоносная проверка секвенсора серьезно влияет на качество транзакций. В большинстве случаев мы выбираем вывод денег и выход из L2. Поэтому в следующем примере в качестве примера используется принудительное снятие, чтобы представить использование ForceInclusion.

**Напомним, что на этапах вывода ETH только шаги 1 и 2 включают проверку секвенсора, поэтому необходимо изменить только эти два шага: **

• Вызовите inbox.sendL2Message() в контракте медленного ящика на L1. Входные параметры — это параметры, которые необходимо ввести при вызове drawEth() на L2. Это сообщение будет передано мостовому контракту на уровне L1.
• После ожидания 24-часового периода ожидания принудительного включения вызовите Force Inclusion() в быстром поле для выполнения принудительного включения. Контракт быстрого окна проверит, есть ли соответствующее сообщение в мосту.

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

Кроме того, в арбитражных учебниках также есть подробные руководства по использованию Arb SDK, которые помогут пользователям выполнять локальные транзакции L2 и транзакции L2-L1 с помощью ForceInclusion().