Як відомо, докази шахрайства широко використовуються в технічному рішенні у просторі блокчейну. Вони виникли в спільноті Ethereum і були прийняті відомими рішеннями Ethereum Layer 2, такими як Arbitrum та Optimism. Після зростання екосистеми Bitcoin у 2023 році Робін Лінус запропонував рішення під назвою BitVM, яке, на основі існуючих технологій Bitcoin, таких як Taproot, зосереджується на доказах шахрайства та надає нову модель безпеки для Bitcoin Layer 2 або мостів.

BitVM випустив кілька теоретичних версій, починаючи з ранньої версії BitVM0, яка використовувала логічні ворота як примітиви, до пізніших версій, таких як BitVM2, яка акцентується на доказах шахрайства ZK та верифікаційних колах Грота16. Технічні шляхи реалізації, пов'язані з BitVM, постійно еволюціонують та дозрівають, привертаючи увагу багатьох фахівців галузі. Проекти, такі як Bitlayer, Citrea, BOB, Fiamma та Goat Network, всі використовують BitVM як одну зі своїх основних технологій, впроваджуючи різні версії на основі цієї основи.

З урахуванням рідкісності та складності публічно доступних пояснень про BitVM, ми запустили серію статей, спрямованих на популяризацію знань про BitVM. З урахуванням глибокого зв'язку між BitVM та доказами шахрайства, ця стаття буде акцентуватися на доказах шахрайства та ZK доказах шахрайства, використовуючи просту та зрозумілу мову для пояснення цих понять.

(Принцип інтерактивного механізму доказу шахрайства Принципу Оптимізму)

OutputRoot та StateRoot

Optimism - відомий проект Optimistic Rollup, інфраструктура якого складається з послідовника (основні модулі включають op-node, op-geth, op-batcher та op-proposer) та смарт-контрактів на ланцюгу Ethereum.

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

Якщо послідовник завантажує неправильний хеш набору стану на Ethereum, обчислений вами локально хеш буде відмінним. У цьому випадку ви можете висунути виклик через систему доказу шахрайства. На підставі рішення система або накласти обмеження або штрафи на послідовника, або не вживати жодних заходів.

При згадуванні терміну «state set» блокчейни на основі EVM зазвичай використовують структуру даних, схожу на дерево Меркла, для запису набору стану, яку називають Деревом стану світу. Після виконання транзакції стан певних облікових записів зміниться, а Дерево стану світу також зміниться, що призведе до зміни його кінцевого хешу. Ethereum посилається на кінцевий хеш Дерева стану світу як StateRoot, який представляє зміни в наборі стану.

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

Система обліку та структура даних оптимізму в цілому відповідають системі Ethereum, також використовують поле StateRoot для представлення змін у наборі стану. OP послідовник періодично завантажує ключове поле, назване OutputRoot, на Ethereum, яке обчислюється на основі StateRoot та ще двох інших полів.

Повертаючись до початкового питання, коли ви запускаєте клієнт вузла OP та обчислюєте StateRoot та поточний OutputRoot локально, якщо ви виявите, що результати, які ви обчислили, не відповідають тим, які були завантажені послідовником OP, ви можете ініціювати доказ шахрайства. Таким чином, який конкретно механізм за цим стоїть? Нижче ми послідовно представимо перевірку стану віртуальної машини MIPS та інтерактивні докази шахрайства.

Віртуальна машина MIPS та дерево Меркля пам'яті

Як вже зазначалося раніше, припустимо, ви виявили, що OutputRoot, наданий послідовником OP, є невірним, і ви хочете розпочати «виклик». Процес виклику передбачає завершення серії взаємодій on-chain, після чого відповідні розумні контракти визначать, чи послідовник OP завантажив невірний OutputRoot.

Для перевірки правильності OutputRoot on-chain за допомогою смарт-контрактів найпростішим методом було б реалізувати клієнт OP-вузла на ланцюгу Ethereum, використовуючи ті ж вхідні параметри, що й OP-послідовник, виконуючи ту саму програму і перевіряючи, чи відповідає розрахований результат. Цей підхід називається програмою доказу шахрайства. Хоча він досить легкий для реалізації офлайн, його дуже важко виконати на ланцюгу Ethereum через дві проблеми:

1. Розумні контракти на Ethereum не можуть автоматично отримати вхідні параметри, необхідні для доказу шахрайства.

