ZK-EVM решения и проекты. Что это такое и кто круче?

Все ZK-EVM решения направлены на достижение одной и той же цели: сделать Ethereum более масштабируемым и увеличить общую экосистему WEB3.

Простыми словами, ZK-EVM это технология, объединяющая транзакции на "L2" (втором уровне) в “партии” (пачки) и затем отправляющая "доказательство валидности" ("validity proof") всей этой “партии” обратно в Ethereum "L1".

В прошлом такие решения, как ZK-rollups, не были совместимы с EVM (Ethereum Virtual Machine). Это обычно означало, что они могли выполнять только определенный перечень операций, таких как трансфер токенов, минт или сжигание. А также они требовали от пользователей новых инструментов, например создания новых кошельков в дополнение к уже имеющимся.

Необходимость в специализированных инструментах для разработчиков и пользователей, которые могли бы работать с вашим rollup, также является очень серьезной задачей. Именно это и привело к созданию ZK-rollup, совместимого с EVM. За последний год ряд компаний (например, Polygon) объявили о создании своих "ZK-EVM".

Сложность создания EVM-совместимого ZK-rollup заключается в том, что Ethereum изначально не был разработан с учетом удобства работы с ZK. Это означает, что много частей оригинального протокола Ethereum требуют большого объема вычислений для обработки и верификации на уровне ZK-rollup.

Определенные части кода, которые также называют опкоды, выполняемые EVM, более "недружелюбны" к ZK, чем другие. Это привело к различиям в уровне EVM-совместимости, который различные компании решили использовать в своих ZK-EVM решениях.

Для начала давайте разберемся, что такое опкод (opcodes), байткод (bytecode) и EVM

EVM - это среда выполнения смарт-контрактов в Ethereum.

Ethereum хранит так называемое "машинное состояние" (machine state) в структуре данных trie, которое меняется от блока к блоку после выполнения транзакций, содержащихся в этом блоке.

EVM является детерминированным, т.е. набор инструкций, выполняемых в любом определенном состоянии, безусловно приводит к следующему новому состоянию.

Это можно сравнить с игрой в шахматы. Шахматная доска (блокчейн Ethereum) имеет большое (в случае Ethereum - бесконечное) количество состояний, в которых может находиться игра. В игре есть правила, по которым можно совершать ходы (транзакции), и ограничения на то, кто может совершать эти действия.

Игроки делают ходы (отправляют транзакции), а игра (Ethereum) диктует правила, которые разрешены, и выполняет их, в результате чего после каждого хода (блока) формируется новое состояние доски (мира).

Что же тогда принимает на вход EVM?

Опкоды и байткоды

Для ответа на данный вопрос нам как раз и пригодятся опкоды и байткоды.

Как разработчик Ethereum или любого другого EVM-совместимого блокчейна вы обычно пишете смарт-контракты на Solidity. Solidity предназначен для чтения человеком, чтобы мы могли сосредоточиться на написании кода, а не на таких сложных вещах, как регистры, адреса памяти, стеки вызовов и т.д.

Однако EVM не может читать Solidity. Она понимает "байткод", то есть двоичный, машиночитаемый код.

В среде EVM этот байткод представляет собой серию "опкодов" EVM, каждый из которых является 256-битным словом, выполняющим определенную операцию в EVM.

Для разработчиков это означает, что нам нужно как-то преобразовать код нашего смарт-контракта из Solidity → Opcodes → Bytecode, чтобы он мог исполняться EVM. К счастью, существуют компиляторы, которые делают это за нас.

Рассмотрим пример этого процесса. Вот самый простой смарт-контракт на Solidity, который имеет базовые возможности чтения/записи/инициации событий.

Но тут есть проблема: EVM не может понять этот Solidity код, поэтому его нужно скомпилировать в байткод.

На примере компилятора Remix IDE, после компиляции, можно увидеть точные опкоды, в которые как раз преобразуется наш смарт-контракт. И также можно просматривать байткод, который генерируется на основе этих опкодов.

Ниже приведен опкод:

А тут показан байткод, полученный из приведенных выше опкодов:

Вы также можете сопоставить опкоды с байткодами, чтобы увидеть, какие именно инструкции содержатся в байткоде:

