Докази шахрайства та віртуальні машини

Ця стаття є підсумком наукової роботи — SoK: Validating Bridges as a Scaling Solution for Blockchains — написана генеральним директором та засновником Oasis Labs Dawn Song, Патріком Маккоррі, Беннетом Йі та спочатку опублікована Крісом Баклендом у своєму блозі тут .

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

Але як можна переконати основний ланцюжок, що зафіксований стан зведення правильний? Зведені пакети поділяються на дві різні категорії, які вирішують цю проблему різними способами:

1. zk-rollups: правильність зобов’язань підтверджується супровідним доказом нульової інформації.
2. Оптимістичні згортки : зобов’язання приймаються оптимістично, але валідитори перевіряють їх і надають докази шахрайства, якщо виявляють, що зобов’язання неправильні. У випадку оптимістичних зведень зобов’язання також називають твердженням, оскільки стан стверджується, а не доводиться.

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

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

У його дописі ми зосередимося лише на оптимістичних зведеннях та доказах шахрайства, які забезпечують їх безпеку. Ми розглянемо, як вони зараз використовуються у двох популярних оптимістичних сукупностях — Arbitrum і Optimism — і які напрямки дослідження доказів шахрайства зараз.

Щоб отримати докладнішу інформацію про те, як загалом працюють зведення, я можу порекомендувати цю публікацію в блозі.

Докази шахрайства

Поточні докази шахрайства бувають двох видів:

1. Неінтерактивні
2. Інтерактивний

Неінтерактивні докази шахрайства дозволяють стороні довести хибність затвердження без участі будь-яких інших сторін. Вони роблять це, виконуючи всі переходи стану між двома підтвердженими зобов’язаннями, щоб показати, що результуюче зобов’язання відрізняється від заявленого. Неінтерактивні докази шахрайства мають перевагу в тому, що вони прості в обґрунтуванні та дизайні. Однак, якщо не використовується zk-proof, перехід між двома твердженнями має бути досить малим, щоб виконуватися в ланцюзі, що в поєднанні з поточними можливостями Ethereum накладає серйозні обмеження на переходи, які можна ефективно перевірити за допомогою цього стилю доказ шахрайства.

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

Отже, які докази шахрайства використовують деякі з поточних оптимістичних зведень?

Optimism

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

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

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

Щоб Optimism повторно виконував свої транзакції в основній мережі, їм потрібно було замінити коди операцій, які мають доступ до стану та облікових записів, на синтетичні, які здійснюють виклики до конкретного контракту, попередньо заповненого відповідним станом. Всього таким чином було замінено 18 кодів операцій , а ще 6 видалено взагалі. Кажуть, що байт-код із цими кодами операцій, заміненими на виклики функцій, виконується всередині Optimistic Virtual Machine (OVM). Оптимізм роздвоїв компілятор Solidity, щоб дозволити розробникам компілювати свої контракти для OVM.

1. Заміна інструкцій доступу до стану викликами контрактів сильно збільшує розмір байт-коду деяких контрактів. Ethereum має обмеження на розмір контракту ~25 КБ, що означає, що після перекладу з EVM на OVM деякі контракти вимагатимуть рефакторингу або їх потрібно буде розбити, щоб зробити можливим їх повторне використання під час підтвердження шахрайства.
2. Здійснення дзвінків замість використання доступу до рідного стану вимагає набагато більше газу, тому транзакції, що виконуються на OVM, фактично мали нижчий ліміт газу, ніж їхні еквіваленти, що виконуються на Ethereum.

Контракти, перекладені з EVM в байт-код OVM, страждають від двох основних обмежень:

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

Arbitrum

На даний момент у виробництві використовуються інтерактивні докази шахрайства, це Arbitrum . Їхній протокол дозволяє захиснику та супернику розділяти твердження один одного навпіл, поки вони не знайдуть єдиний крок, на який вони не згодні, а потім виконати його в ланцюжку. Розмір окремого кроку, обраного Arbitrum, дорівнює розміру однієї інструкції. Виконання однієї інструкції віртуальної машини вимагає надання доступу до внутрішнього стану віртуальної машини. Це включає стек і пам’ять, а також стан і глобальні. Повинен бути написаний інтерпретатор для віртуальної машини, який може працювати на Ethereum і виконувати окремі інструкції.

