Від типу 1 до типу 4, які відмінності між різними типами ZK-EVM?

Оригінальний автор| Ліза Аксельрод

Складено | Odaily Planet Daily 0xAyA

*Примітка редактора: автор склав його на основі вступної статті ZK-EVM, яку раніше написав Віталік, і детально представив різні типи ZK-EVM та відмінності між ними. *

Близько року тому група ZK-EVM оголосила, що збирається запустити тестову мережу. Ці кроки викликали цікавість спільноти Ethereum і викликали дискусію про нюанси, що стоять за такими термінами, як еквівалентність Ethereum і еквівалентність EVM.

Для ясності Віталік написав важливу статтю під назвою «Різні типи ZK-EVM», у якій різні ZK-EVM класифікуються на чотири типи та пояснюються їхні відмінності.

Основна ідея така: тип 1 (наприклад, Taiko) повністю еквівалентний Ethereum, тоді як тип 4 (наприклад, zkSync) вирізняється ефективністю створення доказів. Усі інші типи, Тип 2, Тип 2.5 і Тип 3, знаходяться між ними (наприклад, Polygon zkEVM, Scroll, Linea).

Більшість ZK-EVM спочатку належать до типу 2.5 і типу 3, з певним наміром еволюціонувати до типу 1 або типу 2, хоча ці проекти не передбачили конкретних часових рамок або зобов’язань для цього.

**Ця стаття присвячена відмінностям між Типом 1 і Типом 2/Типом 2.5, а також описує можливі наслідки порушення еквівалентності Ethereum. Також ми коротко торкнемося інших типів. **

Основна мета ZK-EVM — масштабувати Ethereum, тобто збільшити пропускну здатність Ethereum, зберігаючи інші його функції (безпеку, досвід розробників тощо). В ідеалі ZK-EVM повинен мати можливість:

• Демонструє виконання немодифікованого рідного байт-коду (що охоплює 100% кодів операцій Ethereum) відповідно до специфікації віртуальної машини Ethereum у Жовтій книзі.
• Швидко генеруйте докази за низькою ціною.
• Дозволяє 100% повторне використання інструментів та інфраструктури, розроблених для Ethereum.
• Дозволити повторне розгортання будь-якого dApp Ethereum на ZK-EVM «як є» («як є» означає, що жодних змін і компромісів не потрібно).

Відмінності між типами ZK-EVM

У світі ZK-EVM відмінності в основному походять від рівня еквівалентності Ethereum/EVM, впливу незручних для ZK елементів на вартість і швидкість генерації доказів, а також складності реалізації схеми (наприклад, побудова або стан віртуальної машини). дерева).

Давайте проаналізуємо ці відмінності, зокрема відокремлюючи тип 1 від типу 2/типу 2.5. Ми також торкнемося варіантів використання, найбільш відповідних кожному типу.

При порівнянні різних типів часто використовують таку діаграму:

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

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

Тип 1: еквівалент Ethereum

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

«Тип 1 ZK-EVM — це те, що нам остаточно потрібно, щоб зробити сам рівень 1 Ethereum більш масштабованим».

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

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

• Тип 1 — це єдиний тип, який може перевірити сам ланцюжок Ethereum — від цілих блоків до виконання транзакцій, смарт-контрактів і логіки облікового запису.

Тип 2: еквівалент EVM

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

*Примітка. Еквівалент Ethereum і еквівалент EVM – це не те саме. Хоча еквівалентність Ethereum означає, що жодна частина Ethereum не була змінена, що означає, що він повністю сумісний з усіма додатками Ethereum dApps, еквівалентність EVM дозволяє змінювати структури даних (наприклад, блочні структури або дерева стану). *

Хоча ці зміни можуть здатися незначними, вони впливають на сумісність Ethereum. Зміна структур даних може спричинити несумісність dApps Ethereum із типом 2 ZK-EVM, особливо під час перевірки доказів Merkle щодо минулих транзакцій, квитанцій або станів (наприклад, через ланцюгові мости).

Видалити недружні елементи ZK

Модифікації Ethereum призначені для спрощення розробки та збільшення швидкості створення доказів. Мета полягає в тому, щоб видалити частини Ethereum, які покладаються на недружню криптографію з нульовим знанням. Говорячи більш технічною мовою, частини, які потребують великої кількості вентилів (операції додавання та множення) через нелокальні домени (наприклад, хеш-функції); велика кількість мультискалярних множень та/або швидких перетворень Фур’є (ШПФ); або лише та частина, яка потребує багато маніпуляцій.

Конкретні приклади недружніх елементів із нульовим знанням, які тип 2 ZK-EVM може змінити:

• Хеш-функція: у той час як Ethereum використовує хеш-функцію Keccak, багато ZK-EVM використовують хеш-функцію Poseidon, яка вимагає значно меншої кількості воріт. Наприклад, давайте оцінимо, скільки хеш-функцій кожного типу можна обчислити за секунду (тобто порівняння, яке демонструє швидкість генерації).

Хеш-функції Poseidon мають значні переваги у швидкості створення доказів.

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

Ось чому Keccak, незважаючи на те, що він старший і прийнятий ширшою спільнотою (в інших галузях, таких як системи безпеки чи датчики в інтелектуальних пристроях), можна вважати більш перевіреним, ніж Poseidon, який, зрештою, входить до спільноти ZK New hash функції для створення та використання.

• Дерева станів для зберігання даних: наприклад, у той час як Ethereum використовує дерева Merkle Patricia (використовуючи хешування Keccak), деякі ZK-EVM типу 2 вибирають розріджені дерева Merkle (використовуючи хешування Poseidon). Зміна дерева станів може спричинити деякі несумісності. Наприклад, дерево Merkle Ethereum має різні типи вузлів і використовує RLP для кодування даних, що важко зробити в ZK.
• Блокова структура: блоки містять велику кількість інформації. Однак, досліджуючи L2, ми дбаємо лише про ution_payload_header (тобто хеш блоку). На зображенні нижче показано структуру (хеш блоку) усіх даних, що містяться в ution_payload_header.

**Зверніть увагу: зміна будь-якого з цих компонентів порушить еквівалентність Ethereum. **

Тип 2.5: еквівалент EVM, враховуючи вартість газу

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

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

• газ — одиниця виміру роботи.
• Ціни на код операції розраховуються в газі.
• Коди операцій визначають операції в інструкціях машинної мови.
• Програма — це статичний список кодів операцій. Виконання програми - це траса виконання.
• Трасування виконання — це певний упорядкований список кодів операцій, які виконує програма.

Деталі, які важко підтвердити ZK, включають:

• Коди операцій Keccak та деякі інші коди операцій, які залежать від Keccak.
• Попередньо скомпільовані: функції, доступні для EVM. Деякі з них пропонують складні або математично складні завдання, наприклад криптографічні функції (наприклад, blake 2 f або sha 256). Вони не виконуються в EVM, а як функції, жорстко закодовані в клієнті виконання та надані EVM за допомогою викликів до спеціальних адрес.
• Доступ до пам’яті: наприклад, збільшення розміру слота пам’яті (наприклад, Ethereum використовує пам’ять з вирівнюванням байтів, тоді як Polygon zkEVM використовує 32-байтові слоти пам’яті). Щоб зробити цю зміну можливою, внутрішню логіку певних кодів операцій (наприклад, MLOAD) потрібно було змінити.
• Зберігання (тобто зміна хеш-функції або дерева станів, як описано вище).

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

Тип 3: Майже еквівалент EVM

Тип 3 ZK-EVM пропускає попередню компіляцію, яка не застосовується до ZK, і може регулювати доступ до пам’яті та сховища.

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

Тип 4 (еквівалент мови високого рівня)

Тип 4 вже далеко від EVM.

Вихідний код смарт-контракту, написаний на мові високого рівня (наприклад, Solidity, Zinc), компілюється в проміжне представлення, що генерує коди операцій, придатні для ZK-дружніх віртуальних машин.

• Цей метод дозволяє уникнути створення доказів ZK для кожного кроку виконання EVM, що значно скорочує роботу з перевірки.
• Навіть якщо договір можна скомпілювати, потрібна додаткова робота, якщо dApp використовує рукописний байт-код EVM. *Тип 4 ZK-EVM також потребує власних інструментів розробника (тільки на рівні коду операції), таких як налагоджувачі та трасувальники.

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

Варто зазначити, що спеціальні коди операцій (коди операцій, які не розглядаються в Ethereum) дають змогу передавати нові функції, які недоступні в Ethereum за замовчуванням. Наприклад, зробіть кілька викликів для виконання за допомогою функції абстрагування облікового запису або запустіть гаманець смарт-контрактів за допомогою готового рішення, наприклад Argent.

Підведіть підсумки

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

Ці чотири типи класифікації можуть не бути остаточним станом зведення ZK і можуть бути предметом подальших змін у майбутньому. Наприклад, деякі ZK-EVM можуть стати гібридними, Type 1/2 може розробляти рішення типу 4 (з найвищою можливою ефективністю) і надавати dApps обидва варіанти, тоді як ZK-EVM типу 3 і 4 можуть додавати варіант, еквівалентний Ethereum.