Глибоке занурення на захист від помилок, частина 1: MIPS.sol

У першій частині серії поглибленого вивчення Fault Proof з Coinbase розглядається смарт-контракт FPVM MIPS.sol та те, як він працює у системі Fault Proof System OP Stack.

Серія Fault Proof Deep-Dive – це результат співпраці команди Coinbase Blockchain Security (BlockSec) та OP Labs, метою якого є надання детальної інформації про всі основні компоненти Fault Proofs. Ділячись цією інформацією, ми сподіваємося спонукати інших дізнатися більше про архітектуру та технічні аспекти Fault Proofs. Разом ми можемо рухатися до децентралізованого майбутнього блокчейнів OP Stack L2.

У цьому повідомленні блогу ми розглянемо смарт-контракт MIPS.sol для стійкої до відмови віртуальної машини (FPVM).

Що таке MIPS.sol?

Смарт-контракт MIPS.sol - це ончейн-реалізація віртуальної машини (ВМ), яка включає 32-бітну архітектуру набору інструкцій MIPS III (ISA) з прямим порядком байтів. Цей смарт-контракт є аналогом реалізації MIPSEVM golang поза ланцюжком тієї ж ISA. Водночас реалізації ончейн та офчейн віртуальних машин складають Cannon, першу FPVM OP.

Cannon - це екземпляр FPVM, який використовується як частина гри з усунення несправностей для оптимістичних об'єднаних блокчейнів L2, що використовують стек OP. Сама гра зі спорів є модульною, що дозволяє використовувати будь-яку FPVM; однак Cannon зараз є єдиною реалізованою FPVM і, отже, буде використовуватися у всіх суперечках.

Потік управління захистом від збоїв

Зробивши крок назад, коротко зосередимося на тому, де знаходиться контракт MIPS.sol в процесі Fault Proof.

На наведеній вище діаграмі, відтвореній на основі  відео Fault Proof Walkthrough  від Clabby, бачимо, що контракт MIPS.sol взаємодіє з двома іншими контрактами: FaultDisputeGame.sol і PreimageOracle.sol. FaultDisputeGame.sol - це розгорнутий екземпляр гри Fault Dispute Game для активної суперечки. PreimageOracle.sol - це розгорнутий екземпляр Oracle попереднього образу, який зберігатиме попередні зображення для всіх ігор-диспутів, що використовують одну і ту ж FPVM. Отже, у нашому випадку існує один контракт PreimageOracle.sol для всіх ігор, які використовують MIPS.sol як FPVM.

Контракт MIPS.sol викликається запущеним екземпляром спірної гри і викликається лише тоді, коли спірна гра досягає кінцевого вузла в дереві переходу станів, який оспорюється. Листовий вузол є однією інструкцією MIPS (у випадку, якщо ми використовуємо Cannon як FPVM), яку потім можна запустити в ланцюжку. Враховуючи попередній стан, який є раніше узгодженим станом L2 до цієї інструкції, та стан інструкції для виконання у контракті MIPS.sol, гра з дозволу помилок може визначити справжній стан після. Цей справжній стан публікації потім буде використовуватися для вирішення гри зі спором про несправність шляхом порівняння стану оспорюваної публікації на листовому вузлі зі станом публікації, запропонованим опонентом в екземплярі гри зі спором.

Потік керування смарт-контрактом

У смарт-контракті MIPS.sol є єдина точка входу: функція Step(). Це функція, що викликається запущеною грою у суперечці, яка виконує одну інструкцію MIPS у ланцюжку. На високому рівні будуть виконані такі операції:

  1. Вхідні дані про стан виконання віртуальної машини аналізуються та завантажуються на згадку. Ці дані генеруються аналогом Cannon golang, який учасники гри запускають поза ланцюжком через OP-Challenger.

  2. Введення перевірки пам'яті зчитується та перевіряється. Цей доказ використання пам'яті вказує на місце в пам'яті, звідки слід завантажити та запустити наступну інструкцію MIPS.

  3. Виконується наступна інструкція MIPS. Більшість логіки контракту MIPS.sol відповідає за виконання інструкції MIPS відповідно до специфікації MIPS III. При обробці інструкцій MIPS єдиною інструкцією, яка не відповідає строгому специфікації, є інструкція SYSCALL (системний виклик). p align="justify"> Поведінка системних викликів унікальна для операційної системи, і у випадку MIPS.sol системні виклики, які можна здійснити, становлять лише частину від загальної кількості системних викликів. Основна мета системних викликів – обробка читання з контракту PreimageOracle.sol та імітація запису до контракту.

  4. Результати команди можуть бути записані назад у регістр або пам'ять. У разі запису на згадку другий доказ пам'яті буде надано як вхідні дані гри-спору. Другий доказ пам'яті повинен збігатися з місцем у пам'яті, в яке очікується запис, і смарт-контракт MIPS.sol використовуватиме нове значення та доказ пам'яті для обчислення нового кореня Меркла у пам'яті.

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

Стан контракту MIPS.sol

Як згадувалося раніше, контракт MIPS.sol взаємодіє з двома іншими смарт-контрактами: FaultDisputeGame.sol та PreimageOracle.sol. Контракт FaultDisputeGame.sol надає поточний стан виконання віртуальної машини та до двох доказів пам'яті. Контракт PreimageOracle.sol пропонує попередні зображення, які MIPS.sol може використовувати для визначення справжнього стану L2. Вміст, отриманий у попередньому зображенні, може включати дані як з L1, так і з L2, які можуть бути заголовками блоків, транзакціями, квитанціями, станом контракту.

Разом ці два контракти надають всю необхідну інформацію, необхідну для виконання однієї інструкції MIPS. Контракт MIPS.sol не зберігає в пам'яті жодної інформації щодо виконання інструкції. Таким чином, контракт може використовуватись у будь-якій грі з вирішення спорів без необхідності скидання будь-яких значень. Отже, контракт MIPS.sol гарантує, що обчислений корінь Меркла на основі наданих доказів пам'яті дорівнює кореню Меркла у стані виконання віртуальної машини. В іншому випадку контракт FaultDisputeGame.sol повинен забезпечити коректність наданої інформації та дій учасника спірної гри.

Документація для MIPS.sol

На цьому ми закінчуємо детальне вивчення смарт-контракту MIPS.sol. На додаток до цього повідомлення в блозі Coinbase створили докладну документацію, в якій докладно описано кожну функцію смарт-контракту, перелічені інструкції MIPS, що підтримуються FPVM, та багато іншого. Перевірте це на сайті  Fault Proofs – MIPS.sol | Документи з оптимізму .

Переклад оригінальної статті від 15 лютого 2024 року

Subscribe to BanklessUA
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.