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

Ця стаття є технічною інтерпретацією Arbitrum One Луо Бенбеном, колишнім технічним представником Arbitrum і колишнім співзасновником аудиторської компанії з автоматизації смарт-контрактів Goplus Security.

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

**Ця стаття є технічною інтерпретацією Arbitrum One Луо Бенбеном, колишнім технічним представником Arbitrum і колишнім співзасновником аудиторської компанії з автоматизації смарт-контрактів Goplus Security. **

Через відсутність професійної інтерпретації Arbitrum і навіть OP Rollup у статтях або матеріалах, пов’язаних із рівнем 2 у китайському колі, ця стаття намагається заповнити прогалину в цій галузі, популяризуючи механізм роботи Arbitrum. Оскільки сама структура Arbitrum занадто складна, повний текст все одно перевищує 10 000 слів, незважаючи на те, що він максимально спрощений, тому він розділений на дві частини. **

Короткий опис зведеного сортувальника

Принцип розширення Rollup можна підсумувати двома пунктами:

**Оптимізація витрат: передайте більшість обчислювальних завдань і завдань зберігання в ланцюг L1, тобто L2. **L2 — це здебільшого ланцюжок, що працює на одному сервері, тобто секвенсорі/операторі.

Сортувальник виглядає та відчувається схожим на централізований сервер. У «неможливих трьох аспектах блокчейну» від «децентралізації» відмовляються в обмін на TPS та економічні переваги. Користувачі можуть дозволити L2 обробляти інструкції щодо транзакцій замість Ethereum, і вартість набагато нижча, ніж торгівля на Ethereum.

(Джерело: BNB Chain)

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

**Загалом безпека Rollup базується на Ethereum. **Якщо секвенсор не знає закритого ключа облікового запису, він не може ініціювати транзакції від імені облікового запису або не може втручатися в баланс активів облікового запису (навіть якщо знає, це буде швидко виявлено).

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

(Протокол Loopring встановлює функцію примусового зняття у вихідному коді контракту на рівні L1 для виклику користувачів)

Методи перевірки стану, щоб запобігти злому секвенсору Rollup, поділяються на дві категорії: захист від шахрайства та доказ дійсності. Зведена схема, що використовує докази шахрайства, називається OP Rollup (Optimistic Rollup, OPR), тоді як через деякий історичний багаж схему Rollup, що використовує підтвердження дійсності, часто називають ZK Rollup** (Zero-knowledge Proof Rollup, ZKR ) замість Validity Rollup. .

Arbitrum One — це типовий OPR. Він розгортає контракти на L1 і не перевіряє надіслані дані. Оптимістично, що з даними немає проблем. Якщо подані дані неправильні, вузол верифікатора L2 активно ініціює виклик.

Таким чином, **OPR також передбачає припущення про довіру: у будь-який час існує принаймні один чесний вузол перевірки L2. **Контракт ZKR використовує криптографічні обчислення для активної, але економічно ефективної перевірки даних, наданих секвенсером.

(метод оптимістичного зведення)

(режим роботи ZK Rollup)

У цій статті ми детально ознайомимося з Arbitrum One, провідним проектом оптимістичного зведення, охоплюючи всі аспекти всієї системи. Уважно прочитавши її, ви матимете глибоке розуміння Arbitrum і optimistic rollup/OPR.

Основні компоненти та робочий процес Arbitrum

Основний договір:

Найважливіші контракти Arbitrum включають **SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge тощо. **Деталі будуть представлені пізніше.

Секвенсор:

Отримувати та сортувати транзакції користувачів, обчислювати результати транзакцій і швидко повертати квитанції користувачам (зазвичай <1 с). Користувачі часто можуть побачити свої транзакції, перелічені на L2, протягом кількох секунд, і досвід схожий на платформу Web2.

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

Кожні кілька хвилин секвенсор буде стискати відсортовані дані транзакцій L2, об’єднувати їх у пакети та надсилати їх у вхідну скриньку контракту SequencerInbox на рівні 1, щоб забезпечити доступність даних і роботу протоколу Rollup. Загалом, дані L2, надіслані на рівень 1, не можна відкотити назад і можуть бути остаточними.

З наведеного вище процесу ми можемо підсумувати: **Рівень 2 має власну мережу вузлів, але кількість цих вузлів невелика, і, як правило, не існує консенсусного протоколу, який зазвичай використовується загальнодоступними ланцюгами, тому безпека дуже низька і повинна бути гарантована покладаючись на Ethereum Надійність випуску даних та ефективність переходів станів. **

Протокол Arbitrum Rollup:

Низка контрактів, які визначають структуру блоку RBlock ланцюжка Rollup, метод продовження ланцюжка, випуск RBlock і процес режиму виклику. **Зверніть увагу, що згаданий тут зведений ланцюжок — це не облікова книга рівня 2, яку всі розуміють, а абстрактна «структура даних, подібна до ланцюга», незалежно створена Arbitrum One для реалізації механізму захисту від шахрайства. **

Один RBlock може містити результати кількох блоків L2, і дані також дуже різні.Його сутність даних RBlock зберігається в серії контрактів у RollupCore. Якщо виникне проблема з RBlock, валідатор кине виклик заявнику RBlock.

Валідатор:

Вузли перевірки Arbitrum фактично є спеціальною підмножиною повних вузлів рівня 2 і наразі мають доступ до білого списку.

Валідатор створює новий RBlock (зведений блок, також званий твердженням) на основі пакета транзакцій, надісланого секвенсором до контракту SequencerInbox,** і відстежує стан поточного ланцюжка зведених даних, а також оцінює транзакції, надіслані секвенсор Завдання з неправильними даними. **

Активний валідатор повинен заздалегідь закласти активи в ланцюжку ETH, іноді ми також називаємо його стейкером. Хоча вузли рівня 2, які не зобов’язуються, також можуть відстежувати динаміку роботи Rollup і надсилати користувачам аномальні сигнали тривоги, вони не можуть безпосередньо втручатися в дані про помилки, надіслані секвенсером у ланцюжку ETH.

виклик:

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

Період виклику:

Через оптимістичний характер OP Rollup після того, як кожен RBlock надсилається в ланцюжок, контракт не перевіряється активно, залишаючи період вікна для фальсифікатора верифікатора. **Це часове вікно є періодом виклику, який становить 1 тиждень в основній мережі Arbitrum One. Після завершення періоду виклику RBlock буде остаточно підтверджено, і відповідні повідомлення, передані з L2 на L1 у блоці ** (наприклад, операції зняття коштів, виконані через офіційний міст), можуть бути звільнені.

ArbOS, Geth, WAVM:

Віртуальна машина, яку використовує Arbitrum, називається AVM, яка включає Geth і ArbOS. **Geth є найбільш часто використовуваним клієнтським програмним забезпеченням в Ethereum, і Arbitrum вніс до нього легкі модифікації. **ArbOS відповідає за всі пов’язані з L2 спеціальні функції, такі як керування мережевими ресурсами, створення блоків L2, робота з EVM тощо. Ми розглядаємо поєднання обох як рідну AVM, яка є віртуальною машиною, яку використовує Arbitrum. WAVM є результатом компіляції коду AVM у Wasm. **У процесі виклику Arbitrum остання «одноетапна перевірка» перевіряє інструкцію WAVM. **

Тут ми можемо використати наступний малюнок, щоб представити зв’язок і робочий процес між зазначеними вище компонентами:

Життєвий цикл транзакції L2

Потік обробки транзакції L2 такий:

1. Користувач надсилає торгові інструкції секвенсору.

2. Сортувальник спочатку перевіряє транзакції, які потрібно обробити в цифрові підписи та інші дані, усуває недійсні транзакції та виконує сортування та обчислення.

3. Секвенсор надсилає квитанцію про транзакцію користувачеві (зазвичай дуже швидко), ** але це лише «попередня обробка», яку виконує секвенсор у ланцюжку ETH. Він знаходиться в стані Soft Finality і є ненадійний **. Але ті користувачі, які довіряють секвенсору (більшість користувачів), можуть бути оптимістично налаштовані, що транзакцію завершено і її не буде відкочено.

4. Сортувальник сильно стискає попередньо оброблені вихідні дані транзакції та інкапсулює їх у пакет.

**5. Час від часу (під впливом таких факторів, як обсяг даних і перевантаження ETH) секвенсор публікуватиме пакети транзакцій у контракті секвенсора «Вхідні» на L1. **На цьому етапі можна вважати, що транзакція має жорстку остаточність.

Контракт папки вхідних секвенсорів

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

Щоб зрозуміти це фізично, L2, який ми бачимо, — це лише проекція пакету в SequencerInbox, а джерелом світла є STF. Оскільки джерело світла STF не змінюється легко, форма тіні визначається лише пакетом, який діє як об’єкт.

**Контракт секвенсора «Вхідні» також називається швидким ящиком. Секвенсер спеціально надсилає до нього попередньо оброблені транзакції, і лише він може надсилати в нього дані. **Відповідна швидка скринька – це повільна скринька Delayer Inbox, її функції будуть описані в подальшому процесі.

