Виталик: Будущее различных типов ZK-EVM

Оригинальное название: 《Разные типы ZK-EVM》

Автор: Vitalik

Составитель: Block unicorn, Foresight News

В последнее время было много громких объявлений о проектах «ZK-EVM». Polygon открыл свой проект ZK-EVM, ZKSync представил свой план ZKSync 2.0, а относительно новый Scroll также недавно выпустил свой ZK-EVM. Также продолжаются усилия команд, занимающихся исследованием конфиденциальности и масштабируемости, таких как команда Николаса Лиошона и другие, от альфа-компилятора языка Cairo, совместимого с zk, до Starkware, конечно, есть некоторые проекты, которые я мог бы пропустить.

Основная цель всех этих проектов одинакова: использовать технологию ZK-SNARK для создания криптографических доказательств выполнения транзакций, аналогичных Ethereum, чтобы либо упростить верификацию самой цепочки Ethereum, либо построить zk rollup, который предоставляет (приблизительно) тот же контент, что и Ethereum, но с большей масштабируемостью. Однако между этими проектами существуют тонкие различия, а также компромиссы между их практичностью и скоростью. Эта статья попытается описать различные «типы» эквивалентности EVM и попытаться реализовать преимущества и затраты каждого типа.

Обзор (в виде диаграммы)

Тип 1 (полное соответствие Ethereum)

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

Преимущества: идеальная совместимость

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

Тип 1: ZK-EVM — это то, что нам в конечном итоге нужно, чтобы сделать первый уровень Ethereum более масштабируемым. В долгосрочной перспективе изменения, протестированные в ZK-EVM типа 2 или типа 3, могут быть внедрены в сам Ethereum, но такое переосмысление связано со своей сложностью.

Тип 1: ZK-EVM также является идеальным выбором для агрегирования, поскольку они позволяют повторно использовать большое количество инфраструктуры. Например, клиент выполнения Etherum может использоваться как есть для генерации и обработки ROLLUP блоков (или, по крайней мере, как только будет реализован вывод, они могут быть повторно использованы, и эта функция может быть повторно использована для поддержки ETH, помещенного в ROLLUP), поэтому инструменты управления ресурсами блоков, производства блоков и т.д. очень легко повторно использовать.

Недостатки: время верификации

Ethereum изначально не был спроектирован с учетом дружелюбия к zk, поэтому многие части протокола Ethereum требуют значительных вычислений для проверки zk. Цель типа 1 — полностью воспроизвести Ethereum, поэтому у него нет способов смягчить эти неэффективности. В настоящее время доказательство блоков Ethereum требует много часов для генерации. Эта ситуация может быть смягчена за счет умной инженерии для масштабного параллелизма верификаторов или, в долгосрочной перспективе, с помощью специализированных интегральных схем ZK-SNARK.

Кто строит?

Команда ZK-EVM, занимающаяся конфиденциальностью и масштабируемостью, строит ZK-EVM типа 1.

Тип 2 (полное соответствие EVM)

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

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

Преимущества: полное равенство на уровне виртуальной машины

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

Но есть и некоторые исключения. Для приложений, которые проверяют исторические блоки Ethereum с помощью доказательства Меркла для проверки заявлений о исторических транзакциях, квитанциях или состоянии, возникает несовместимость (например, мосты иногда делают это). Замена Keccak на ZK-EVM с помощью другой хеш-функции сломает эти доказательства. Тем не менее, я обычно рекомендую не строить приложения таким образом, поскольку будущие изменения в Ethereum (например, Verkle Trees) даже на самом Ethereum могут сломать такие приложения. Лучшей альтернативой для самого Ethereum будет добавление надежной предкомпиляции для доступа к истории в будущем.

Недостатки: улучшенное время верификации, но все еще медленно

Тип 2 ZK-EVM предлагает более быстрое время верификации, чем тип 1, в основном за счет удаления зависимостей от ненужной сложности и недружелюбного ZK шифрования в стеке Ethereum. В частности, они могут изменить Keccak Ethereum и основанные на RLP деревья Меркла Патриции, возможно, также изменят структуру блоков и получения. Тип 2 ZK-EVM может использовать разные хеш-функции, например, Poseidon. Другим естественным изменением является изменение дерева состояния для хранения хешей кода и keccak, что устраняет необходимость верификации хешей для обработки операций EXTCODEHASH и EXTCODECOPY.

Эти изменения значительно улучшают время верификации, но они не решают всех проблем. Из-за врожденной неэффективности EVM и его недружелюбия к zk процесс доказательства EVM как есть все еще очень медленный. Простой пример — память: поскольку MLOAD может читать любые 32 байта, включая «невыравненные» блоки (где начало и конец не кратны 32), MLOAD не может просто интерпретироваться как чтение одного блока; наоборот, может потребоваться чтение двух последовательных блоков и выполнение битовых операций для объединения результатов.

Кто строит?

Проект ZK-EVM Scroll движется в сторону ZK-EVM типа 2, как и Polygon Hermez. То есть, оба проекта еще не завершены (не завершили работу над ZKEVM); в частности, многие более сложные предкомпиляции еще не реализованы. Поэтому в настоящее время оба проекта лучше всего рассматривать как тип 3.

Тип 2.5 (эквивалентен EVM, не включая газовые сборы)

Значительным способом улучшить время верификации в худшем случае является значительное увеличение стоимости операций, которые трудно доказать в EVM. Это может включать предкомпиляции, операции KECCAK, а также определенные соглашения о вызовах или доступ к памяти, хранилищу или восстановлению.

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

Тип 3 (почти эквивалентен EVM)

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

Преимущества: легче строить, время верификации быстрее