2. Ліміт блоку газу Ethereum обмежений, і він не підтримує високорівневі складні обчислювальні завдання. Тому ми не можемо повністю реалізувати клієнт вузла OP on-chain.

Перший питання еквівалентне вимозі від on-chain смарт-контракту читати off-chain дані, що може бути вирішено за допомогою рішення, подібного до оракула. ОП розгорнув контракт PreimageOracle на ланцюгу Ethereum, і пов'язані з доказом шахрайства контракти можуть читати необхідні дані з цього контракту. Теоретично, будь-хто може завантажити дані до цього контракту, але система доказу шахрайства ОП має спосіб перевірити, чи потрібні дані, хоча цей процес тут не розглядатиметься, оскільки це не є ключовим для основної теми цієї статті.

Для другої проблеми команда розробників OP написала віртуальну машину MIPS на Solidity для виконання деяких функцій клієнта вузла OP, які є достатніми для системи доказу шахрайства. MIPS є загальною архітектурою набору команд процесора, а код OP послідовника написаний на вищорівневих мовах програмування, таких як Golang/Rust. Ми можемо компілювати програми Golang/Rust в програми MIPS та обробляти їх через віртуальну машину MIPS на ланцюжку Ethereum.

Команда розробників OP написала спрощену програму на Golang для захисту від шахрайства, яка по суті імітує модулі в вузлі OP, які виконують транзакції, генерують блоки та виробляють OutputRoot. Однак ця спрощена програма все одно не може «виконати повністю». Іншими словами, кожен блок ОП містить безліч транзакцій. Після обробки цього пакету транзакцій генерується OutputRoot. Хоча ви знаєте, що OutputRoot блоку якої висоти неправильний, було б нереалістично запустити всі транзакції в цьому блоці в ланцюжку, щоб довести, що відповідний OutputRoot неправильний. Крім того, під час виконання кожної транзакції послідовно обробляється серія кодів операцій MIPS. Було б недоцільно запускати всю цю серію операційних кодів на віртуальній машині MIPS, реалізованої в ончейн-контракті, оскільки обчислювальні витрати та споживання газу були б занадто великими.

(Принцип роботи набору інструкцій MIPS)

Для вирішення цієї проблеми команда Optimism розробила інтерактивну систему доказу шахрайства, спрямовану на глибокий аналіз потоку обробки транзакцій OP. Спостерігаючи весь процес обчислення OutputRoot, система визначає, на якому MIPS опкоді віртуальна машина MIPS OP-послідовника допустила помилку. Якщо помилка підтверджується, можна зробити висновок, що OutputRoot, наданий послідовником, є недійсним.

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

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

З погляду реалізації коду, розумні контракти на ланцюгу Ethereum, що стосуються доказу шахрайства, завершать останній процес виконання опкодів MIPS через функцію під назвою Step:

Параметри вищезазначеної функції, _stateData та _proof, представляють залежні елементи даних для виконання одного опкоду MIPS, такі як регістральний стан віртуальної машини MIPS, хеш стану пам'яті тощо. Діаграма показана нижче:

Ми можем ввести ці параметри оточення віртуальної машини MIPS через _stateData та _proof, виконати одну MIPS інструкцію on-chain та отримати авторитетний результат. Якщо авторитетний результат, отриманий on-chain, відрізняється від результату, надісланого послідовником, це вказує на те, що послідовник є зловмисником.

Загалом ми звертаємося до хешу _stateData як до statehash, який можна приблизно розуміти як хеш всього стану віртуальної машини MIPS. Серед кількох полів у _stateData memRoot є найбільш винахідливим рішенням. Як ми знаємо, під час виконання програми використовується велика кількість пам'яті, і ЦП взаємодіє з даними в певних адресах пам'яті за допомогою зчитування та запису. Тому, коли ми виконуємо опкод MIPS on-chain через функцію VM.Step, нам потрібно надати дані з певних адрес пам'яті у віртуальній машині MIPS.

OP використовує архітектуру 32-біт для віртуальної машини MIPS, і її пам'ять містить 2^27 адрес, які можуть бути організовані в 28-рівневе бінарне дерево Меркля. Листові вузли на найнижчому рівні нумеруються 2^27, при цьому кожен листок записує дані з певної адреси пам'яті віртуальної машини. Хеш, розрахований з усіх даних в листях, - це memRoot. На схемі нижче показана структура дерева Меркля, яке записує дані пам'яті віртуальної машини MIPS:

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

Інтерактивний доказ шахрайства

