Віталік: Обговоріть різні типи версій «вбудованого ZK-EVM» і проблеми дизайну

Слова: Віталік Бутерін

Компіляція: 1912212.eth, Foresight News

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

Ця ситуація не ідеальна, оскільки ці проєкти реплікують функціональність, яка вже існує в протоколі ETH Workshop, а ETH Governance вже відповідає за оновлення та виправлення помилок: ZK-EVM — це, по суті, та сама робота, що й перевірка блоків Layer 1 ETH Workshop!Крім того, в найближчі роки ми очікуємо, що легкі клієнти ставатимуть все більш потужними, і незабаром досягнуть точки, коли ZK-SNARK будуть використовуватися для повної перевірки виконання EVM рівня 1. У цей момент ETH мережа ефективно побудує вбудований ZK-EVM. Отже, виникає питання: а чому б не зробити сам ZK-EVM придатним і для роллапів?

У цій статті ми розглянемо кілька «вбудованих версій ZK-EVM», які можна реалізувати, і обговоримо компроміси та проблеми дизайну, а також причини, чому вони не рухаються в певному напрямку. Переваги впровадження функцій протоколу слід зважити з перевагами залишення речей в екосистемі та простоти базового протоколу.

Які ключові функції ми хочемо отримати від вбудованого ZK-EVM?

• Основна функція: перевірка ETH блоків. Функція протоколу (яка ще не ясна, чи є вона кодом операції, попередньою компіляцією або іншим механізмом) повинна прийняти як вхідні дані принаймні один корінь з попереднім станом, один блок і один корінь після стану, і перевірити, що корінь після стану насправді є результатом виконання блоку.
• Сумісний з декількома клієнтами ETH Square. Це означає, що ми хочемо уникнути лише однієї системи атестації, а натомість дозволити різним клієнтам використовувати різні системи атестації. Звідси випливають наступні моменти:
• Вимоги до доступності даних: Для будь-якого виконання EVM, яке використовує вбудований ZK-EVM для доведення, ми хочемо гарантувати доступність базових даних, щоб докази, які використовують іншу систему атестації, могли повторно підтвердити виконання та дозволити клієнтам, які покладаються на цю систему атестації, перевірити щойно створені докази.
• Докази існують за межами структур даних EVM і фрагментів: Вбудована функція ZK-EVM не приймає SNARK як вхідні дані в EVM, оскільки різні клієнти очікують різних типів SNARK. Натомість, це може бути схоже на перевірку BLOB: транзакція може включати (pre-state, block body, post-state) претензії, які потрібно засвідчити, до вмісту яких може отримати доступ код операції або прекомпілятор, а правила консенсусу на стороні клієнта перевірятимуть доступність даних та докази існування для кожної заяви окремо.
• Можливість аудиту. Якщо будь-яке виконання доведено, ми хочемо, щоб базові дані були придатними для використання, щоб у разі виникнення проблеми користувачі та розробники могли їх перевірити. Фактично, це додає ще одну причину, чому вимоги до доступності даних такі важливі.
• Можливість модернізації. Якщо виявиться, що рішення ZK-EVM має помилку, ми хочемо мати можливість швидко її виправити. Це означає, що немає необхідності в хардфорку для виправлення. Це додає до того, чому докази існують за межами EVM і блокових структур даних.
• Підтримує майже всі EVM. Однією з переваг L2 є інновації на рівні виконання та масштабування EVM. Якщо віртуальна машина для даного L2 лише трохи відрізняється від EVM, то було б непогано, якби L2 все ще міг використовувати ZK-EVM в рамках рідного протоколу в тих же частинах, що і EVM, і покладатися тільки на свій власний код в різних частинах. Цього можна досягти шляхом розробки функції ZK-EVM, яка дозволяє абоненту вказувати бітові поля або списки кодів операцій або адреси, які обробляються зовнішніми таблицями, а не самим EVM. Ми також можемо певною мірою зробити вартість газу відкритою для редагування.

“Відкриті” та “закриті” мультиклієнтські системи

