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

Огляд Rollup Sequencer

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

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

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

(Джерело: Мережа БНБ)

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

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

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

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

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

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

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

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

(Метод роботи ZK Rollup)

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

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

Основні контракти:

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

Секвенсор:

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

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

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

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

Зведений протокол Arbitrum:

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

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

Валідатор:

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

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

Активному валідатору необхідно заздалегідь поставити активи на ланцюг ETH. Іноді ми також називаємо це Staker. Незважаючи на те, що вузли рівня 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. На цьому етапі можна вважати, що транзакція має жорстку остаточність.

Договір папки вхідних секвенсорів

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

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

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

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

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

（Секвенсор безперервно надсилає пакети до вхідної скриньки секвенсора）

（Конкретна інформація про партію; поле даних відповідає даним партії. Розмір цієї частини даних дуже великий, і знімок екрана відображається не повністю.）

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

додати Sequencer L2Batch From Origin()

Секвенсор буде викликати цю функцію кожного разу, щоб надіслати пакетні дані до контракту Sequencer Inox.

примусове включення()

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

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

Ціноутворення на газ

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

Витрати на публікацію даних, пов’язані з використанням ресурсів рівня 1

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

Витрати, понесені користувачами, які займають ресурси рівня 2

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

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

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

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

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

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

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

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

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

У цей час контракт рівня 1 запитає: який ваш статус на рівні 2 і як довести, що ви справді володієте активами, які ви заявляєте про передачу? У цей час користувач повинен надати відповідне підтвердження Merkle тощо.

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

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

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

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

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

Зведений протокол

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

Основним контрактом протоколу Rollup є RollupProxy.sol, який використовує рідкісну структуру подвійного агента, гарантуючи узгодженість структури даних. Один агент відповідає двом реалізаціям RollupUserLogic.sol і RollupAdminLogic.sol, які не можуть добре проаналізувати такі інструменти, як Scan.

Крім того, контракт ChallengeManager.sol відповідає за керування викликами, а контракти серії OneStepProver використовуються для визначення доказів шахрайства.

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

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

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

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

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

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

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

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

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

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

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

Однокроковий доказ

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

Для цього потрібно спочатку зрозуміти WAVM. Віртуальна машина Wasm Arbitrum — це віртуальна машина, скомпільована за допомогою модуля 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. Якщо хеш не узгоджується з хешем після операції інструкції, записаної в блоці зведення, виклик успішний. Якщо вони узгоджені, це означає, що немає проблем із результатом виконання цієї інструкції, записаним у блоці зведення, і виклик не вдався.

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

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

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