Серія Layer2 Proof (Частина 1) — OP Stack Fraud Proof: проблеми, рішення та інновації

Огляд

Рішення Layer 2 відкривають перспективи для усунення обмежень масштабованості Layer 1. У серії розглядаються L2 proof-рішення з акцентом на fraud proof-механізми. Fraud proof-системи — це криптографічні механізми для перевірки транзакцій або обчислень у блокчейні, які забезпечують цілісність і безпеку операцій розподіленого реєстру.

Короткий огляд workflow Optimistic Rollup

Workflow Optimistic Rollup складається із семи основних етапів, що формують pipeline перевірки транзакцій. Користувачі ініціюють транзакції в Layer 2, надсилаючи їх до L2 sequencer. Далі L2 sequencer виконує транзакції на копії ланцюга L2 та створює новий state root, який відображає оновлений стан реєстру.

Після виконання sequencer передає початкові транзакції та новий state root у блокчейн Layer 1. Після отримання L1 smart contract відкриває challenge window, під час якого будь-який учасник блокчейну може оскаржити валідність транзакцій або результатів виконання, що надані L2 sequencer. Challenge-фаза є критичною для безпеки системи та запобігання зловмисній активності.

Після завершення challenge window блокчейн Layer 1 фіналізує запис виконання L2. Якщо під час оскарження доведено недобросовісність sequencer, застосовують санкції, а state root перераховують для коректності й відновлення цілісності системи.

Чому proving-механізм критично важливий для безпеки L2

Fraud proof-механізм і система оскарження є ключовими для зниження ризику недобросовісної поведінки sequencer. Криптографічні proof дозволяють будь-якому учаснику блокчейну L1 незалежно перевірити коректність rollup-транзакцій і state root без повного повторного виконання всієї історії транзакцій.

У протоколі Optimism передбачено розширене challenge window, коли учасники — користувачі та незалежні верифікатори — можуть перевіряти коректність виконання та state root. Такий тривалий період забезпечує спільноті час для ідентифікації й оскарження потенційно шахрайських submissions, формуючи модель безпеки на основі економічних стимулів і криптографічної перевірки, а не довіри до одного учасника.

Fraud Proof vs Validity Proof

У блокчейн-екосистемі існують дві категорії proof-рішень з різними принципами роботи та компромісами. Validity proof-системи вимагають, щоб sequencer разом із результатами виконання подавав у Layer 1 криптографічні validity proof. Це дає змогу будь-якому учаснику мережі Layer 1 негайно перевірити коректність виконання без повторного запуску транзакцій у ланцюзі L2, хоча такі системи потребують складної математики й zero-knowledge proof.

Fraud proof-системи, або fault proof, працюють за іншим принципом. Вони передбачають добросовісність sequencer за замовчуванням, а правильність гарантують через механізм оскарження. В такій моделі учасники мають час для оскарження потенційно шахрайських submissions, і тягар доказу переходить від sequencer до challenger, що може бути ефективніше при переважно добросовісних submissions.

Fraud proof-рішення

Fraud proof-реалізації поділяються на два основних підходи: неінтерактивні та інтерактивні рішення, кожне зі своїми архітектурними особливостями й наслідками для продуктивності.

Вступ до неінтерактивних fraud proof

Неінтерактивні fraud proof працюють шляхом повторного виконання транзакцій з L2 на L1. Це потребує потужної інфраструктури для запуску L2-транзакцій у середовищі L1 і перевірки змін стану L2 через verification layer L1. Основна складність неінтерактивних fraud proof — повторне виконання транзакцій з L2 на L1 і вирішення проблем несумісності стану між L2 та L1 для коректної перевірки.

Optimism Virtual Machine (OVM v1)

Для вирішення проблеми сумісності стану у неінтерактивних fraud proof протокол Optimism впровадив низку складних технік. L2 періодично створює state commitments, що генерують криптографічні докази всього стану L2. Доступність даних забезпечується, коли валідатори L1 підтверджують наявність і доступність даних у ланцюзі L1. Верифікація виконання відбувається через повторне виконання транзакцій на L1 із використанням даних L2 у контексті L2. Для взаємодії між шарами впроваджено cross-chain communication. Добре продумані incentive-механізми стимулюють добросовісну поведінку учасників.

Головна інновація OVM — створення «контейнера», що дозволяє виконання на L1 бути ідентичним запуску на L2. Це реалізовано через preload стану акаунтів, підготовку L2-акаунтів для виконання на L1; модифікацію EVM bytecode щодо доступу до storage і стану; деплой смарт-контрактів на L1, які змінюють байт-код для доступу до зовнішніх даних; і зміни компілятора Solidity для генерації OVM bytecode замість стандартного EVM bytecode.

Скорочення OVM

Підхід OVM має низку суттєвих недоліків. Виникає складність через зміни компілятора контракту, що змушує розробників працювати з нестандартним байт-кодом. Збільшення розміру коду спричинено заміною opcode на виклики функцій, що додає команди й підвищує вартість деплойменту. Споживання gas зростає, оскільки виклики функцій витрачають більше газу, ніж одиничні opcode, тому транзакції OVM дорожчі. Продуктивність обмежується недостатньою оптимізацією OVM, що створює вузькі місця у процесі транзакцій.

