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

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

В предыдущей статье «Бывшие технические амбассадоры Arbitrum объясняют компонентную структуру Arbitrum (Часть I)» мы рассказали о роли секвенсоров, валидаторов, контрактов SequencerInbox, блоков Rollup и неинтерактивных доказательств мошенничества в основных компонентах Arbitrum, а в сегодняшней статье мы сосредоточимся на компонентах основных компонентов Arbitrum, связанных с обменом сообщениями о межсетевом взаимодействии и устойчивыми к цензуре входами в транзакции.

Тело: В предыдущей статье мы упоминали, что контракт Sequencer Inbox специально получает пакет пакетов транзакций, опубликованных секвенсором на уровне 1. В то же время мы указываем на то, что Sequencer Inbox также известен как Fast Box, в отличие от Slow Box Delayed Inbox (сокращенно Inbox). **Ниже мы более подробно рассмотрим компоненты, связанные с обменом сообщениями о межсетевом взаимодействии, такие как Delayed Inbox.

Принципы кроссчейн-взаимодействия и моста

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

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

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

Поведение Cross-Chain Interaction между Rollup и ETHMainnet принципиально отличается от приведенного выше Cross-Chain Interaction, потому что состояние Layer 2 определяется данными, записанными на Layer 1, пока вы используете официальный мост Rollup Cross-Chain Interaction, он абсолютно безопасен с точки зрения структуры операций. **

Это также подчёркивает суть Rollup, он просто с точки зрения пользователя, как самостоятельная цепочка, но на самом деле так называемый ** “Layer2” - это просто быстрое окно отображения Rollup, открытое для пользователей, и его реальная структура цепочки по-прежнему сжигается на Layer 1. Таким образом, мы можем думать о L2 как о половине цепочки, или «цепочке, созданной на уровне 1».

Retryable ticket Retryables Retryables

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

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

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

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

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

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

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

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

Шлюз межсетевого взаимодействия активов ERC-20

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

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

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

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

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

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

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

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

Если мы теперь переведем кроссчейн-взаимодействие WETH непосредственно на L2, мы обнаружим некоторые странные проблемы:

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

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

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

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

Аналогом SequencerInbox является Delayed Inbox (Отложенный входящий ящик). Так как fast box предназначен для получения пакета транзакций L2, опубликованных секвенсором, все транзакции, которые не были предварительно обработаны секвенсором в сети L2, не должны отображаться в контракте fast box.

** Первая функция медленного блока — обработка поведения при пополнении баланса от L1 до L2. ** Пользователь вносит депозит через Slow Box, а секвенсор прослушивает его, а затем отражает на L2, и, наконец, запись депозита будет включена секвенсором в последовательность транзакций L2 и отправлена в папку «Входящие» секвенсора.

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

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

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

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

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

Несколько основных функций Slowbox Inbox:

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

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

Исходящие

Исходящие связаны только с выводом средств, что можно понимать как систему учета и управления поведением при выводе средств:**

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

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

ETH депозит

1. Пользователь вызывает функцию depositETH() Слоубокса.

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

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

4. Секвенсор включит запись депозита в пакет и отправит ее в Экспресс-контракт на L1.

ETH вывод средств

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

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

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

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

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

Быстрые выплаты

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

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

Принудительные выплаты

force Inclusion() используется для противодействия цензуре секвенсора и может быть использован для любых локальных транзакций L2, L1-to-L2 и L2-to-L1. Злонамеренная цензура секвенсора серьезно повлияла на опыт торговли, и в большинстве случаев мы выберем вывод и выход из L2, поэтому ниже приведен пример принудительного вывода для введения использования forceInclusion.

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

• Вызовите inbox.sendL2Message() в контракте slowbox на L1, а входной параметр — это параметр, который нужно ввести при вызове withdrawEth() на L2. Сообщение передается контракту-мосту на L1.
• Дождавшись 24-часового периода ожидания принудительной агрегации, вызовите force Inclusion() в быстром боксе, чтобы принудительно собрать данные, и контракт fast box проверит, есть ли соответствующее сообщение в мосту.

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

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