Тип 3 ZK-EVM может удалить некоторые функции, которые особенно трудно реализовать в ZK-EVM. Здесь предкомпиляции обычно находятся на верхней части списка; кроме того, тип 3 ZK-EVM иногда имеет тонкие различия в том, как обрабатывается код контрактов, память или стек.

Недостатки: больше несовместимости

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

Кто строит?

Scroll и Polygon в настоящее время находятся в форме типа 3, хотя со временем они надеются улучшить совместимость. У Polygon есть уникальный дизайн, они используют ZK для проверки своего внутреннего языка zkASM и используют zkASM для реализации интерпретации кода ZK-EVM. Несмотря на такие детали реализации, я все равно называю это настоящим Type3ZK-EVM; он все еще может проверять код EVM, просто использует некоторую другую внутреннюю логику для этого.

Сегодня ни одна команда ZK-EVM не хочет стать типом 3; тип 3 — это просто переходный этап, пока не будет завершена сложная работа по добавлению предкомпиляций, и проект может перейти к типу 2.5. Тем не менее, в будущем ZK-EVM типа 1 или типа 2 могут добровольно стать ZK-EVM типа 3, добавив новые предкомпиляции, дружелюбные к ZK-SNARK, чтобы предоставить разработчикам функции с низким временем верификации и затратами на газ.

Тип 4 (эквивалентен языкам высокого уровня)

Тип 4 системы работает так, что принимает исходный код смарт-контрактов, написанный на языках высокого уровня (например, SOLIDITY, VYPER или некотором промежуточном языке, в который компилируются оба), и компилирует его в язык, явно разработанный для дружелюбия к ZK-snark.

Преимущества: время верификации очень быстрое

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

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

Недостатки: больше несовместимости

«Нормальное» приложение, написанное на Vyper или Solidity, может быть скомпилировано и будет «нормально работать», но есть некоторые важные аспекты, из-за которых многие приложения не «нормально работают»:

• Адреса контрактов в системе типа 4 могут отличаться от их адресов в EVM, поскольку адреса, согласованные CREATE2, зависят от точного байт-кода. Это ломает приложения, которые зависят от еще не развернутых «контрактов контрфактов», кошельков ERC-4337, одиночек EIP-2470 и многих других приложений.
• Ручной байт-код EVM труднее использовать. Для повышения эффективности многие приложения используют ручной байт-код EVM в некоторых частях. Система типа 4 может не поддерживать это, хотя есть некоторые способы реализовать ограниченную поддержку байт-кода EVM для удовлетворения этих случаев использования, не прилагая усилий для того, чтобы стать полноценным Type3ZK-EVM.
• Многие инструменты отладки не могут продолжать, поскольку эти инструменты работают на байт-коде EVM. То есть, это ограничение смягчается за счет большего доступа к инфраструктуре отладки из «традиционных» высокоуровневых или промежуточных языков (например, LLVM).

Разработчики должны быть внимательны к этим вопросам.

Кто строит?

ZKSync является системой типа 4, хотя со временем она может увеличить совместимость с байт-кодом EVM. Проект Warp от NetherMind разрабатывает компилятор из Solidity в Cairo от Starkware, который сделает StarkNet фактически системой типа 4.

Будущее различных типов ZK-EVM

Эти типы не являются явно «лучше» или «хуже» других типов. Скорее, они представляют собой разные точки в пространстве компромиссов: типы с меньшей сложностью кодирования более совместимы с существующей инфраструктурой, но медленнее; типы с большей сложностью кодирования менее совместимы с существующей инфраструктурой, но быстрее. В целом, все эти типы исследуются, что полезно для этой области.

• ZK-EVM может начать с типа 3, решив не включать некоторые функции, которые особенно трудно доказать ZK. Позже они могут добавить эти функции с течением времени и перейти к типу 2.
• ZK-EVM может начать с типа 2 и затем стать гибридным типом 2/типа 1 ZK-EVM, предоставив возможность работать в полностью совместимом с Ethereum режиме или использовать модифицированное дерево состояния, которое может быстрее генерировать доказательства. Scroll рассматривает возможность развития в этом направлении.
• Системы, начинающиеся с типа 4, могут со временем стать типом 3, поскольку позже будет добавлена возможность обработки кода EVM (хотя разработчиков по-прежнему призывают компилировать непосредственно из языков высокого уровня, чтобы снизить затраты и время верификации).
• Если сам Ethereum примет свои изменения, чтобы стать более дружелюбным к ZK, то ZK-EVM типа 2 или типа 3 могут стать ZK-EVM типа 1.
• ZK-EVM типа 1 или типа 2 могут стать ZK-EVM типа 3, добавив предкомпиляции для проверки кода на языках, дружелюбных к ZK-SNARK. Это позволит разработчикам делать выбор между совместимостью с Ethereum и скоростью, что будет типом 3, поскольку это нарушает идеальную эквивалентность EVM, но с практической точки зрения будет иметь многие преимущества типа 1 и типа 2. Основным недостатком может быть то, что некоторые инструменты для разработчиков не понимают настраиваемые предкомпиляции ZK-EVM, хотя это можно исправить: инструменты для разработчиков могут добавить поддержку общего предкомпилированного формата, включая эквиваленты кода EVM.

Лично я надеюсь, что со временем все станет типом 1, улучшая ZK-EVM и сам Ethereum, чтобы сделать его более подходящим для ZK-Snark. В таком будущем у нас будет несколько реализаций ZK-EVM, которые можно использовать как для ZK rollups, так и для верификации самого Ethereum. Теоретически Ethereum не обязательно стандартизировать единую реализацию ZK-EVM для использования L1; разные клиенты могут использовать разные доказательства, и мы продолжаем извлекать выгоду из избыточности кода.

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