У попередньому розділі ми вирішили друге питання, завершивши виконання опкодів MIPS на ланцюжку та верифікацію стану віртуальної машини. Але як можуть челенджер та секвенсор точно визначити спірний інструкційний опкод MIPS?

Багато людей, можливо, читали прості пояснення інтерактивних доказів шахрайства в Інтернеті і чули про підхід бінарного пошуку, що стоїть за ними. Команда OP розробила протокол під назвою Гра суперечок про несправності (FDG). Протокол FDG включає дві ролі: викликача та захисника.

Якщо ми виявимо, що введений на ланцюжку OutputRoot від послідовника є неправильним, ми можемо виступити як викликач у FDG, а послідовник виступатиме як захисник. Щоб допомогти знайти опкод MIPS, який потрібно обробити на ланцюжку, протокол FDG вимагає від учасників локально сконструювати дерево Меркля, яке називається Графом гри, структура якого виглядає наступним чином:

Ми бачимо, що GameTree досить складний, з ієрархічною вкладеною структурою, що складається з дерева першого рівня та піддерев другого рівня. Іншими словами, листові вузли дерева першого рівня містять піддерево.

Як вже зазначалося раніше, кожний блок, створений секвенсором, містить OutputRoot, а листові вузли дерева першого рівня в GameTree представляють OutputRoots різних блоків. Викликач і захисник повинні взаємодіяти в Мерклівському дереві, сформованому OutputRoots, щоб визначити, чий OutputRoot блоку є предметом суперечки.

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

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

На цей момент ми завершили весь процес інтерактивного доказу шахрайства. Щоб узагальнити, дві основні механізми інтерактивного доказу шахрайства:

1. FDG (Fault Dispute Game) спочатку визначає опкод MIPS, який потрібно виконати on-chain, разом із інформацією про стан ВМ на той момент;

2. Віртуальна машина MIPS, реалізована на ланцюгу Ethereum, виконує опкод, видаючи кінцевий результат.

ZK доказ шахрайства

ZK Доказ Шахрайства Як ми бачимо, традиційний підхід до доказу шахрайства включає дуже складні взаємодії, вимагаючи кількох раундів взаємодії в процесі FDG та повторення окремих інструкцій на ланцюжку. Однак у цьому рішенні є кілька викликів:

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

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

На діаграмі, Викликач refers to the party that raises the challenge, and the Захисникце OP послідовник. У нормальних умовах OP послідовник генерує блоки на основі отриманих транзакцій та надсилає ствердження стану різних блоків в Ethereum. Ці ствердження стану можуть бути просто сприйняті як хеш-значення блоків. Челенджер може викликати на основі хешу блоку. Після прийняття виклику Захисник генерує доказ ZK, щоб продемонструвати, що результати генерації блоку є вірними. На діаграмі, БонсайНасправді це інструмент для генерації доказів ZK. Порівняно з інтерактивними доказами шахрайства, найбільшою перевагою доказу шахрайства ZK є те, що він замінює кілька раундів взаємодії одним раундом генерації доказу ZK та верифікації on-chain. Це значно зберігає час та зменшує витрати на газ. Крім того, на відміну від ZK Rollups, OP Rollups на основі доказів шахрайства ZK не потребують генерації доказів кожного разу, коли виробляється блок. Замість цього вони тимчасово генерують доказ ZK при виклику, що також зменшує обчислювальні витрати для вузлів Rollup.

Концепцію ZK Fraud Proof також використовує BitVM2. Проекти, які використовують BitVM2, такі як Bitlayer, Goat Network, ZKM та Fiama, реалізують програму верифікації ZK Proof через біткоїн-скрипти, що значно спрощує розмір програм, які потрібно внести на ланцюжок. У зв'язку з обмеженнями простору, ця стаття не буде детально розглядати цю тему. Слідкуйте за нашою майбутньою статтею про BitVM2, щоб отримати глибше розуміння його шляху впровадження!

Disclaimer:

1. Ця стаття відтворена з [ GodRealmX], авторські права належать оригінальному автору [Шов та Ноа] , якщо у вас є будь-які зауваження щодо репринту, будь ласка, зв'яжіться з Gate Learnкоманда, і команда якнайшвидше вирішить це відповідно до відповідних процедур.

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

3. Інші мовні версії статті перекладені командою Gate Learn та не згадуються вGate.io, перекладена стаття не може бути відтворена, поширена або плагіатована.