Но в чем смысл всего этого? Разве речь идет не о ZK-EVM? Почему мы вообще говорим об опкодах?

Каждый продукт ZK-EVM отличается от другого. Некоторые из них обеспечивают полную эквивалентность опкодов EVM, другие имеют лишь незначительные модификации некоторых опкодов, а некоторые имеют совершенно другой байткод.

Ethereum не рассчитан на "дружелюбность к ZK", и, как правило, чем ты ближе к исходному Ethereum коду, тем сложнее и более трудоемко генерировать ZK-доказательства.

В августе 2022 года Виталик сделал запись в блоге, чтобы классифицировать эти различные ZK-EVM решения. Он описывает различные типы EVM в зависимости от их совместимости и времени генерации (производительности) ZK-доказательств.

Он выделяет 4 (с половиной) различных категорий, к которым сегодня относятся все решения с ZK-EVM:

Тип 1

ZK-EVM первого типа полностью эквивалентны Ethereum, т.е. они не изменяют ни одной части системы Ethereum в целях облегчения генерации доказательств.

Генерация ZK-доказательств в такой системе занимает много времени (например, несколько часов).

Тип 2

Тип 2 полностью эквивалентен EVM, но меняет некоторые внутренние представления, например - способ хранения состояния цепочки блоков, с целью ускорения времени формирования ZK-докозательств.

Тип 2,5

Тип 2.5 полностью эквивалентен EVM, за исключением того, что увеличивает газовые затраты на некоторые операции, чтобы "значительно улучшить время подтверждения транзакций в самых неблагоприятных обстоятельствах".

Тип 3

Тип 3: Почти полностью EVM-эквивалентные ZK-EVM решения, которые имеют незначительные отличия, направленные на ускорение времени подтверждения транзакций и упрощения EVM разработки.

Тип 4

Тип 4: ZK-EVM решения, эквивалентные отдельному языку программирования высокого уровня, которые компилируют исходный код смарт-контрактов в язык, дружественный ZK-SNARK. Это приводит к ускорению формирования ZK-подтверждений, но потенциально может привести к несовместимости и ограничениям.

Важным моментом является то, что время, затрачиваемое ZK-EVM на отправку доказательств достоверности в Ethereum L1, определяет время, в течение которого пользователь не может перевести (сбриджить) свои средства обратно.

Например, если генерация доказательств занимает несколько часов, то пользователь не сможет перевести (сбриджить) свои средства обратно на L1 в течение нескольких часов. Этот процесс генерации доказательств является лишь одним из многих этапов, необходимых для завершения транзакций на L1.

1. Taiko

Taiko - ZK-EVM первого типа, находящийся в стадии тестнета.

Taiko в точности повторяет поведение Ethereum: использует те же хэш-функции, цены на газ, алгоритмы шифрования и т.д. (за исключением 2 EIP).

Как и ожидалось, все, что автор выполнял, вело себя так же, как и в случае с Ethereum. Удалось без труда развернуть простой Solidity смарт-контракт и создать NFT коллекцию, используя многим известный сервис @thirdweb.

Недостатком ZK-EVM первого типа является то, что когда все точно так же, как в Ethereum, даже внутри - для получения подтверждений требуется очень много времени. Это означает, что процесс возврата ETH из Taiko L2 в Ethereum L1 занял несколько часов:

2. Linea

Line - в настоящее время ZK-EVM 3-го типа:

• Не подтверждает (пока) все опкоды или прекомпиляции кода.
• Представляет внутреннее состояние цепочки блоков иначе, чем Ethereum. Например, использует другую функцию хэширования

Развернутый байткод такой же, как у Ethereum:

Здесь процесс снова прошел гладко, удалось легко развернуть оба смарт-контракта и взаимодействовать с ними.

Это было то же самое поведение, что и в Ethereum: развертывание смарт-контрактов, взаимодействие с ними, минт NFT и т.д. с использованием существующих инструментов и кошельков.

На момент данного тестирования блокчейнов (17 июля 2023) в Linea не было пользовательского UI интерфейса для моста. Поэтому опыт бриджа оказался несколько затруднительным: пришлось напрямую вызывать функции смарт-контракта моста.

Согласно документации, мост L2 -> L1 для ETH обычно занимает ~15 минут, но в данном случае это заняло несколько часов.

3. Polygon ZK-EVM

