Особая благодарность командам PSE, Polygon Hermez, Zksync, Scroll, Matter Labs и Starkware за обсуждение и рецензирование.

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

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

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

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

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

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

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

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

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

Кто его строит?

Команда Privacy and Scaling Explorations team ZK-EVM занимается созданием ZK-EVM типа 1.

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

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

Преимущество: совершенная эквивалентность на уровне ВМ

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

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

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

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

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

Кто его строит?

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

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

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

Альтернативный способ управления ограничениями ресурсов - просто установить жесткие ограничения на количество вызовов каждой операции. Это проще реализовать в схемах, но это гораздо менее приятно для предположений о безопасности EVM. Я бы назвал этот подход Типом 3, а не Типом 2.5.

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

Преимущество: проще построить и быстрее проверить.

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

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

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

Кто строит его?

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

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

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

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

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

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

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

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

• Контракты могут иметь не те же адреса в системе типа 4, что и в EVM, поскольку адреса контрактов CREATE2 зависят от точного байткода. Это нарушает работу приложений, которые полагаются на еще не развернутые "контрфактические контракты", кошельки ERC-4337, синглтоны EIP-2470 и многие другие приложения.

• Рукописный байткод EVM сложнее в использовании. Многие приложения используют рукописный байткод EVM в некоторых частях для повышения эффективности. Системы типа 4 могут не поддерживать его, хотя есть способы реализовать ограниченную поддержку байткода EVM для удовлетворения этих сценариев использования, не прибегая к усилиям по превращению в полноценный ZK-EVM типа 3.

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

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

Кто его строит?

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

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

Кроме того, проекты ZK-EVM могут легко начать с более высоких типов и со временем перейти к более низким (или наоборот). Например:

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

• ZK-EVM может начинаться как Тип 2, а позже стать гибридом Тип 2 / Тип 1 ZK-EVM, предоставляя возможность работать либо в режиме полной совместимости с Ethereum, либо с модифицированным деревом состояний, которое может быть доказано быстрее. Компания Scroll рассматривает возможность движения в этом направлении.

• То, что начинается как система типа 4, со временем может стать типом 3, добавив возможность обрабатывать код EVM (хотя разработчикам по-прежнему будет рекомендовано компилировать непосредственно из языков высокого уровня, чтобы сократить расходы и время на доказательство).

• ZK-EVM типа 2 или 3 может стать ZK-EVM типа 1, если Ethereum сам примет его модификации в попытке стать более дружественным к ZK.

• 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, так и для проверки самой цепочки Ethereum. Теоретически, Ethereum нет необходимости стандартизировать единую реализацию ZK-EVM для использования в L1; разные клиенты могут использовать разные доказательства, так что мы по-прежнему получаем выгоду от избыточности кода.

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

Оригинал статьи:

https://vitalik.ca/general/2022/08/04/zkevm.html

Перевод сделал skyc1e#4943 (@skyyyc1e)

Особая благодарность командам PSE, Polygon Hermez, Zksync, Scroll, Matter Labs и Starkware за обсуждение и рецензирование.

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

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

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

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

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

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

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

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

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

Кто его строит?

Команда Privacy and Scaling Explorations team ZK-EVM занимается созданием ZK-EVM типа 1.

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

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

Преимущество: совершенная эквивалентность на уровне ВМ

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

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

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

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

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

Кто его строит?

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

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

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

Альтернативный способ управления ограничениями ресурсов - просто установить жесткие ограничения на количество вызовов каждой операции. Это проще реализовать в схемах, но это гораздо менее приятно для предположений о безопасности EVM. Я бы назвал этот подход Типом 3, а не Типом 2.5.

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

Преимущество: проще построить и быстрее проверить.

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

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

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

Кто строит его?

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

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

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

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

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

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

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

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

• Контракты могут иметь не те же адреса в системе типа 4, что и в EVM, поскольку адреса контрактов CREATE2 зависят от точного байткода. Это нарушает работу приложений, которые полагаются на еще не развернутые "контрфактические контракты", кошельки ERC-4337, синглтоны EIP-2470 и многие другие приложения.

• Рукописный байткод EVM сложнее в использовании. Многие приложения используют рукописный байткод EVM в некоторых частях для повышения эффективности. Системы типа 4 могут не поддерживать его, хотя есть способы реализовать ограниченную поддержку байткода EVM для удовлетворения этих сценариев использования, не прибегая к усилиям по превращению в полноценный ZK-EVM типа 3.

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

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

Кто его строит?

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

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

Кроме того, проекты ZK-EVM могут легко начать с более высоких типов и со временем перейти к более низким (или наоборот). Например:

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

• ZK-EVM может начинаться как Тип 2, а позже стать гибридом Тип 2 / Тип 1 ZK-EVM, предоставляя возможность работать либо в режиме полной совместимости с Ethereum, либо с модифицированным деревом состояний, которое может быть доказано быстрее. Компания Scroll рассматривает возможность движения в этом направлении.

• То, что начинается как система типа 4, со временем может стать типом 3, добавив возможность обрабатывать код EVM (хотя разработчикам по-прежнему будет рекомендовано компилировать непосредственно из языков высокого уровня, чтобы сократить расходы и время на доказательство).

• ZK-EVM типа 2 или 3 может стать ZK-EVM типа 1, если Ethereum сам примет его модификации в попытке стать более дружественным к ZK.

• 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, так и для проверки самой цепочки Ethereum. Теоретически, Ethereum нет необходимости стандартизировать единую реализацию ZK-EVM для использования в L1; разные клиенты могут использовать разные доказательства, так что мы по-прежнему получаем выгоду от избыточности кода.

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

Оригинал статьи:

https://vitalik.ca/general/2022/08/04/zkevm.html

Перевод сделал skyc1e#4943 (@skyyyc1e)