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

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

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

Тіло: У попередній статті ми згадували, що контракт Sequencer Inbox конкретно отримує партію пакетів транзакцій, опублікованих секвенсором на рівні 1. У той же час ми зазначаємо, що Sequencer Inbox також відомий як Fast Box, на відміну від Slow Box Delayed Inbox (скорочено 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».

Повторний квиток Reryables

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

**Повторні тікетси є основними інструментами, які використовуються при внесенні депозиту через офіційний міст 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?
• Токени зі спеціальними функціями, такими як регульована кількість токенів перебазування, самозростаючі токени, що приносять відсотки, як крос-чейн взаємодія?

Ми не збираємося відповідати на всі ці питання, тому що це занадто складно для розширення. Ці питання використовуються лише для ілюстрації складності крос-чейн взаємодії ERC20.

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

Arbitrum використовує систему Gateway для вирішення більшості больових точок крос-чейн взаємодії ERC20 з наступними особливостями:

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

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

WETH є еквівалентом ERC20 ETH. Оскільки Ether є основною монетою, багато складних функцій у dApps неможливі, тому потрібен еквівалент ERC20. Перенесіть деякі ETH в контракт WETH, вони будуть зафіксовані в контракті і така ж кількість WETH буде згенерована.

Таким же чином можна спалити WETH і вивезти ETH. **Очевидно, що кількість WETH в обігу та сума ETH Lock-up Position завжди буде 1:1. **

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

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

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

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

Відкладена поштова скринька

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

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

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

Друга функція slow box – протистояти цензурі. **Транзакції, надіслані безпосередньо користувачами до контракту Slowbox, будуть зібрані секвенсором протягом 10 хвилин. Але якщо секвенсор зловмисно ігнорує ваш запит, slowbox також має функцію примусового включення:

Якщо транзакція надсилається до папки «Відкладені вхідні», через 24 години транзакція в Slowbox не була включена секвенсором у послідовність транзакцій, Користувач може вручну запустити функцію примусового включення на рівні 1, а запити на транзакції, проігноровані секвенсором, примусово групуються в папку «Вхідні» секвенсера Fastbox, після чого вони будуть контролюватися всіма вузлами Arbitrum One і будуть примусово включені в послідовність транзакцій рівня 2.

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

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

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

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

Однак слід зазначити, що функція force Inclusion насправді знаходиться в контракті Slowbox, просто щоб було простіше зрозуміти, ми розмістимо її тут у Slowbox і пояснимо разом.

Вихідні

Вихідна скринька пов’язана лише з виведенням коштів, що можна розуміти як систему обліку та управління поведінкою при виведенні коштів:**

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

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

ETH депозит

1. Користувач викликає функцію depositETH() Slowbox.

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

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

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

ETH зняття коштів

1. Користувач викликає функцію withdrawEth() контракту ArbSys на L2 для спалювання відповідної кількості ETH на L2.

2. Секвенсор відправляє запит на виведення коштів в Quickbox.

**3.Вузол-валідатор створює новий Rollup Block на основі послідовності транзакцій у Fastbox, який міститиме вищезазначені транзакції виведення. **

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

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

Швидкі виплати

Виведення коштів за допомогою офіційного мосту Optimistic Rollup призведе до періоду очікування на період челенджу. Ми можемо обійти цю проблему за допомогою приватних сторонніх мостів Cross-Chain Interaction:

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

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

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