V Shen Xinwen: Після ETH вбудованого ZK Fang, куди рухається Layer2?

Вироблено | Odaily

Компіляція | Лупі Лу

Сьогодні Віталік Бутерін опублікував у ETH-спільноті нову статтю під назвою «Як може виглядати вбудований ZK-EVM?». У цій статті досліджується, як ETH Workshop матиме власний ZK-EVM, вбудований у майбутні оновлення мережі.

Як ми всі знаємо, в контексті повільного розвитку ETH майже всі мейнстрімні рівні 2 вже мають ZK-EVM, але коли основна мережа ETH майстерні інкапсулює свій власний ZK-EVM, чи виникне конфлікт між рольовим позиціонуванням основної мережі та рівня 2?

У цій статті Віталік Бутерін наголошує на важливості сумісності, доступності даних та можливості аудиту, а також досліджує можливості впровадження ефективних та державних атестаторів. Крім того, у статті досліджується можливість впровадження доказів стану для ефективності, а також обговорюється роль проєктів рівня 2 у забезпеченні швидкого попереднього підтвердження та стратегій пом’якшення наслідків MEV. Ця стаття відображає баланс просування розвитку мережі ETH за допомогою ZK-EVM при збереженні її гнучкості.

Odaily Planet Daily зібрав оригінальну статтю, а повний текст статті виглядає наступним чином:

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

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

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

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

Які ключові атрибути ми можемо очікувати від упакованого ZK-EVM?

Основна функція: перевірка ETH блоків. Функція протоколу (яка ще не визначена, чи є це кодом операції, попередньою компіляцією або якимось іншим механізмом) повинна бути в змозі прийняти принаймні корінь до стану, блок і корінь після стану як вхідні дані, і перевірити, що корінь після стану насправді є результатом виконання цього блоку поверх кореня попереднього стану. Сумісний з мультиклієнтською системою ETH Workshop. Це означає, що ми хочемо уникнути єдиної вбудованої системи атестації, а натомість дозволити різним клієнтам використовувати різні системи атестації.

Це також означає кілька речей:

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

Докази знаходяться за межами структур даних EVM і фрагментів:* Функціональність ZK-EVM насправді не сприймає SNARK як вхідні дані всередині EVM, оскільки різні клієнти очікують різних типів SNARK. Натомість, це може бути схоже на перевірку BLOB: транзакція може включати твердження (pre-state, block body, post-state), які потрібно довести, до вмісту яких можна отримати доступ за допомогою кодів операцій або прекомпіляцій, а правила консенсусу на стороні клієнта перевіряють доступність даних та доказ тверджень, зроблених у блоці, відповідно.

Можливість перевірки: Якщо будь-яке виконання доведено, ми хочемо, щоб базові дані були придатними для використання, щоб, якщо щось піде не так, як користувачі, так і розробники могли це перевірити. Фактично, це додає ще одну причину, чому вимоги до доступності даних є важливими.

Можливість оновлення: Якщо ми знаходимо помилку в певному рішенні ZK-EVM, ми хочемо мати можливість швидко її виправити. Це означає, що немає необхідності в хардфорку для вирішення проблеми. Це додає ще одну причину, чому докази за межами EVM і блокових структур даних є важливими.

Однією з переваг підтримки «приблизного EVM» :**L2s є можливість впроваджувати інновації на рівні виконання та масштабувати EVM. Якщо віртуальна машина L2 лише трохи відрізняється від EVM, то було б непогано, якби L2 міг використовувати рідний вбудований протокол ZK-EVM для тих самих частин, що й EVM, і покладатися лише на власний код для обробки різних частин. Цього можна досягти, розробивши функцію ZK-EVM, яка дозволяє абоненту вказати бітове поле, код операції або список адрес, які будуть оброблятися зовнішньою формою, а не самим EVM. Ми також можемо певною мірою налаштувати вартість газу.

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

«Менталітет кількох клієнтів» – це, мабуть, найбільш суперечлива вимога в цьому списку. Одним із варіантів було б відмовитися від мультиклієнтської та зосередитися на одній схемі 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:

клас ZKEVMClaimTransaction(Container):
pre_state_root: байтів 32
post_state_root: байт 32
транзакція_and_witness_blob_pointers: список[VersionedHash]
…

Як і у випадку з EIP-4844, об’єкт, переданий у мемпулі, є модифікованою версією транзакції:

клас ZKEvmClaimNetworkTransaction(Container):
pre_state_root: байтів 32
post_state_root: байт 32
доведення: байти
transaction_and_witness_blobs: list[Bytes[FIELD_ELEMENTS_PER_BLOB * 31 ]]

Другу можна перетворити на першу, але ніяк не навпаки. Ми також розширили об’єкт block sidecar (представлений в EIP-4844), включивши список доказів, оголошених у блоці.

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

На рівні консенсусу ми додали правило перевірки, яке прийматиме блок лише в тому випадку, якщо клієнт бачить дійсний доказ кожного твердження в блоці. Доказ повинен бути конкатенацією доказу ZK-SNARK, серіалізованим як пара транзакцій_and_witness_blobs, і пре_state_root дійсним з (i) і Witness (ii) вивести правильний пост_state_root. (Заблокувати, Свідок) Потенційно клієнти можуть дочекатися M-of-N для кількох типів доказів.

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

В результаті, реалізація ZK-EVM користувача може замінити його клієнт виконання, який все ще буде використовуватися (i) виробниками доказів і блоків, і (ii) вузлами, які піклуються про індексацію та зберігання даних для локального використання.

Валідація та ревалідація

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

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

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

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

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

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

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

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

• Спеціальний газовий стіл (користувачі не можуть зменшити витрати на газ, але можуть їх збільшити)
• Вимкніть певні коди операцій
• Встановити номер блоку (це буде мати на увазі різні правила в залежності від хардфорка)
• Встановіть прапорець, який активує повний набір змін EVM, які були нормалізовані для використання L2, а не L1, або інших простіших змін

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

клас PrecompileInputOutputTran(Container):
used_precompile_addresses: Список[Address]
входи_commitments: список[VersionedHash]
виходів: Список[Bytes]

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

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

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

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

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

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

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

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

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

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

2. До ( σpre, σпост, Доказ ) Потрійний, щоб додати квитанцію, згенеровану для блоку R зобов’язань BLOB. Будь-які раніше згенеровані або використані зобов’язання BLOB, включно з тими, що представляють блоки, свідків, квитанції або навіть звичайні транзакції BLOB-об’єктів EIP-4844, можуть мати певні часові обмеження, на які можна посилатися в ZKEVMClaimTransaction і отримувати доступ під час їх виконання (можливо, за допомогою серії інструкцій: «Буде вчинено Я Байти N… N+k-1 вставляється в дані фрагмент+свідка J "）。

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

Параметри для закритих мультисерверів та офчейн даних

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

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

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

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

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