Вступ до інтерактивних fraud proof Optimism

Інтерактивні fraud proof — це новий підхід до fraud proof-механізмів, що використовують протокол взаємодії між defender і challenger для перевірки коректності переходу стану. Такий підхід дозволяє сторонам зосередити ресурси на частинах переходу стану з розбіжностями, а не виконувати всі транзакції.

Поточна реалізація Optimism, проект Cannon, орієнтована на верифікацію через одну MIPS-інструкцію на L1, що суттєво знижує обчислювальні витрати в ончейні.

Огляд Cannon

Проект Cannon має амбітні цілі. Він усуває модифікації контрактів на рівні opcode, уникаючи складних EVM-on-EVM-сценаріїв. Рішення надає спрощений доступ до стану L2 й скорочує витрати на ончейн-верифікацію fraud proof.

Cannon реалізує ці цілі через низку функцій. Єдиний доступ до стану впроваджено через preimage oracle — механізм для доступу до Layer 2 через хеш-ключі. Замість повторного виконання на рівні контракту Cannon використовує Geth-level replay, що ближче до клієнтської реалізації. Ончейн-верифікація оптимізована для виконання лише однієї MIPS-інструкції, що суттєво скорочує навантаження. Op-program служить містком для доступу та генерації preimage-даних, а dispute game дозволяє defender і challenger спільно ідентифікувати проблемні інструкції.

Процес Cannon

Архітектура Cannon включає ключові компоненти, що діють узгоджено. Op-program — це клієнт-серверна реалізація доступу до preimage-даних, де клієнт op-program компілюється у MIPS-інструкції, а сервер відповідає за запити й отримання preimage-даних. Cannon — це емулятор MIPS, що виконує MIPS-інструкції, містить mipsevm і ончейн-смарт-контракти. MIPS.sol реалізує інтерпретатор ончейн MIPS-інструкцій, а PreimageOracle.sol обслуговує preimage-запити з MIPS.sol.

Workflow працює так: клієнт op-program на MIPS завантажується в емулятор Cannon MIPS, який створює початковий стан fraud proof-процесу. Виконання стартує, кроки виконуються у mipsevm, записується доступ і зберігаються preimage-дані. Dispute game починається, коли challenger знаходить розбіжності між зміною стану L2 rollup і записом на L1. Defender і challenger застосовують бінарний пошук для знаходження інструкції, яка породжує різні стани. Матеріали fraud proof готують і подають у MIPS.sol для ончейн-верифікації.

Виклики інтерактивних fraud proof Optimism

Проект Cannon стикається з важливими викликами. Вибір MIPS-інструкцій обумовлений підтримкою Golang, простотою реалізації та архітектурою, але спеціалізований набір створює бар’єр для навчання. Потенційні експлойти Golang runtime — питання безпеки; Cannon пропатчив частину функцій, зокрема вимкнув garbage collection, що може спричинити out-of-memory-помилки при великому споживанні пам’яті.

Головний недолік для користувачів — challenge window для fraud proof. Подовжений період змушує чекати перед виведенням токенів, що незручно для застосунків із чутливістю до часу. Безпека L1 smart contract і офчейн-компонентів потребує постійної уваги та аудиту.

Альтернативні рішення

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

Ініціативи щодо розвитку L2 proof

Сучасні L2-блокчейни на базі OP Stack активно вдосконалюють fraud proof-механізми через низку ініціатив. Зусилля спрямовані на підвищення ефективності офчейн-інфраструктури fraud proof, оптимізацію challenge window для швидшого фіналу користувачів, покращення й стабілізацію ончейн-контрактів через тестування й аудит, а також пошук альтернативних бізнес-рішень для різних застосунків та спільнот.

Висновки

У статті розглянуто еволюцію fraud proof-систем Layer 2, історичні підходи та сучасні інтерактивні fraud proof-інновації через проект Cannon. Описано архітектурні принципи OVM, спробу створити EVM-сумісне середовище на L1, а також особливості дизайну і реалізації Cannon, що є проривом завдяки скороченню ончейн-верифікації до однієї MIPS-інструкції. Ці розробки демонструють розвиток Layer 2 у напрямку ефективності, зниження витрат і покращення користувацького досвіду при збереженні гарантій безпеки для блокчейн-застосунків.

FAQ

Що таке fraud proof?

Fraud proof — це криптографічні докази для оскарження валідності транзакцій у блокчейн-мережах. Вони забезпечують цілісність транзакцій і є важливими для масштабування блокчейну.

Як fraud proof працює в Optimistic Rollups?

Fraud proof дають змогу користувачам оскаржувати некоректний стан L2, запропонований sequencer. Optimistic rollup розміщує дані транзакцій та покладається на сторонніх учасників для перевірки стану L2 шляхом його відновлення. Challenger у разі розбіжностей оскаржує стан на L1 через механізм bisection game, визначає некоректні обчислення та виконує one-step proof для доведення fraud.

Чим fraud proof відрізняється від validity proof?

Fraud proof підтверджують транзакції із затримкою через оскарження фальшивих транзакцій, а validity proof миттєво підтверджують транзакції із застосуванням zero-knowledge криптографії. Validity proof забезпечують негайний фінал та ефективність, а fraud proof потребують часу для можливих оскаржень.