Различные типы zkEVMs
Перевод
Это вольный перевод статьи В. Бутерина: vitalik.ca/general/2022/08/04/zkevm.html
Благодарности
Виталик выражает особую благодарность командам 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, либо для того, чтобы значительно упростить проверку, либо для создания ZK-роллапов, которые (почти) эквивалентны тем, что предоставляет Ethereum, но гораздо более масштабируемы.
Но есть тонкие различия между этими проектами, и то, на какие компромиссы они идут между практичностью и скоростью. В этой заметке попытаемся описать таксономию различных "типов" эквивалентности EVM, а также то, какие преимущества и издержки несут попытки достичь каждого типа.
https://vitalik.ca/images/zkevm/chart.png
Тип 1 (полностью эквивалентный Ethereum)
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 ASICs.
Версия ZK-EVM Community Edition (созданная участниками сообщества, включая Privacy and Scaling Explorations, команду Scroll, Taiko и других) - это ZK-EVM уровня 1.
Тип 2 (полностью эквивалентный EVM)
ZK-EVM второго типа стремятся быть в точности похожими на EVM, но не совсем эквивалентными Ethereum (здесь ==, а не ===). То есть, они выглядят точно так же, как Ethereum "изнутри", но имеют некоторые отличия снаружи, особенно в структурах данных, таких как структура блока и дерево состояний.
Цель состоит в том, чтобы быть полностью совместимыми с существующими приложениями, но внести некоторые незначительные изменения в Ethereum, чтобы упростить разработку и ускорить генерацию доказательств.
Преимущество: полная эквивалентность на уровне Виртуальной Машины.
ZK-EVM второго типа вносят изменения в структуры данных, которые хранят такие вещи, как состояние Ethereum. К счастью, это структуры, к которым сам EVM не может получить прямой доступ, поэтому приложения, работающие с Ethereum, почти всегда будут работать на ZK-EVM типа 2.
Вы не сможете использовать клиенты исполнения Ethereum как таковые, но вы сможете использовать их с некоторыми модификациями, и вы по-прежнему сможете использовать инструменты отладки EVM и большинство других инструментов.
Существует небольшое количество исключений. Одна несовместимость возникает для приложений, которые проверяют доказательства Меркла в блоках Ethereum для проверки утверждений об исторических транзакциях, поступлениях или состоянии (например, так иногда поступают мосты).
ZK-EVM, заменяющая Keccak другой хэш-функцией, нарушит эти доказательства.
Однако обычно не рекомендую создавать приложения таким образом, потому что будущие изменения Ethereum (например, деревья Веркле) сломают такие приложения даже на самом Ethereum. Лучшей альтернативой было бы, если бы Ethereum сам добавил прекомпиляцию доступа к истории с защитой от будущих изменений.
Недостаток: улучшенное, но все ещё медленное время работы провера.
ZK-EVM второго типа обеспечивают более быстрое время работы провера по сравнению с первым типом в основном за счёт удаления частей стека Ethereum, которые полагаются на ненужную сложную и недружественную к ZK криптографию.
ZK-EVM второго типа могут вместо этого использовать другую хэш-функцию, например, Poseidon. Ещё одна естественная модификация - изменение дерева состояний для хранения хэша кода и keccak, что устраняет необходимость проверки хэшей для обработки опкодов EXTCODEHASH и EXTCODECOPY.
Эти модификации значительно улучшают время работы провера, но они не решают всех проблем. Медленность от необходимости доказывать EVM как есть, со всеми неэффективностями и ZK-недружелюбием, присущими EVM, все еще остается.
Один простой пример - память: поскольку MLOAD может читать любые 32 байта, включая "невыровненные" куски (где начало и конец не кратны 32), MLOAD нельзя просто интерпретировать как чтение одного куска; скорее, может потребоваться чтение двух последовательных кусков и выполнение битовых операций для объединения результата.
Проект ZK-EVM компании Scroll работает над созданием ZK-EVM типа 2, как и проект Poligon Hermez. Тем не менее, ни тот, ни другой проект ещё не дошли до конца; в частности, многие более сложные прекомпиляции ещё не реализованы. Поэтому на данный момент оба проекта лучше рассматривать как тип 3.
Тип 2.5 (эквивалент EVM, за исключением затрат на газ)
Одним из способов значительного улучшения времени работы провера в худшем случае является значительное увеличение газовых затрат на определённые операции в EVM, которые очень трудно проверить ZK.
Изменение газовых затрат может снизить совместимость инструментария разработчика и сломать несколько приложений, но это обычно считается менее рискованным, чем "более глубокие" изменения EVM. Разработчики должны следить за тем, чтобы не требовать больше газа в транзакции, чем помещается в блок, и никогда не делать вызовы с жёстко заданным количеством газа (это уже давно является стандартным советом для разработчиков).
Альтернативный способ управления ограничениями ресурсов - просто установить жёсткие ограничения на количество вызовов каждой операции. Это проще реализовать в схемах, но это гораздо менее приятно для предположений по безопасности EVM. Назвал бы этот подход Типом 3, а не Типом 2.5.
Тип 3 (почти EVM-эквивалент)
ZK-EVM типа 3 практически эквивалентны 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 (языковой эквивалент высокого уровня)
Система типа 4 работает следующим образом: берётся исходный код смарт-контракта, написанный на языке высокого уровня (например, Solidity, Vyper или каком-либо промежуточном, на котором компилируются оба языка), и компилируется в язык, который явно разработан так, чтобы быть дружественным к ZK-SNARK.
Преимущество: очень быстрое время работы провера.
Существует много накладных расходов, которых можно избежать, не проводя ZK-тестирование всех различных частей каждого шага выполнения EVM, а начиная непосредственно с кода более высокого уровня.
В этом посте описываю это преимущество всего одним предложением (по сравнению с большим списком недостатков, связанных с совместимостью), но это не следует воспринимать как оценочное суждение! Компиляция из языков высокого уровня напрямую действительно может значительно снизить затраты и помочь децентрализации, так как это облегчает работу проверяющего.
Недостаток: больше несовместимости.
"Нормальное" приложение, написанное на Vyper или Solidity, можно скомпилировать, и оно будет "просто работать", но есть несколько важных аспектов, по которым очень многие приложения не являются "нормальными":
Контракты могут иметь не те же адреса в системе Type 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 могут легко начать с более высоких типов и со временем перейти к более низким (или наоборот). Например:
- 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.