В предыдущей статье "Компонентная структура 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".
Обратите внимание, что транзакции между цепочками являются асинхронными и неатомарными. В отличие от транзакций на одной цепи, завершение транзакции и подтверждение результата после одной транзакции на одной цепи невозможно при межцепочечных транзакциях. Также нет никакой гарантии, что на другой стороне в определенный момент времени произойдет что-то конкретное. Поэтому межцепочечные транзакции могут быть неудачными из-за некоторых мягких проблем, но при использовании надлежащих методов, таких как тикеты с возможностью повторной попытки, жесткие проблемы, такие как застревание средств, не возникнут.
Повторные билеты - это фундаментальный инструмент, используемый в официальном мосте Arbitrum во время депозитов, применимый как к депозитам ETH, так и к депозитам ERC20. Жизненный цикл состоит из трех этапов:
Более того, что касается процесса вывода средств на официальном мосту Arbitrum, то, несмотря на определенную симметричность процесса по сравнению с депозитами, здесь отсутствует концепция повторных билетов. Это можно понять с точки зрения самого протокола Rollup, и можно выделить некоторые различия:
Перекрестное связывание активов ERC-20 - сложная задача. Мы можем подумать над несколькими вопросами:
Мы не собираемся отвечать на все эти вопросы, потому что они слишком сложны для раскрытия. Эти вопросы используются только для того, чтобы проиллюстрировать сложность кросс-цепочки ERC20.
В настоящее время многие решения для масштабирования используют белые списки и ручные списки, чтобы избежать различных сложных проблем и граничных условий.
Arbitrum использует систему Gateway, чтобы решить большинство проблем с залипанием кросс-цепочек ERC20. Он обладает следующими характеристиками:
Давайте рассмотрим относительно простую кросс-цепочку WETH в качестве примера, иллюстрирующего необходимость настройки шлюза.
WETH - это ERC20-эквивалент ETH. Будучи основной валютой, Ether не может реализовать сложные функции во многих dApp, поэтому необходим эквивалент ERC20. Переведите некоторое количество ETH в контракт WETH, они будут заблокированы в контракте, и будет сгенерировано такое же количество WETH.
Таким же образом можно сжигать WETH и выводить ETH. Очевидно, что соотношение циркулирующих WETH и заблокированных ETH всегда составляет 1:1.
Если теперь мы напрямую соединим цепочку WETH с 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):
Однако важно отметить, что функция включения силы на самом деле находится в быстром контракте inbox. Для облегчения понимания мы объяснили это вместе с медленным инбоксом.
Outbox имеет отношение только к снятию денег и может быть понят как система записи и управления поведением при снятии денег:
Ниже мы рассмотрим ETH в качестве примера, чтобы полностью объяснить процесс внесения и снятия средств. Единственное различие между ERC20 и ETH заключается в том, что в первом случае используется Gateway. Мы не будем объяснять это в деталях.
Пользователь вызывает функцию depositETH() медленного ящика.
Эта функция будет продолжать вызывать 'bridge.enqueueDelayedMessage()', запишите сообщение в мостовой контракт и отправьте ETH в мостовой контракт. Все средства депозита ETH хранятся в бридж-контракте, который эквивалентен адресу депозита.
Секвенсор отслеживает сообщения о пополнении счета в медленном ящике и отражает операцию пополнения счета в базе данных L2. Пользователи могут видеть активы, которые они разместили в сети L2.
Секвенсор включает запись о депозите в пакет транзакций и отправляет его в контракт фаст-бокса на L1.
Пользователь вызывает функцию withdrawEth() контракта ArbSys на L2, и соответствующее количество ET сгорает на L2.
Секвенсор отправляет запрос на вывод средств в экспресс-бокс.
Узел Validator создает новый блок Rollup Block на основе последовательности транзакций в быстром блоке, который будет содержать вышеуказанные транзакции вывода средств.
После того, как блок Rollup пройдет период испытания, который также будет подтвержден, пользователь может вызвать функцию Outbox.execute Transaction() на L1, чтобы доказать, что параметры заданы контрактом ArbSys, о котором говорилось выше.
После подтверждения правильности контракта Outbox соответствующее количество ETH в мосте будет разблокировано и отправлено пользователю.
При использовании официального моста Optimistic Rollup для снятия наличных возникнет проблема ожидания периода вызова. Для устранения этой проблемы мы можем использовать частный межцепочечный мост третьей стороны:
Функция force Inclusion() используется для противостояния цензуре секвенсора. Любая локальная транзакция L2, транзакция L1-L2 и транзакция L2-L1 может быть реализована с помощью этой функции. Вредоносная цензура секвенсора серьезно влияет на опыт транзакций. В большинстве случаев мы предпочитаем снять деньги и оставить L2. Поэтому ниже в качестве примера для ознакомления с использованием ForceInclusion используется принудительное снятие.
Если посмотреть на шаги вывода ETH, то только шаги 1 и 2 включают в себя цензуру секвенсора, поэтому нужно изменить только эти два шага:
Конечные пользователи могут выводить деньги в Outbox, а остальные шаги такие же, как и при обычном выводе средств.
Кроме того, в arbitrum-tutorials есть подробные руководства по использованию Arb SDK, которые подскажут пользователям, как выполнять локальные транзакции L2 и транзакции L2 to L1 с помощью функции forceInclusion().
В предыдущей статье "Компонентная структура 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".
Обратите внимание, что транзакции между цепочками являются асинхронными и неатомарными. В отличие от транзакций на одной цепи, завершение транзакции и подтверждение результата после одной транзакции на одной цепи невозможно при межцепочечных транзакциях. Также нет никакой гарантии, что на другой стороне в определенный момент времени произойдет что-то конкретное. Поэтому межцепочечные транзакции могут быть неудачными из-за некоторых мягких проблем, но при использовании надлежащих методов, таких как тикеты с возможностью повторной попытки, жесткие проблемы, такие как застревание средств, не возникнут.
Повторные билеты - это фундаментальный инструмент, используемый в официальном мосте Arbitrum во время депозитов, применимый как к депозитам ETH, так и к депозитам ERC20. Жизненный цикл состоит из трех этапов:
Более того, что касается процесса вывода средств на официальном мосту Arbitrum, то, несмотря на определенную симметричность процесса по сравнению с депозитами, здесь отсутствует концепция повторных билетов. Это можно понять с точки зрения самого протокола Rollup, и можно выделить некоторые различия:
Перекрестное связывание активов ERC-20 - сложная задача. Мы можем подумать над несколькими вопросами:
Мы не собираемся отвечать на все эти вопросы, потому что они слишком сложны для раскрытия. Эти вопросы используются только для того, чтобы проиллюстрировать сложность кросс-цепочки ERC20.
В настоящее время многие решения для масштабирования используют белые списки и ручные списки, чтобы избежать различных сложных проблем и граничных условий.
Arbitrum использует систему Gateway, чтобы решить большинство проблем с залипанием кросс-цепочек ERC20. Он обладает следующими характеристиками:
Давайте рассмотрим относительно простую кросс-цепочку WETH в качестве примера, иллюстрирующего необходимость настройки шлюза.
WETH - это ERC20-эквивалент ETH. Будучи основной валютой, Ether не может реализовать сложные функции во многих dApp, поэтому необходим эквивалент ERC20. Переведите некоторое количество ETH в контракт WETH, они будут заблокированы в контракте, и будет сгенерировано такое же количество WETH.
Таким же образом можно сжигать WETH и выводить ETH. Очевидно, что соотношение циркулирующих WETH и заблокированных ETH всегда составляет 1:1.
Если теперь мы напрямую соединим цепочку WETH с 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):
Однако важно отметить, что функция включения силы на самом деле находится в быстром контракте inbox. Для облегчения понимания мы объяснили это вместе с медленным инбоксом.
Outbox имеет отношение только к снятию денег и может быть понят как система записи и управления поведением при снятии денег:
Ниже мы рассмотрим ETH в качестве примера, чтобы полностью объяснить процесс внесения и снятия средств. Единственное различие между ERC20 и ETH заключается в том, что в первом случае используется Gateway. Мы не будем объяснять это в деталях.
Пользователь вызывает функцию depositETH() медленного ящика.
Эта функция будет продолжать вызывать 'bridge.enqueueDelayedMessage()', запишите сообщение в мостовой контракт и отправьте ETH в мостовой контракт. Все средства депозита ETH хранятся в бридж-контракте, который эквивалентен адресу депозита.
Секвенсор отслеживает сообщения о пополнении счета в медленном ящике и отражает операцию пополнения счета в базе данных L2. Пользователи могут видеть активы, которые они разместили в сети L2.
Секвенсор включает запись о депозите в пакет транзакций и отправляет его в контракт фаст-бокса на L1.
Пользователь вызывает функцию withdrawEth() контракта ArbSys на L2, и соответствующее количество ET сгорает на L2.
Секвенсор отправляет запрос на вывод средств в экспресс-бокс.
Узел Validator создает новый блок Rollup Block на основе последовательности транзакций в быстром блоке, который будет содержать вышеуказанные транзакции вывода средств.
После того, как блок Rollup пройдет период испытания, который также будет подтвержден, пользователь может вызвать функцию Outbox.execute Transaction() на L1, чтобы доказать, что параметры заданы контрактом ArbSys, о котором говорилось выше.
После подтверждения правильности контракта Outbox соответствующее количество ETH в мосте будет разблокировано и отправлено пользователю.
При использовании официального моста Optimistic Rollup для снятия наличных возникнет проблема ожидания периода вызова. Для устранения этой проблемы мы можем использовать частный межцепочечный мост третьей стороны:
Функция force Inclusion() используется для противостояния цензуре секвенсора. Любая локальная транзакция L2, транзакция L1-L2 и транзакция L2-L1 может быть реализована с помощью этой функции. Вредоносная цензура секвенсора серьезно влияет на опыт транзакций. В большинстве случаев мы предпочитаем снять деньги и оставить L2. Поэтому ниже в качестве примера для ознакомления с использованием ForceInclusion используется принудительное снятие.
Если посмотреть на шаги вывода ETH, то только шаги 1 и 2 включают в себя цензуру секвенсора, поэтому нужно изменить только эти два шага:
Конечные пользователи могут выводить деньги в Outbox, а остальные шаги такие же, как и при обычном выводе средств.
Кроме того, в arbitrum-tutorials есть подробные руководства по использованию Arb SDK, которые подскажут пользователям, как выполнять локальные транзакции L2 и транзакции L2 to L1 с помощью функции forceInclusion().