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

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

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

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

Крім того, те, що ми зазвичай називаємо крос-ланцюговою поведінкою, є крос-ланцюговою поведінкою між двома непов'язаними мережами з використанням крос-ланцюгового моста в режимі свідка. Безпека цього крос-ланцюга залежить від містка між ланцюгами. Історично склалося так, що крос-ланцюгові мости, засновані на режимі свідка, часто стикалися з інцидентами крадіжок.

На противагу цьому, поведінка між ланцюжком Rollup і основною мережею Ethereum принципово відрізняється від вищезгаданих міжланцюгових операцій. Це пов'язано з тим, що стан рівня 2 визначається даними, записаними на рівні 1. Якщо ви використовуєте офіційний перехресний міст Rollup, його робоча структура абсолютно безпечна.

Це також підкреслює суть Rollup, який з точки зору користувача виглядає як незалежний ланцюжок. Однак насправді так званий "Рівень 2" - це лише вікно швидкого відображення, яке Rollup відкриває користувачам, а його справжня ланцюжкова структура все ще записана на Рівні 1. Тому ми можемо розглядати L2 як половину ланцюга, або як "ланцюг, створений на рівні 1".

Повторні спроби

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

Повторні квитки - це основні інструменти, які використовуються при поповненні рахунку через офіційний міст 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 є складними. Ми можемо розглянути кілька питань:

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

Ми не маємо наміру відповідати на всі ці питання, оскільки вони надто складні для всебічного розгляду. Ці питання просто покликані проілюструвати складність транзакцій між ланцюжками ERC-20.

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

Arbitrum використовує систему шлюзів для вирішення більшості проблемних питань, пов'язаних з міжмережевими транзакціями ERC20, з наступними характеристиками:

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

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

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

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

Відкладені вхідні

Аналогом SequencerInbox, також відомим як швидка скринька, є Inbox (офіційна назва - Delayed Inbox). Чому розрізняють швидкі та відкладені скриньки? Оскільки фаст-бокс спеціально розроблений для отримання партій L2-транзакцій, опублікованих секвенсором, і будь-які транзакції, які не були попередньо оброблені секвенсором в мережі L2, не повинні з'являтися в контракті фаст-боксу.

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

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

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

Якщо транзакцію надіслано до папки "Відкладені" і вона залишається неагрегованою в послідовність транзакцій секвенсором протягом 24 годин, користувачі можуть вручну активувати функцію примусового включення на рівні 1. Ця дія змушує запити на транзакції, проігноровані секвенсором, агрегуватися у швидку скриньку SequencerInbox, і згодом виявлятися всіма вузлами Arbitrum One, таким чином, примусово включатися в послідовність транзакцій 2-го рівня.

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

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

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

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

Однак важливо зазначити, що функція forceInclusion() насправді знаходиться в контракті фаст-боксу. Для наочності, ми обговорювали її тут разом з функціями повільної скриньки.

Вихідні

Вихідні пов'язані лише з виведенням коштів, і їх можна розуміти як систему реєстрації та управління поведінкою, пов'язаною з виведенням коштів:

• Ми знаємо, що для виведення коштів на офіційному мосту Arbitrum потрібно чекати близько 7 днів, поки закінчиться період оскарження, і виведення може бути здійснене тільки після завершення Rollup Block. Після закінчення періоду оскарження користувач надсилає відповідне підтвердження Merkle Proof контракту Outbox на Layer1, який потім зв'язується з контрактами для виконання інших функцій (наприклад, розблокування активів, заблокованих в інших контрактах) і, нарешті, завершує виведення коштів.
• Контракт OutBox фіксує, які повідомлення між ланцюжками L2 і L1 були оброблені, щоб запобігти повторному надсиланню виконаних запитів на виведення коштів. Це досягається за допомогою відображення, яке називається витраченим, і пов'язує витрачені індекси запитів на виведення коштів з відповідною інформацією. Якщо 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 перевірить, чи є відповідне повідомлення в мості.

Нарешті, користувачі можуть вивести кошти зі скриньки "Вихідні", і решта кроків є такими ж, як і в звичайному процесі виведення коштів.

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

Відмова від відповідальності:.

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