Основной текст: В предыдущих статьях мы упоминали, что контракт Sequencer Inbox специально разработан для получения пакетов данных транзакций, публикуемых секвенсором на Уровне 1. В то же время, мы отметили, что Sequencer Inbox также называют "быстрым ящиком", а его аналог - Delayed Inbox (именуемый Inbox). Далее мы подробно расскажем о компонентах, связанных с передачей сообщений по цепочке, таких как Delayed Inbox.

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

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

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

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

В отличие от этого, поведение кросс-цепочек между Rollup и мейннетом Ethereum в корне отличается от вышеупомянутых кросс-цепочечных операций. Это происходит потому, что состояние Уровня 2 определяется данными, записанными на Уровне 1. Пока Вы используете официальный межцепочечный мост Rollup, его операционная структура абсолютно безопасна.

Это также подчеркивает суть Rollup, который, с точки зрения пользователя, выглядит как независимая цепочка. Однако в действительности так называемый "Уровень 2" - это всего лишь окно быстрого отображения, открываемое Rollup для пользователей, а его настоящая цепочечная структура по-прежнему записана на Уровне 1. Поэтому мы можем рассматривать L2 как половину цепочки, или как "цепочку, созданную на Уровне 1".

Retryables

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

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

1. Отправка билета на L1: Создайте депозитный билет с помощью метода createRetryableTicket() в контракте Delayed Inbox и отправьте его.

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

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

Более того, в процессе вывода средств с официального моста Арбитрум, несмотря на некоторое симметричное сходство с поведением депозита в плане процесса, отсутствует понятие Retryables. Это можно понять как с точки зрения самого протокола Rollup, так и рассмотрев некоторые различия:

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

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

Межцепочечный шлюз для активов ERC-20

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

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

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

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

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

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

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

WETH - это ERC20-эквивалент ETH. Поскольку Эфир выступает в качестве основной валюты, многие сложные функциональные возможности в dApps невозможно реализовать напрямую. Следовательно, необходим эквивалент ERC20, например, WETH. Вкладывая некоторое количество 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, также известного как быстрый ящик, является Inbox (официальное название - Delayed Inbox). Почему существует различие между быстрыми и отложенными коробками? Поскольку быстрый блок специально разработан для приема партий транзакций L2, опубликованных секвенсором, любые транзакции, не прошедшие предварительную обработку секвенсором в сети L2, не должны появляться в контракте быстрого блока.

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

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

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

Если транзакция отправлена в Delayed Inbox и по истечении 24 часов не включена секвенсором в последовательность транзакций, пользователи могут вручную запустить функцию принудительного включения на Уровне 1. Это действие заставляет игнорируемые секвенсором запросы транзакций объединяться в быстрый ящик SequencerInbox и впоследствии обнаруживаться всеми узлами Arbitrum One, таким образом, принудительно включаясь в последовательность транзакций уровня 2.

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

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

Несколько основных функций медленной коробки Inbox заключаются в следующем:

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

Однако важно отметить, что функция forceInclusion() на самом деле находится в контракте fast box. Для наглядности мы рассмотрели его здесь вместе с функциями медленной коробки.

Outbox

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

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

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

Депозит ETH

1. Пользователь вызывает функцию depositETH() отложенного почтового ящика.
2. Затем эта функция вызывает bridge.enqueueDelayedMessage(), который записывает сообщение в мостовой контракт и отправляет ETH в мостовой контракт. Все внесенные средства ETH хранятся в бридж-контракте, выступающем в качестве адреса депозита.
3. Секвенсор отслеживает сообщение о вкладе в папке "Отложенные входящие" и отражает операцию вклада в базе данных L2. Пользователи могут видеть свои депонированные активы в сети L2.
4. Секвенсор включает запись о депозите в пакет транзакций и отправляет ее в контракт Fast Inbox на L1.

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

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

2. Секвенсор отправляет запрос на снятие денег в быстрый ящик.

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

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

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

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

Использование оптимистичного официального моста Rollup предполагает ожидание периода вызова. Чтобы обойти эту проблему, мы можем использовать частный межцепочечный мост третьей стороны:

• Атомарный обмен: При таком подходе обмен активами между сторонами происходит в рамках их соответствующих цепочек, и он является атомарным, то есть если одна сторона предоставляет предварительный образ, обе стороны могут получить соответствующие активы. Однако ликвидность относительно дефицитна, что требует поиска контрагентов по принципу "равный-равному".
• Межцепочечный мост на основе свидетелей: Большинство типов межцепочечных мостов попадают в эту категорию. Пользователи подают заявки на вывод средств, указывая в качестве пункта назначения оператора или пул ликвидности стороннего моста. Как только свидетель обнаружит, что межцепочечная транзакция была отправлена на контракт Fast Inbox на L1, он сможет напрямую перевести средства пользователю на L1. По сути, этот метод использует другую систему консенсуса для мониторинга уровня 2 и выполнения операций на основе данных, переданных на уровень 1. Однако уровень безопасности в этом режиме ниже по сравнению с официальным мостом Rollup.

Вывод войск

Функция forceInclusion() используется для борьбы с цензурой секвенсора. Его можно применять к любым локальным транзакциям L2, транзакциям L1-L2 и транзакциям L2-L1. Поскольку злонамеренная цензура секвенсора значительно ухудшает впечатления от транзакций, мы часто предпочитаем отказаться от участия в L2. Ниже приведен пример использования функции forceInclusion() для принудительного выхода:

В контексте вывода ETH только шаги 1 и 2 связаны с цензурой секвенсора. Поэтому нам нужно изменить только эти два шага:

• Вызовите inbox.sendL2Message() в контракте Delayed Inbox на L1, с параметрами, необходимыми при вызове withdrawEth() на L2. Это сообщение передается по мостовому контракту на L1.
• После 24-часового периода ожидания принудительного включения вызовите функцию forceInclusion() в контракте Fast Inbox, чтобы принудительно включить его. Контракт Fast Inbox проверит, есть ли соответствующее сообщение в мосту.

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

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

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

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