Детально поясніть п'ять типів ZK-EVM: архітектуру, переваги та недоліки та рішення

Автор оригінального тексту: s Компіляція оригінального тексту: Deep Tide TechFlow

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

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

Давайте розберемо типи ЗК-ЕВМ, їх плюси і мінуси.

1. Тип 1: повністю еквівалентний Ethereum;

2. Тип 2: повністю еквівалентний EVM;

3. Тип 2.5: частково еквівалентний EVM;

4. Тип 3: майже еквівалентний EVM;

5. Тип 4: де мова високого рівня є еквівалентною.

Тип 1: повністю еквівалентний Ethereum

Архітектура: вона точно така ж, як Ethereum, і не змінює жодної частини системи Ethereum.

перевага

Ідеальна сумісність:

• Можливість перевірки блоків Ethereum;
• Допоможіть зробити Ethereum L1 більш масштабованим;
• Підходить для зведених пакетів, оскільки вони можуть повторно використовувати велику кількість інфраструктури.

недолік

Ідеальна сумісність:

• Ethereum спочатку не був розроблений для функціональності ZK;
• Багато компонентів Ethereum вимагають багато обчислень для створення доказів ZK (ZKP);
• Створення доказів для блоків Ethereum займає багато годин.

Рішення проблеми:

• Широкомасштабний прувер розпаралелювання;
• ZK-SNARK ASIC.

Тип 2: повністю еквівалентний EVM

Архітектура:

• Структура даних (блокова структура та дерево стану) значно відрізняється від Ethereum;
• Повністю сумісний з існуючими додатками;
• Незначні модифікації Ethereum для полегшення розробки та швидшого створення доказів.

перевага

• Забезпечує більш швидкий час перевірки, ніж тип 1;
• EVM не має прямого доступу до структури даних;
• Програми, що працюють на Ethereum: швидше за все, працюватимуть на Type 2;
• Підтримка існуючих інструментів налагодження EVM та іншої інфраструктури розробки.

недолік

Перш ніж розбиратися в недоліках, спочатку зрозумійте, що таке “Keccak”:

• Алгоритм хешування блокчейна Ethereum;
• Використовується для захисту даних на Ethereum;
• Переконайтеся, що повідомлення перетворено на хеш.

Тип 2 несумісний із програмами, які перевіряють докази Merkle історичних блоків для перевірки інформації про історичні транзакції, квитанції/стани. Це тому, що якщо алгоритм хешування зміниться (більше не Keccak), доказ стане недійсним.

Ми можемо думати про Keccak як про мову, яка використовує докази Merkle (алфавіти). Якщо ZK-EVM замінить Keccak іншим алгоритмом хешування (наприклад, Poseidon), докази Merkle стануть незнайомими, і програми не зможуть їх прочитати та підтвердити свої твердження.

Потенційне вирішення недоліків: Ethereum може додати в майбутньому масштабовану попередню компіляцію доступу до історії.

демонструвати

• Прокрутка;
• Багатокутник Гермеза.

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

Тип 2.5: частково еквівалентний EVM

Архітектура:

Збільшити вартість газу для конкретних операцій EVM, які важко підтвердити ЗК;

• Попередньо скомпільований;
• Код операції Keccak;
• Режим виклику договору;
• Доступ до пам’яті;
• зберігання.

перевага

• Значно покращений час перевірки найгіршого випадку;
• Безпечніше, ніж вносити глибші зміни в стек EVM.

недолік

• Сумісність засобів розробки знижена;
• Деякі програми не працюватимуть.

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

Архітектура:

• У реалізації ZK-EVM деякі функції, які надзвичайно важко реалізувати, видаляються, зазвичай попередньо скомпільовані;
• ZK-EVM має невеликі відмінності в тому, як він обробляє код контракту, пам’ять або стек.

перевага

• скоротити час перевірки;
• Полегшити розробку EVM;
• Мета полягає в тому, щоб вимагати мінімального перезапису для менш сумісних програм.

недолік

• Більше несумісностей;
• Програми, які використовують попередню компіляцію, видалені в типі 3, потрібно буде переписати.

демонструвати

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

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

Архітектура:

• Приймати код смарт-контракту, написаний на мовах високого рівня (таких як Solidity, Vyper);
• Скомпільовано мовою, розробленою для підтримки ZK-SNARK.

перевага

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

недолік

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

демонструвати

• zkSync

Нарешті, ми можемо порівняти наведені вище типи разом, щоб допомогти кожному зрозуміти різні zkEVM з першого погляду.