Оскільки їм потрібно було б написати інтерпретатор віртуальної машини, Arbitrum вирішив написати новий, оптимізований для їхнього випадку використання для підтвердження виконання окремих кроків, а не писати інтерпретатор для EVM. Прикладом оптимізації, яку вони зробили, було зміна структури пам’яті ВМ на незмінну, щоб до неї завжди можна було отримати доступ за постійний час, а не логарифмично, як цього вимагає поточна структура EVM. Вони назвали цю оптимізовану віртуальну машину AVM (Arbitrum Virtual Machine).

Контракти та транзакції AVM не мають тих самих обмежень, що й OVM, оскільки транзакції ніколи не виконуються повністю, вони навіть можуть перевищувати обмеження в основній мережі Ethereum, якщо вузли Arbitrum вирішують це дозволити. Написання нової віртуальної машини має й інші переваги. Оскільки все, що написано в коді AVM, можна підтвердити на Ethereum, розробники Arbitrum можуть включати нові коди операцій, якщо вони можуть бути підкріплені кодами операцій EVM. Це дозволяє їм легко включати іншу поведінку вузла, як-от читання транзакцій із контрактів папки «Вхідні», до набору операцій, які можуть бути підтверджені правильно. Arbitrum може використовувати той самий тип доказу шахрайства для будь-якої поведінки свого вузла, який вони хочуть зробити доказовою.

Одним з основних недоліків створення нової віртуальної машини є те, що вона не завжди може бути сумісна з Ethereum, а якщо сумісність можлива, для її досягнення можуть знадобитися додаткові зусилля.

Відхід від Ethereum

Обидва вищезгадані підходи відрізняються від EVM, який створює інженерні проблеми для Arbitrum, Optimism та їх користувачів. Розробники, які пишуть контракти для EVM, очікують, що їхні контракти працюватимуть на AVM та OVM, вони очікують, що існуючі інструменти працюватимуть, а JSON-RPC відповідатиме Ethereum. Щоб досягти цього, зведеним програмам може знадобитися фіксувати кінцеві точки вузла JSON-RPC, щоб вони працювали послідовно, що можливо в деяких випадках, але не в інших.

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

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

Конвергенція на Ethereum

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

Однак, на відміну від поточної версії Arbitrum, вони не хочуть розробляти нову віртуальну машину, а замість цього намагаються знайти представлення EVM, яке можна ефективно довести в ланцюжку. Це спроба зберегти 100% сумісність з EVM та Ethereum . Потім вони зможуть вносити мінімальні зміни в існуючі кодові бази клієнта Ethereum і запускати їх як зведені клієнти, успадкувавши безпеку та наполегливу роботу, яку вони доклали. Це також має означати, що вони досягають сумісності з усіма існуючими кінцевими точками JSON-RPC та інструментами, які покладаються на них без будь-яких додаткових зусиль.

Схоже, Arbitrum також усвідомили цінність цього підходу, і в своїй останній публікації в блозі вони окреслили підхід, який рухатиме їх у цьому напрямку.

До цього можна підійти кількома способами:

1. Розширте набір інструкцій, включивши в нього повну перевірку блоків, і розбийте будь-які великі окремі кроки на менші підкроки. Проект Macula є спробою цього. Він має на меті генерувати трасування виконання для повного виконання блоку Ethereum, а потім написати інтерпретатор для цього трасування виконання. Таким чином всі операції в блоці можуть бути розділені навпіл на один крок, а потім виконуватися в ланцюжку. Він має справу з кодами операцій, які можуть бути неефективними для доведення, наприклад, копіювання пам’яті, розбиваючи їх на підінструкції, сума яких дорівнювала б виконанню оригінальної інструкції.

2. Використовуйте існуючу архітектуру, більш підходящу для підтвердження та реалізуйте для неї інтерпретатор EVM. Проект Cannon витягує частини Geth, які використовуються для перевірки блоку. Потім він компілює ці частини Geth до набору інструкцій, більш піддатного для підтвердження — наприклад, MIPS або RISC-V. Коли цей MIPS-Geth використовується для перевірки блоку, записується трасування виконання. Саме цю трасу виконання дві сторони можуть розділити навпіл, щоб знайти одну інструкцію, з якою вони не погоджуються, яка потім буде виконуватися в ланцюжку з використанням інтерпретатора MIPS у ланцюжку. . Здається, це також напрямок, яким планується рухатися Arbitrum, однак замість MIPS вони мають намір використовувати стандарт WASM.