«Філософія кількох клієнтів» – це, мабуть, найбільш суб’єктивна вимога в цьому списку. Є варіант відмовитися від неї і зосередитися на схемі ZK-SNARK, яка спростить дизайн, але ціною того, що вона стане більшим «філософським поворотним моментом» для ETH Workshop (оскільки вона фактично відмовляється від давньої багатоклієнтської філософії ETH Workshop) і вносить більші ризики. У майбутньому, коли технологія формальної верифікації стане кращою, можливо, буде краще вибрати цей шлях, але зараз здається, що ризик занадто великий.

Інший варіант - закрита багатоклієнтська система, де в протоколі відомий фіксований набір систем атестації. Наприклад, ми можемо вирішити використовувати три ZK-EVM: PSE ZK-EVM, Polygon ZK-EVM і Kakarot. Для того, щоб блок був дійсним, потрібні докази, надані двома з цих трьох. Це краще, ніж єдина система доведення, але це робить систему менш адаптивною, оскільки користувачам доводиться підтримувати валідаторів для кожної існуючої системи доказів, і неминуче виникнуть політичні процеси управління для включення нових систем доказів тощо.

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

Які ключові властивості ми хочемо отримати від реалізації ZK-EVM?

Крім базової функціональної коректності і гарантій безпеки, найважливішим атрибутом є швидкість. Хоча ми можемо розробити функцію ZK-EVM у протоколі, яка є асинхронною і повертає кожну оголошену відповідь лише після затримки в N слотів, проблема стає набагато простішою, якщо ми можемо надійно гарантувати, що доказ буде згенеровано за лічені секунди, незалежно від того, що відбувається в кожному блоці, який є самодостатнім.

Хоча сьогодні для створення доказів для ETH блоків потрібно багато хвилин або годин, ми знаємо, що немає теоретичних причин для запобігання масовому розпаралеленню: ми завжди можемо об’єднати достатню кількість графічних процесорів, щоб довести виконання окремих частин блоку окремо, а потім скласти докази разом за допомогою рекурсивних SNARK. Крім того, апаратне прискорення за допомогою FPGA та ASIC може допомогти ще більше оптимізувати докази. Однак дійти до цього моменту є величезним інженерним викликом, який не можна недооцінювати.

Як може виглядати функція ZK-EVM у протоколі?

Подібно до транзакцій BLOB EIP-4844, ми представили новий тип транзакцій, який містить вимоги ZK-EVM:

Важливо зазначити, що на практиці ми можемо захотіти розділити бічне завантаження на два окремі бічні завантаження, одне для BLOB, а інше для доказів, і налаштувати окрему підмережу для кожного типу доказів (і додаткову підмережу для BLOB).

На рівні консенсусу ми додали правило валідації, яке приймає блок лише в тому випадку, якщо клієнт бачить дійсний доказ кожного твердження в блоці. Доказом має бути ZK-SNARK, який доводить, що конкатенація транзакції_and_witness_blobs є серіалізацією пари (Блок, Свідок), і що блок виконується з pre_state_root на Свідка

(i) є дійсним;

(ii) Вивести правильний пост_state_root. Можливо, клієнт може дочекатися декількох типів доказів M-of-N.

Тут важливо відзначити, що саме виконання блоку можна розглядати просто як одну з трійок, які потрібно перевірити разом з трійками, наданими в об’єкті ZKEVMClaimTransaction (σpre, σpost, Proof). В результаті, реалізація ZK-EVM користувача може замінити його клієнт виконання; клієнт виконання все одно буде виконуватися

(i) Виробники та будівельники блоків та:

та (ii) вузли, які дбають про індексацію та зберігання даних для локального використання.

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

Верифікація та переатестація

Припустимо, що є два ETH клієнти, один з яких використовує PSE ZK-EVM, а інший використовує Polygon ZK-EVM, на даний момент обидві реалізації еволюціонували до такої міри, що вони можуть довести виконання ETH блоку менш ніж за 5 секунд, і для кожної системи доказу є достатня кількість незалежних добровольців, які запускають апаратне забезпечення для генерації доказів.

На жаль, оскільки окремі системи доказів не є формалізованими, вони не можуть бути заохочені в протоколі, однак ми очікуємо, що вартість проведення доказів буде нижчою порівняно з дослідженнями та розробками, тому ми можемо легко фінансувати докази через установи, що фінансуються на суспільні блага.