Валідатор завжди відстежуватиме контракт SequencerInbox. **Щоразу, коли секвенсер випускає пакет до контракту, буде створено подію в ланцюжку. Після того, як валідатор прослухає цю подію, він завантажить пакетні дані та виконає їх Нарешті, надішліть RBlock контракту протоколу Rollup у ланцюжку ETH.

У бридж-контракті Arbitrum є параметр під назвою «акумулятор», який записує щойно надісланий пакет L2, а також кількість і інформацію про щойно отримані транзакції в повільній папці «Вхідні».

(Секвенсор постійно надсилає пакети до SequencerInbox)

• *

(Інформація про пакет, поле даних відповідає даним пакету, ця частина даних дуже велика, і знімок екрана відображається не повністю)

Контракт SequencerInbox виконує дві основні функції:

add Sequencer L2Batch From Origin(), секвенсор буде викликати цю функцію щоразу, щоб надсилати пакетні дані до контракту Sequencer Inox.

force Inclusion(), Ця функція може бути викликана будь-ким і використовується для реалізації транзакцій, стійких до цензури. Те, як ця функція набуває чинності, буде докладно пояснено пізніше, коли ми будемо говорити про контракт із затриманими вхідними.

Наведені вище дві функції викличуть bridge.enqueueSequencerMessage() для оновлення параметра накопичувача у контракті мосту.

Ціни на газ

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

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

Витрати, які несуть користувачі через використання ресурсів рівня 2, встановлюють ліміт газу, який можна обробляти за секунду, щоб забезпечити стабільну роботу системи (наразі Arbitrum One становить 7 мільйонів). Орієнтовні ціни на газ для L1 і L2 відстежуються та коригуються ArbOS, і наразі формули тут не описуватимуться.

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

Оптимістичний доказ шахрайства

Згадуючи вищесказане, L2 насправді є лише проекцією вхідного пакета транзакцій, надісланого сортувальником у швидкому вікні, тобто:

Входи транзакцій -> STF -> Виходи стану. Вхідні дані визначено, а STF залишається незмінним, тому вихідний результат також визначений.**Система захисту від шахрайства та протокол Arbitrum Rollup публікує корінь вихідного стану в L1 у формі RBlock (він же твердження), і це система оптимістичного доказу. **

На L1 є вхідні дані, опубліковані секвенсором, і вихідний статус, опублікований верифікатором. Давайте уважно розглянемо, чи потрібно публікувати в ланцюжку статус рівня 2?

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

Під час створення Rollup одна з основних ідей полягає в тому, щоб помістити більшу частину обчислень і зберігання на L2, щоб уникнути високої вартості L1. Це означає, що L1 не знає статус L2, це лише допомагає L2. Секвенсор публікує вхідні дані усіх транзакцій, але не несе відповідальності за обчислення стану L2.

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

У цей час у контракті Layer1 запитуватимуть: **Який ваш статус на Layer2 і як довести, що ви справді володієте активами, які ви заявляєте про передачу. У цей час користувач повинен надати відповідне підтвердження Merkle тощо. **

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

У так званому оптимістичному доказі контракт не перевіряє, чи правильний вихідний статус, поданий до L1, і оптимістично вважає, що все точно. **Система оптимістичного підтвердження припускає, що в будь-який час існує принаймні один чесний валідатор. Якщо станеться неправильний стан, його буде оскаржено через доказ шахрайства. **

Перевага цієї конструкції полягає в тому, що немає необхідності активно перевіряти кожен RBlock, виданий L1, щоб уникнути марної витрати газу. Фактично, для OPR нереалістично перевірити кожне твердження, оскільки кожен R-блок містить один або більше блоків L2, і кожну транзакцію потрібно повторно виконати на L1. Це нічим не відрізняється від виконання транзакцій L2 безпосередньо на L1, що втрачає значення розширення рівня 2.

У ZKR немає цієї проблеми, тому що ZK Proof є простим і потребує лише перевірки дуже маленького Proof.Немає необхідності фактично виконувати багато транзакцій, що відповідають Proof. Тому ЗКР працює не оптимістично.Кожного разу при звільненні статусу буде контракт Verfier для математичної перевірки.

**Хоча докази шахрайства не можуть бути такими короткими, як докази з нульовим знанням, Arbitrum використовує покроковий інтерактивний процес «багатораундовий спліт-одноетапний доказ». Зрештою, те, що потрібно підтвердити, — це лише одна віртуальна машина код операції, вартість відносно невелика. **

Протокол зведення

Давайте спочатку розглянемо, як працює протокол Rollup, який є точкою входу для ініціювання викликів і ініціювання доказів.

**Основним контрактом протоколу Rollup є RollupProxy.sol.**За умови забезпечення узгодженої структури даних використовується рідкісна структура подвійного агента.Один агент відповідає двом реалізаціям RollupUserLogic.sol і RollupAdminLogic.sol.В інструментах як-от сканування. Це ще не можна добре проаналізувати.

