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

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

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

Принцип крос-ланцюга та мостового зв’язку

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

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

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

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

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

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

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

Повторні квитки є основними інструментами, які використовуються в офіційному бриджі Arbitrum під час депозитів, застосовних до депозитів ETH і ERC20. Життєвий цикл складається з трьох етапів:

1. Надсилання квитка на L1: скористайтеся методом «createRetryableTicket()» у контракті Delayed Inbox, щоб створити квитанцію на депозит і надіслати її.
2. Автоматичне погашення на L2: у більшості випадків секвенсор може автоматично викупити квиток для користувача, не вимагаючи додаткових дій вручну.
3. Погашення вручну на L2: у деяких надзвичайних випадках, як-от раптове зростання цін на бензин на L2, якщо попередньо оплаченого газу на квитку недостатньо, автоматичний погашення не відбутися. У цьому випадку потрібне ручне втручання користувача. Важливо зауважити, що якщо автоматичне погашення не вдається, користувач повинен викупити квиток вручну протягом 7 днів; інакше квиток буде або видалено (що призведе до остаточної втрати коштів), або користувачеві потрібно буде сплатити певну комісію, щоб поновити зберігання квитка.

Крім того, щодо процесу зняття на офіційному бриджі Arbitrum, хоча існує певна симетрична подібність процесу порівняно з депозитами, немає поняття повторних квитків. Це можна зрозуміти з точки зору самого протоколу 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 успадковує логіку перехресного зв’язку звичайного шлюзу та дозволяє розробникам налаштовувати поведінку між ланцюжками, пов’язану з логікою токенів, яка може задовольнити більшість потреб.

Затримка вхідних

Відповідником швидкої папки «Вхідні», відомої як папка вхідних повідомлень Sequencer, є повільна папка «Вхідні» (повна назва «Відкладені вхідні»). Навіщо розрізняти швидкий і повільний? Це пояснюється тим, що швидка скринька вхідних повідомлень призначена для отримання пакетів транзакцій L2, опублікованих секвенсором, і будь-які транзакції, які не були попередньо оброблені секвенсером у мережі L2, не повинні з’являтися в контракті швидкої скриньки вхідних повідомлень.

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

У цьому сценарії користувачам недоцільно надсилати депозитні транзакції безпосередньо до швидкої вхідної скриньки (Sequencer Inbox), оскільки транзакції, надіслані до швидкої вхідної скриньки, можуть порушити звичайне впорядкування транзакцій у Рівні 2, тим самим впливаючи на роботу секвенсора.

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

Якщо транзакцію надсилають до папки «Відкладені вхідні» та через 24 години вона залишається невключеною секвенсором у послідовність транзакцій, користувачі можуть вручну активувати функцію примусового включення на рівні 1. Ця дія змушує транзакції, проігноровані секвенсером, примусово агрегуватись у швидку папку «Вхідні» (Sequencer Inbox). Згодом вони будуть виявлені всіма вузлами Arbitrum One і примусово включені в послідовність транзакцій Layer2.

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

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

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

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

Однак важливо зазначити, що функція примусового включення фактично розташована в контракті швидкої папки вхідних повідомлень. Для простоти розуміння ми пояснили це разом із повільною папкою "Вхідні".

Вихідні

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

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

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

Депозит ETH

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

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

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

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

Виведення ETH

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

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

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

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

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

Швидке зняття готівки

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

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

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

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