Колишній технічний представник Arbitrum пояснює структуру компонентів Arbitrum (частина 2)

Як Arbitrum обробляє міжланцюговий обмін повідомленнями та транзакції, стійкі до цензури? Яка модель перехресного ланцюгового мосту?

Написав: Луо Бенбен, колишній технічний представник Arbitrum і фанат веб3-дописувача

У попередній статті* «Колишній технічний посол Arbitrum інтерпретує структуру компонентів Arbitrum (частина 1)»** ми представили секвенсор, валідатор, договір вхідної скриньки секвенсора, зведений блок і неінтерактивний захист від шахрайства в основних компонентах Arbitrum. У сьогоднішній статті ми зосередимося на компонентах, пов’язаних із міжланцюговим обміном повідомленнями та стійкими до цензури входами транзакцій серед основних компонентів Arbitrum. *

У попередній статті ми згадували, що контракт Inbox секвенсора спеціально отримує пакет даних транзакції Batch, опублікований секвенсером на рівні 1. Водночас ми зазначаємо, що вхідну скриньку секвенсора також називають швидкою скринькою, на відміну від повільної скриньки із затримкою вхідних повідомлень (іменована папкою вхідних повідомлень). Нижче ми надамо детальне пояснення компонентів, пов’язаних із міжланцюжковим обміном повідомленнями, наприклад «Відкладена папка вхідних».

Принципи перехресного ланцюга та перемикання

Перехресні транзакції можна розділити на L1 до L2 (поповнення) і L2 до L1 (виведення коштів). Зауважте, що згадані тут поповнення та зняття не обов’язково пов’язані з міжланцюжковими активами, але можуть бути повідомленнями, які безпосередньо не включають активи. Отже, ці два слова представляють лише два напрямки поведінки, пов’язаної між ланцюгами.

У порівнянні з чистими транзакціями L2, міжланцюгові транзакції обмінюються інформацією в двох різних системах, L1 і L2, тому процес є більш складним.

Крім того, те, що ми зазвичай називаємо перехресним ланцюгом, є перехресним ланцюгом у двох непов’язаних мережах за допомогою перехресного мосту в режимі спостереження. Безпека цього перехресного ланцюга залежить від перехресного ланцюжкового мосту. Оператори, викрадення перехресних ланцюгові мости, засновані на моделі свідків, траплялися в історії часто.

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

Це також підкреслює суть Rollup. З точки зору користувача він лише виглядає як незалежний ланцюжок, але насправді так званий «**Layer2» — це лише вікно швидкого відображення, яке Rollup відкриває користувачам. Його справжній тип ланцюжка Структура все ще записується на Layer1. **Таким чином, ми можемо розглядати L2 як половину ланцюжка або «ланцюг, створений на Рівні 1».

Retryable ticketsRetryables

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

Квитки з можливістю повторної спроби є основними інструментами, які використовуються під час депозиту через офіційний міст 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 є еквівалентом ERC20 ETH. Як основна валюта, Ether не може реалізувати складні функції в багатьох dApps, тому потрібен еквівалент ERC20. Перенесіть трохи ETH у контракт WETH, вони будуть заблоковані в контракті, і буде згенеровано таку ж кількість WETH.

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

Якщо ми зараз з’єднаємо WETH безпосередньо з L2, ми виявимо деякі дивні проблеми:

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

Очевидно, це порушує принципи дизайну WETH. **Тоді, коли WETH є крос-ланцюгом, незалежно від того, поповнюється чи знімається, його потрібно спочатку розгорнути в ETH, потім перейти на іншу сторону, а потім загорнути в WETH. **Це роль WETH Gateway.

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

Вхідні із затримкою

Швидкій скриньці, також відомої як SequencerInbox, відповідає повільна папка «Вхідні» (повна назва «Відкладена папка вхідних»)**. Чому потрібно розрізняти швидкість і повільність? Оскільки швидкий ящик призначений для отримання пакету транзакцій L2, виданого секвенсором, усі транзакції, які не були попередньо оброблені секвенсором у мережі L2, не повинні відображатися в контракті швидкого ящика.