Існує також контракт **ChallengeManager.sol, який відповідає за керування викликами, і серія контрактів OneStepProver для визначення доказів шахрайства. **

(Джерело фото: офіційний сайт L2BEAT)

У RollupProxy записується ряд блоків RBlocks (так звані твердження), надісланих різними валідаторами, які є полями на малюнку нижче: зелений — підтверджено, синій — непідтверджено, жовтий — фальсифіковано.

**RBlock містить кінцевий стан після виконання одного або кількох блоків L2 з моменту останнього RBlock. **Ці RBlocks утворюють формальний ланцюжок зведення (зауважте, що сама книга L2 відрізняється). За оптимістичних обставин у цьому ланцюжку зведення не повинно бути розгалужень, оскільки розгалуження означає, що валідатор подав конфліктуючі блоки зведення.

Щоб запропонувати або погодитися з твердженням, верифікатор повинен спочатку зробити ставку певної суми ETH для твердження та стати Стейкером. Таким чином, коли виникає доказ оскарження/шахрайства, застава програшів буде втрачена.Це є економічною основою для забезпечення чесної поведінки верифікатора.

Синій блок № 111 у нижньому правому куті фігури з часом буде фальсифікований, оскільки його батьківський блок № 104 неправильний (жовтий).

**Крім того, верифікатор A запропонував зведений блок № 106, але B не погодився та оскаржив його. **

Після того, як B ініціює виклик, контракт ChallengeManager несе відповідальність за перевірку розподілу кроків виклику:

1. Сегментація — це процес, у якому обидві сторони по черзі взаємодіють.Одна сторона сегментує історичні дані, що містяться в певному блоці зведення, а інша сторона вказує, яка частина фрагмента даних є проблематичною. Процес, подібний до дихотомії (фактично N/K), який постійно та поступово звужує сферу.

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

3. Контракт ChallengeManager лише перевіряє, чи дійсні «фрагменти даних», створені після сегментації вихідних даних.

4. Коли претендент і оскаржений знайшли машинну інструкцію, яку потрібно оскаржити, претендент викликає oneStepProveution() і надсилає одноетапний доказ шахрайства, щоб довести, що існує проблема з результатом виконання цієї машинної інструкції. **

Одноетапний доказ

Одноетапний доказ є основою захисту Arbitrum від шахрайства. Давайте подивимося, що конкретно доводить одноетапний доказ.

Для цього потрібно спочатку зрозуміти WAVM, **Wasm Arbitrum Virtual Machine, яка є віртуальною машиною, скомпільованою за допомогою модуля ArbOS і основного модуля Geth (клієнт Ethereum). **Оскільки L2 повністю відрізняється від L1, оригінальне ядро Geth має бути злегка модифіковано та працювати з ArbOS.

Тому перехід стану на L2 фактично є спільною роботою ArbOS+Geth Core.

Клієнт вузла Arbitrum (секвенсор, валідатор, повний вузол тощо) компілює згадану вище програму обробки ArbOS+Geth Core у власний машинний код, який хост вузла може безпосередньо обробляти (для x86/ARM/PC/Mac тощо).

Якщо ви зміните цільову мову, отриману після компіляції, на Wasm, ви отримаєте WAVM, який використовується верифікатором під час генерації доказів шахрайства, а контракт для перевірки одноетапного доказу також імітує функції віртуальної машини WAVM.

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

Однак WASM працює трохи повільніше, ніж рідний машинний код, тому вузли/контракти Arbitrum використовуватимуть WAVM лише під час створення та перевірки доказів шахрайства.

**Після попередніх раундів інтерактивних підрозділів однокрокова перевірка нарешті підтверджує однокрокову інструкцію в наборі інструкцій WAVM. **

Як видно з наведеного нижче коду, OneStepProofEntry має спочатку визначити, до якої категорії належить код операції інструкції, яку потрібно перевірити, а потім викликати відповідну перевірку, наприклад Mem, Math тощо, щоб передати однокрокову інструкцію в договір перевірки.

Остаточний результат після Hash буде повернено до ChallengeManager. Якщо хеш не узгоджується з хешем після операції інструкції, записаної в блоці Rollup Block, виклик успішний. Якщо вони узгоджуються, це означає, що немає проблем із результатом виконання цієї команди, записаним у блоці зведення, і виклик не вдався.

У наступній статті ми проаналізуємо Arbitrum і навіть контрактний модуль, який обробляє міжланцюгові повідомлення/функції перемикання між Layer2 і Layer1, і далі пояснимо, як справжній Layer2 має досягати стійкості до цензури.