Polygon ZK-EVM - ZK-EVM 3-го типа, который находится в мейннете с конца марта 2023.

В документации Polygon zkEVM перечислены все существующие различия между EVM и zkEVM:

Байткод, который вы развертываете, такой же, как и в Ethereum, что опять же упрощает развертывание и взаимодействие с создаваемыми в рамках нашего теста смарт-контрактами.

Виталик сказал: "Polygon zkEVM имеет уникальную конструкцию, в которой они ZK-верифицируют свой собственный внутренний язык под названием zkASM":

Команда инженеров Polygon также заявила, что в ближайшее время они завершат оставшиеся прекомпиляции для перехода на тип 2, а также улучшат время генерации и вывода доказательств.

Мост с мейннетом zkEVM прошел без проблем; весь процесс бриджа с L2 -> L1 занял ~1 час.

4. Scroll

Scroll - третий и последний ZK-EVM 3-го типа, в настоящее время находится в стадии тестнета.

В документации Scroll также указаны различия между их ZK-EVM и EVM Ethereum:

Как и в случае с другими ZK_EVM 3-го типа, все снова прошло гладко. Удалось легко развернуть свой Solidity смарт-контракт, создать свою коллекцию NFT и повзаимодействовать с ними обоими.

По оценкам, возврат средств из L2 в L1 занимает "от 10 минут до нескольких часов".

5. zkSync Era

zkSync Era - ZK-EVM 4-го типа.

Era несколько отличается от других ZK-EVM, рассмотренных ранее. Байткод смарт-контракта, который разворачивается для их ZK-EVM, не такой, как у Ethereum. Это позволяет их ZK-EVM иметь уникальные особенности.

Одним из таких уникальных предложений является нативная абстракция счетов. Как пример такой абстракции, получается создавать приложения без необходимости подтверждения транзакций в кошельке и без затрат газа.

(кому будет интересно, можно дополнительно погуглить EIP-4337 account abstraction)

Однако эти базовые изменения в предоставляемых возможностях сопровождаются различиями в среде разработки. Но, как объяснил Виталик, это все равно позволяет работать с теми же высокоуровневыми языками, такими как Solidity.

Из-за этих отличий от EVM, Era поставляется с полным набором инструментов и готовых наработок кода (лучших практик), которые вы можете использовать как разработчик. Поэтому от разработчика потребуются относительно небольшие изменения в процессе разработки, чтобы создать код специально для Era.

Например, пришлось установить и настроить среду Hardhat с пользовательскими Расширениями zkSync для создания байткода, который можно развернуть на Era ZK-EVM:

Очень интересно то, что в процессе компиляции получается совершенно другой байткод, чем тот, который мы видели в предыдущих сетях, рассмотренных в этой статье. Это видно на скриншоте ниже:

Недавно @thirdweb добавили флаг (отметку) "--zksync", который можно использовать для обработки и развертывания байткода zkSync вместо обычного байткода.

Таким образом, изменения небольшие, но все же некоторые отличия в среде разработки есть.

С учетом этого опыт разработки вцелом остался прежним. Автору снова удалось легко развернуть два своих смарт-контракта, взаимодействовать с ними и вывести средства через мост из L2 -> L1.

В настоящее время, в целях безопасности, существует 24-часовая задержка на вывод средств из мэйннета Era в Ethereum L1.

6. Kakarot

Еще один проект, над которым ведется работа в направлении получения ZK-EVM типа 2.5 - это @KakarotZkEvm, который финансируется в том числе Виталиком.

Тестовая сеть еще не выпущена, но планируется к выпуску позднее в 2023 году.

Итоговые затраты по созданию и взаимодействию с двумя смарт-контрактами у автора составили:

Но не столько в целях соревнования, сколько вцелом для Web3 пространства, полезны и нужны разрабатываемые ZK-EVM решения.

У Виталика также есть "теория мульти-подтверждений", согласно которой rollups могут работать совместно, в целях повышения безопасности Ethereum в целом.

Ссылка на выступление Виталика: https://youtu.be/6hfVzCWT6YI

Думаю, что мы все хотим, чтобы Ethereum преуспел, а "переход к масштабированию L2" - это один из трех технических переходов, которые, по мнению Виталика, должен пройти Ethereum.

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