Скажімо, хтось публікує ZKEvmClaimNetworkTransaction, але публікує лише доказ версії PSE ZK-EVM. Вузол доведення полігону ZK-EVM бачить це, обчислює та повторно публікує об’єкт разом із доказом полігону ZK-EVM.

Це збільшить загальну максимальну затримку між найранішим чесним вузлом, який приймає блок, і останнім чесним вузлом, який приймає той самий блок, від δ до 2δ+Tprove (припускаючи, що тут Tprove<5s).

Хороша новина, однак, полягає в тому, що якщо ми приймемо остаточність одного слота, ми майже напевно зможемо «пройти» цю додаткову затримку разом із багатораундовою затримкою консенсусу, притаманною SSF. Наприклад, у цій пропозиції з 4 слотами для кроку “голосування головою” може знадобитися лише перевірка валідності базового блоку, але крок “заморозити та підтвердити” вимагатиме наявності доказу.

Розширення: Підтримка “майже-EVM”

Бажаною метою функції ZK-EVM є підтримка «майже-EVM»: EVM з додатковими функціями. Це може включати нову попередню компіляцію, нові коди операцій, контракти, які можуть бути EVM або абсолютно різними віртуальними машинами (наприклад, в стилусі Arbitrum), або навіть кілька паралельних EVM із синхронним перехресним зв’язком.

Деякі модифікації можуть бути підтримані простим способом: ми можемо визначити мову, яка дозволяє ZKEVMClaimTransaction передавати повний опис модифікованого правила EVM. Це можна використовувати в наступних ситуаціях:

1. Індивідуальна таблиця витрат на газ (користувачам не дозволяється зменшувати витрати на газ, але вони можуть їх збільшити)
2. Вимкніть певні коди операцій
3. Встановити номер блоку (це буде означати, що існують різні правила в залежності від хардфорка)
4. Встановіть прапорець, щоб активувати повний набір змін EVM, які вже стандартизовані для L2, але не для використання L1, або інші простіші зміни

Для того, щоб дозволити користувачам додавати нові функціональні можливості більш відкритим способом, наприклад, вводячи новий попередньо скомпільований (або код операції), ми можемо додати спосіб включення попередньо скомпільованих записів введення/виведення в розділ blob ZKEVMClaimNetworkTransaction:

class PrecompileInputOutputTran(Container):used_precompile_addresses: List[Address][VersionedHash]inputs_commitments: список[Bytes]виходи: Список

Виконання EVM буде змінено наступним чином. Масив під назвою inputs буде ініціалізований як порожній. Щоразу, коли викликається адреса used_precompile_addresses, ми додаємо об’єкт InputsRecord(callee_address, Gas, input_calldata) до входів і встановлюємо викликаний RETURNDATA на виходи[i]。 Нарешті, ми перевіряємо, що used_precompile_addresses було викликано len(outputs) загалом разів, і що inputs_commitments збігається з результатом зобов’язання результуючої blob до серіалізації входів SSZ. Мета експонування входів_commitments полягає в тому, щоб дозволити зовнішньому СНАРКУ довести взаємозв’язок між входами та виходами.

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

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

Дизайн може бути змінений для підтримки нових або модифікованих кодів операцій, на додаток до нових або модифікованих попередніх компіляцій. Навіть при попередній компіляції дизайн дуже потужний. Наприклад:

Такі функції, як Arbitrum Stylus, можуть підтримуватися встановленням used_precompile_addresses для включення списку звичайних адрес облікових записів з певним прапорцем, встановленим в об’єкті їх облікового запису в стані, і генерації SNARK, які доводять, що вони побудовані правильно, де контракт може записати свій код в EVM або WASM (або іншій віртуальній машині). Привілейовані транзакції можна використовувати, щоб дозволити обліковим записам WASM відкликати EVM.

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

