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

Основной текст: В предыдущих статьях мы упоминали, что контракт Sequencer Inbox специально разработан для получения пакетов данных транзакций, публикуемых секвенсором на Уровне 1. В то же время, мы отметили, что Sequencer Inbox также называют "быстрым ящиком", а в противоположность ему есть "медленный ящик" или Delayed Inbox (именуемый Inbox). Ниже мы дадим подробную интерпретацию компонентов, связанных с передачей сообщений по цепочке, включая 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, то, несмотря на определенную симметричность процесса по сравнению с депозитами, здесь отсутствует концепция повторных билетов. Это можно понять с точки зрения самого протокола 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.
• Шлюз-маршрутизатор отвечает за поддержание соответствия адресов между Token L1<->Token L2. Кроме того, отображение между некоторым маркером<->некоторым шлюзом.
• Сам шлюз можно разделить на стандартный шлюз ERC20, шлюз Generic-custom, шлюз Custom и т.д., чтобы решить различные типы и функции проблем с мостом ERC20.

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

WETH - это ERC20-эквивалент ETH. Будучи основной валютой, Ether не может реализовать сложные функции во многих dApp, поэтому необходим эквивалент 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 наследует логику межцепочечного взаимодействия обычного шлюза и позволяет разработчикам настраивать поведение межцепочечного взаимодействия, связанное с логикой токенов, что может удовлетворить большинство потребностей.

Отложенная папка "Входящие

Аналогом быстрой папки "Входящие", известной как Sequencer Inbox, является медленная папка "Входящие" (полное название - Delayed Inbox). Зачем различать быстрое и медленное? Это связано с тем, что быстрый почтовый ящик предназначен для приема партий транзакций L2, опубликованных секвенсором, и любые транзакции, не прошедшие предварительную обработку секвенсором в сети L2, не должны появляться в контракте быстрого почтового ящика.

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

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

Вторая функция медленного почтового ящика - защита от цензуры. Транзакции, напрямую отправленные в контракт медленного инбокса, обычно агрегируются секвенсором в быстрый инбокс в течение 10 минут. Однако если секвенсор злонамеренно игнорирует Ваш запрос, в медленном инбоксе есть функция принудительного включения:

Если транзакция отправлена в папку Delayed Inbox и по истечении 24 часов она по-прежнему не включена секвенсором в последовательность транзакций, пользователи могут вручную запустить функцию принудительного включения на Layer1. Это действие заставляет транзакции, проигнорированные секвенсором, быть принудительно объединенными в быструю папку входящих сообщений (Sequencer Inbox). Впоследствии они будут обнаружены всеми узлами Arbitrum One и принудительно включены в последовательность транзакций уровня 2.

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

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

Несколько основных функций медленной папки "Входящие" (Inbox):

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

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

Outbox

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

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

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

Депозит ETH

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

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

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

4. Секвенсор включает запись о депозите в пакет транзакций и отправляет его в контракт фаст-бокса на L1.

Вывод средств из ETH

1. Пользователь вызывает функцию withdrawEth() контракта ArbSys на L2, и соответствующее количество ET сгорает на L2.

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

3. Узел Validator создает новый блок Rollup Block на основе последовательности транзакций в быстром блоке, который будет содержать вышеуказанные транзакции вывода средств.

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

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

Быстрое снятие наличных

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

• Атомарный обмен замками. Этот метод предусматривает обмен активами только между двумя сторонами в рамках их соответствующих цепочек и является атомарным. Если одна из сторон обеспечивает Предварительный расчет, обе стороны обязательно получат имущество, которого они заслуживают. Но проблема в том, что ликвидность относительно скудна, и Вам нужно найти контрагентов с помощью метода "равный-равному".F
• Свидетели пересекают цепной мост. Общими типами мостов с перекрестными цепями являются мосты-свидетели. Пользователи подают собственные запросы на вывод средств, а пункт назначения вывода указывает на оператора стороннего моста или пула ликвидности. После того, как свидетель обнаружит, что межцепочечная транзакция была передана в контракт L1 fast box, он может напрямую перевести деньги пользователю на стороне L1. Этот подход, по сути, использует другую систему консенсуса для мониторинга уровня 2 и работы на основе данных, которые она передала на уровень 1. Проблема в том, что уровень безопасности в этом режиме не так высок, как в официальном мосте Rollup. \

Вынужденный уход

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

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

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

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

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

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

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