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

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

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

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

Короткий опис секвенсера Rollup

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

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

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

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

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

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

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

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

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

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

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

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

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

Секвенсор:

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

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

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

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

Протокол Arbitrum Rollup:

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

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

Валідатор:

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

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

Активні валідатори вимагають попереднього стейкінгу активів у ланцюжку ETH, які іноді називають стейкерами. Хоча вузли рівня2, які не здійснюють стейкінг, також можуть відстежувати динаміку роботи зведень, надсилати аномальні тривоги користувачам тощо, вони не можуть безпосередньо втручатися в дані про помилки, надіслані секвенсором у ланцюжку 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 тощо), секвенсор публікуватиме пакети транзакцій у контракті Sequencer Inbox на L1. На цьому етапі транзакцію можна вважати такою, що має жорстку завершеність.

Контракт на поштову скриньку секвенсера

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

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

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

Валідатор завжди слухатиме контракт SequencerInbox, і щоразу, коли секвенсер випускає пакет до контракту, він генеруватиме ончейн-подію, і після того, як валідатор почує цю подію, він завантажить пакетні дані, а після локального виконання він випустить RBlock до контракту протоколу Rollup у ланцюжку ETH.

Бридж-контракт Arbitrum має параметр під назвою accumulator, який фіксуватиме кількість щойно поданих партій L2, а також кількість щойно отриманих транзакцій та інформацію в повільній поштовій скриньці.

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

додати секвенсер L2Batch From Origin(), який секвенсор викликає щоразу, щоб надіслати пакетні дані до контракту Sequencer Inox.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одноетапна перевірка

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

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

Таким чином, переходи станів на L2 насправді є загальною рисою ArbOS+Geth Core.

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

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

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

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

Після попередніх раундів сегментації взаємодії, однокроковим доказом в кінцевому підсумку виявилася однокрокова інструкція в наборі інструкцій WAVM.

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

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

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