ZK-EVM типу 4 може працювати, маючи кілька реалізацій: одна, яка перетворює Solidity або іншу мову вищого рівня безпосередньо на віртуальну машину, дружню до SNARK, а інша, яка компілює її в код EVM і виконує його в прописаному ZK-EVM. Друга (і неминуче повільніша) реалізація може запуститися лише в тому випадку, якщо організатор невдачі надсилає транзакцію, стверджуючи, що має помилку, і якщо він може запропонувати, щоб ці двоє обробляли різні транзакції, винагороду можна було б отримати.

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

Розширення: Підтримка підтвердження стану

Проблема з наведеним вище дизайном полягає в тому, що він повністю не має стану, що робить його поганим з точки зору ефективності даних. Завдяки ідеальному стисненню даних, стиснення зі збереженням стану може зробити надсилання ERC20 більш компактним у 3 рази порівняно зі стисненням без стану.

На додаток до цього, державні EVM не зобов’язані надавати дані свідків. В обох випадках принцип однаковий: марнотратно просити про доступність даних, коли ми вже знаємо, що дані доступні, оскільки вони були введені або вироблені попереднім виконанням EVM. **

Якщо ми хочемо зробити функцію ZK-EVM станною, у нас є два варіанти:

Вимагає, щоб σpre було або null, або заздалегідь оголошеним списком ключів і значень, для яких доступні дані, або деяким раніше виконаним σpost.

Додайте зобов’язання blob до кортежу (σpre, σpost, proof) для квитанції R, згенерованої блоком. Будь-які раніше згенеровані або використані зобов’язання-блоби, на які можна посилатися в ZKEVMClaimTransaction і отримувати доступ під час їх виконання, включаючи зобов’язання, що представляють блоки, свідків, квитанції або навіть звичайні транзакції BLOB-BLOB-(можуть існувати деякі часові обмеження, на які можна посилатися серією інструкцій: «Вставте байт N зобов’язання i в позицію j блоку + дані свідка… N+k-1")

(1) Основний сенс такий: замість встановлення перевірки EVM без стану, ми створимо дочірній ланцюг EVM.

і (2) по суті створює мінімальний вбудований алгоритм стиснення зі збереженням стану, який використовує раніше використаний або згенерований BLOB як словник. І те, і інше накладає навантаження на вузол провера, і тільки вузол ровера зберігає більше інформації;

У випадку (2) простіше обмежити цей тягар у часі, а у випадку (1) складніше.

Аргументи для закритих багатофункціональних систем та офчейн-даних

Замкнута багатофункціональна система, в якій в структурі M-of-N є фіксована кількість доказів, дозволяє уникнути значної частини описаної вище складності. Зокрема, закритій мультитестерній системі не потрібно турбуватися про те, щоб дані існували в ланцюжку. Крім того, закрита мультитестерна система дозволить виконувати докази ZK-EVM поза мережею, що зробить їх сумісними з плазмовими рішеннями EVM.

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

Якщо ми вбудуємо ZK-EVM і зробимо його функцією протоколу, яка поточна роль проекту L2?

Функції валідації EVM, які зараз реалізовані самою командою L2, будуть оброблятися протоколом, але проект L2 все одно відповідатиме за низку важливих функцій:

• Швидке попереднє підтвердження: Завершеність одного слота може уповільнити слоти L1, тоді як L2 вже надає користувачам послугу з власною безпекою, що підтримується попереднім підтвердженням, із затримкою набагато меншою, ніж один слот. За цю послугу, як і раніше, відповідатиме L2.
• Стратегії пом’якшення наслідків MEV: Це може включати такі функції, як зашифровані мемпули, послідовний вибір на основі репутації тощо, які L1 неохоче впроваджує.
• Розширення EVM: Проєкти рівня 2 можуть впроваджувати значні розширення EVM, які надають значну цінність їхнім користувачам. Це включає в себе «майже-EVM» і зовсім інші підходи, такі як підтримка WASM в Arbitrum Stylus і дружня каїрська мова SNARK.
• Зручність для користувачів і розробників: команди Tier 2 докладають багато зусиль, щоб залучити користувачів і проекти до своєї екосистеми та зробити так, щоб вони відчували себе бажаними; вони отримують гроші, збираючи MEV та комісію за перевантаження у своїй мережі. Ці стосунки залишаться надовго.