**Першою функцією повільного блоку є керування поведінкою перезарядки від L1 до L2. **Користувач поповнює рахунок через повільний ящик, а секвенсор відстежує його, а потім відображає на L2. Нарешті, секвенсор включає запис поповнення в послідовність транзакцій L2 і надсилає його до вхідної скриньки секвенсора контракту швидкого блоку.

У цьому прикладі користувачам недоцільно надсилати транзакції поповнення безпосередньо в експрес-скриньку, оскільки транзакції, надіслані в експрес-скриньку секвенсора, заважатимуть нормальному сортуванню транзакцій рівня 2, а потім впливатимуть на роботу секвенсора.

Друга функція повільної коробки — протистояти цензурі. Користувачі безпосередньо надсилають транзакції до контракту повільної скриньки, а сортувальник зазвичай об’єднує їх у швидку скриньку протягом 10 хвилин. Але якщо сортувальник зловмисно ігнорує ваш запит, повільний блок також має функцію примусового включення:

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

Як ми щойно зазначали, дані в швидкому ящику є об’єктом історичних даних L2. Таким чином, у разі зловмисної цензури, інструкції щодо транзакцій можуть бути остаточно включені в книгу L2 через повільний блок, який охоплює такі сценарії, як примусове зняття коштів і вихід із рівня 2. **

Звідси видно, що для транзакцій будь-якого напрямку та рівня секвенсер остаточно не зможе вас постійно переглядати.

Кілька основних функцій повільної скриньки Inbox:

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

Однак слід зазначити, що функція примусового включення фактично розташована в контракті швидкого блоку.Просто для зручності розуміння ми пояснимо це разом у повільному боксі.

Вихідні Вихідні

Поштова скринька «Вихідні» пов’язана лише зі зняттям коштів і може розглядатися як система запису та керування зняттями:

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

Нижче ми візьмемо ETH як приклад, щоб повністю пояснити процес внесення та зняття коштів. Єдина відмінність між ERC20 і Gateway полягає в тому, що він не буде описуватися в деталях.

Депозит ETH

1. Користувач викликає функцію depositETH() повільного ящика.

2. Ця функція продовжуватиме викликати bridge.enqueueDelayedMessage(), записуватиме повідомлення в бридж-контракт і надсилатиме ETH у бридж-контракт. **Усі кошти поповнення ETH зберігаються в бридж-контракті, що еквівалентно адресі поповнення. **

3. Секвенсор відстежує повідомлення про поповнення в повільному вікні та відображає операцію поповнення в базі даних рівня 2. Користувачі можуть бачити активи, які вони поповнили в мережі рівня 2.

4. Секвенсор включає запис поповнення в пакет транзакцій і надсилає його до контракту швидкого ящика на L1.

Виведення ETH

1. Користувач викликає функцію drawEth() контракту ArbSys на L2, щоб знищити відповідну кількість ETH на L2.

2. Секвенсор надсилає запит на зняття до експрес-скриньки.

3 **Вузол перевірки створює новий зведений блок на основі послідовності транзакцій у швидкому полі, який міститиме наведену вище транзакцію зняття. **

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

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

Швидке виведення

**Якщо ви використовуєте офіційний міст Optimistic Rollup для зняття готівки, виникне проблема очікування періоду виклику. Щоб обійти цю проблему, ми можемо використовувати приватний сторонній перехресний міст: **

• Атомний обмін блокуванням. Цей метод обмінюється лише активами між двома сторонами в межах їхніх відповідних ланцюжків і є атомарним. Поки одна сторона надає Preimage, обидві сторони точно отримають активи, на які заслуговують. Але проблема полягає в тому, що ліквідність відносно невелика, і вам потрібно знаходити контрагентів точка-точка.
• **Свідок перехресного ланцюгового мосту. **Загальні типи перехресних ланцюгових мостів є мостами-свідками. Користувачі надсилають власні запити на зняття коштів, а пункт призначення вказує на оператора стороннього мосту або пулу ліквідності. Після того, як свідок виявляє, що трансакцію між ланцюжками було передано в контракт швидкої скриньки 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() у швидкому ящику, щоб виконати примусове включення. Контракт швидкого ящика перевірить, чи є відповідне повідомлення в мосту.

Кінцеві користувачі можуть знімати гроші в папці «Вихідні», а інші дії такі ж, як і при звичайних видаленнях.

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