3. Створіть доказ нульового знання виконання за один крок. Замість того, щоб виконувати один крок у ланцюжку, контракт може підтвердити, що підтвердження виконання цього окремого кроку є дійсним. Доведення великих переходів станів, таких як повні транзакції, в zk наразі неможливо за короткі періоди часу, проте створення доказів для одного кроку має бути можливим. Цей підхід зараз досліджують дослідники Oasis Labs та UC Berkeley, але він також був описаний у статті Arbitrum .

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

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

Ну насправді, так! На даний момент відомі два підходи до цього:

Нульові докази знань для повного переходу стану. Існує ще ряд проблем, які необхідно подолати, перш ніж докази zk для повних транзакцій можуть бути створені за короткі проміжки часу (час блоку). Однак, якщо доказ нульової інформації використовується як доказ шахрайства, він не повинен бути ефективним для отримання доказу. Наразі докази шахрайства забезпечують тривалий період (~ 1 тиждень), щоб дати час претендентам перевірити поточний ланцюжок, створити докази шахрайства та надіслати його в Ethereum. Навіть якщо створення доказу шахрайства займає дуже багато часу (наприклад, 1–2 дні), цей період виклику може бути продовжений без незначного впливу на загальний протокол. Як і інтерактивні докази шахрайства, цей стиль доказу шахрайства може виходити за межі L1. Цей підхід зараз досліджується Sumo,Consensys .

Докази шахрайства із чистим металом. Початкова мета Optimism полягала в тому, щоб виконати код EVM на EVM, але вони не змогли, оскільки EVM основної мережі не мав доступу до стану згортання. Але чи можна спроектувати систему, де це було б можливим?

Такий підхід використовує Oasis Labs . Їх блокчейн розділяє виконання на швидкий і повільний шляхи. Підкомітети консенсусної групи виконують транзакції проти державного кореня. Отриманий корінь стану потім зберігається в базовому ланцюжку, який перевіряється повною групою консенсусу. Якщо будь-який член підкомітету не згоден з отриманим коренем стану, він може попросити групу повного консенсусу повторно виконати будь-який спірний перехід стану. У підкомітеті потрібен єдиний чесний валідатор, щоб успадкувати безпеку базового ланцюга — ту саму безпеку, що й оптимістичні зведення.

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

1. Дані містять блок зведених транзакцій із супровідним станом і свідками, а також корінь стану.
2. Клієнт виконує блок транзакцій щодо кореня стану, щоб отримати наступний корінь стану.
3. Кортеж (корінь попереднього стану, хеш блоку транзакції, корінь наступного стану) буде потім зберігатися в глобальному контракті, що дозволить будь-яким смарт-контрактам шукати цю інформацію та виконувати зріз тощо на основі результатів.

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

Резюме

Оптимістичні зведення вимагають доказів шахрайства, щоб залишатися в безпеці. Ми розглянули два популярних зведених пакети й побачили, як їхній вибір доказів шахрайства або спричинив обмеження для їхніх користувачів і розробників контрактів (Optimism), або не підтримував повну сумісність з Ethereum (Arbitrum). Обидва ці зведені пакети рухаються до повної сумісності з Ethereum, без будь-яких нових обмежень, і для цього використовують інтерактивні докази шахрайства. Однак інтерактивні докази шахрайства складніші для безпечного створення, і існують поточні шляхи дослідження, щоб знайти ефективні неінтерактивні докази шахрайства, які не накладають додаткових обмежень і все ще можуть залишатися сумісними з Ethereum.

Дякуємо Патріку Маккоррі, Дон Сонг, Беннету Йі та Ніколасу Ліочону за їхні відгуки та внесок.

Спочатку опубліковано Крісом Баклендом на https://medium.com 22 жовтня 2021 року.

**Автор відмовляється від будь якого права на статтю, перекладано з Англійської на Українську мову.**

Оригінальна стаття: https://medium.com/oasis-protocol-project/fraud-proofs-and-virtual-machines-a485bbda1452