Переслати оригінальний заголовок:

У цій статті представлена технічна інтерпретація Arbitrum One Ло Бенбеном (罗奔奔), колишнім технічним амбасадором Arbitrum і колишнім співзасновником Goplus Security, аудиторської компанії з автоматизації смарт-контрактів.

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

Введення до Rollup Sequencer

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

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

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

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

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

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

Хоча послідовник, як центральна вісь системи, може мати централізований відтінок, у зрілих рішеннях Rollup централізований послідовник може займатися лише м'якими зловісними діями, такими як цензура транзакцій або зловісні аварії. Проте в ідеальних рішеннях Rollup є відповідні заходи для обмеження таких дій (такі як примусові вилучення або сортування доказів як антицензурні механізми).

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

Щоб запобігти зловживанню роллап-послідовниками, існують два типи методів перевірки стану: Доказ шахрайства та Доказ дійсності. Рішення роллапу, що використовують Доказ шахрайства, називають Оптимістичний Роллап (OPR), тоді як ті, що використовують Доказ дійсності, часто називаються ZK Роллап (Роллап з нульовими доказами, ZKR), а не Роллап дійсності, через історичне навантаження.

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

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

(Метод операції оптимістичного ролапу)

(Метод операції ZK Rollup)

Ця стаття надасть детальне введення в провідний проект у оптимістичному роллапі — Арбітрум Ван, охоплюючи всі аспекти системи. Після уважного прочитання ви здобудете глибоке розуміння Арбітруму та Оптимістичного Роллапу (OPR).

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

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

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

Послідовник:

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

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

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

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

Протокол Arbitrum Rollup:

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

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

Валідатори:

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

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

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

Виклик:

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

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

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

ArbOS, Geth, WAVM:

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

Тут ми можемо представити відносини та робочі процеси між різними компонентами за допомогою діаграми нижче:

Цикл життя транзакції L2

Потік обробки транзакції L2 виглядає наступним чином:

1. Користувач надсилає інструкції щодо транзакції послідовнику.
2. Послідовник спочатку перевіряє дані, включаючи цифрові підписи, транзакції, які будуть оброблені, відфільтровує недійсні транзакції, а потім упорядковує та обчислює їх.
3. Секвенціонер надсилає користувачеві квитанцію про транзакцію (зазвичай дуже швидко), але це лише «попередній обробки», що робить секвенціонер на ланцюгу Ethereum, і вона перебуває в стані м'якої остаточності і не є надійною. Однак для користувачів, які довіряють секвенціонеру (більшість користувачів), вони можуть оптимістично припускати, що транзакція була завершена і не буде скасована.
4. Послідовник інкапсулює попередньо оброблені дані операцій в партію після їх високої стискаючої обробки.
5. На регулярних інтервалах (під впливом таких факторів, як обсяг даних та затори в Ethereum) послідовник публікує пакет транзакцій на контракті вхідної скриньки послідовника на L1. На цей момент можна вважати, що транзакція має тверду завершеність.

Контракт для скриньки послідовника

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

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

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

Валідатори будуть постійно контролювати контракт Sequencer Inbox. Кожного разу, коли послідовник публікує партію у цей контракт, спрацьовує подія on-chain. Після виявлення цієї події валідатор завантажить дані партії, виконає їх локально, а потім опублікує RBlock на контракт протоколу Rollup на ланцюгу Ethereum.

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

(Послідовник безперервно подає партії в SequencerInbox)

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

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

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

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

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

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

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

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

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

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

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

Подивившись на попередній текст, стає очевидним, що Layer2 (L2) фактично є лише проекцією пакетів введення транзакцій, надісланих послідовником в папку послідовника:

Входи транзакції -> Функція переходу стану (STF) -> Вихід стану

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

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

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

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

На цьому етапі контракт Layer1 запитає: який ваш стан на Layer2 і як ви доводите, що справді володієте активами, які ви претендуєте на передачу? На цьому етапі користувачам потрібно надати відповідні Докази Меркла тощо.

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

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

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

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

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

Протокол Rollup

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

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

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

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

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

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

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

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

Додатково, Валідатор A запропонував Rollup Блок 106, з яким не погоджується Валідатор B і викликає на виклик.

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

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

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

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

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

Однокрокове підтвердження

Однокрокове підтвердження є основою всього доказу шахрайства 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 для імітації віртуальної машини VM, яка може обробляти певний набір наборів інструкцій, а WASM легко реалізувати імітацію в контракті.

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

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

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

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

Відмова:

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