ZK-EVM: Эфир, Виталик, три ZK

За основу текущей статьи, взята статья Виталика Бутерина о ZK-EVM.

Ранее в канале, были рассмотрены несколько проектов-будущих гемов, основанных на технологии ZK (доказательства с нулевым разглашением).

Какие это проекты?

Начнем от начала!

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

Так что же такое ZK-EVM и как она помогает сделать Ethereum дешевле и эффективнее в использовании?

Понимание виртуальной машины Ethereum

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

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

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

Но у Ethereum и, следовательно, у EVM есть одна большая проблема: его нужно масштабировать! Пропускная способность Ethereum слишком низкая, а транзакции стоят слишком дорого. Так что же с этим делать?

Мощность ZK-EVM

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

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

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

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

Виталик о различных ZK-EVM

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

Здесь будет предпринята попытка описать различные «типы» эквивалентности EVM, а также каковы преимущества и издержки попыток достижения каждого типа.

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

Тип 1 (полностью эквивалентен Ethereum)

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

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

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

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

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

Недостаток: время доказывания

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

Тип 2 (полностью эквивалентен EVM)

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

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

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

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

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

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

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

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

*Прувер (Prover) - это генератор доказательств для транзакций.

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

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

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

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

Преимущество: проще в сборке и меньше времени прувера

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

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

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

Сегодня ни одна команда 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.
• Рукописный байт-код EVM сложнее использовать. Многие приложения используют рукописный байт-код EVM в некоторых частях для повышения эффективности. Системы типа 4 могут не поддерживать его, хотя есть способы реализовать ограниченную поддержку байт-кода EVM для удовлетворения этих вариантов использования, не прилагая усилий для того, чтобы стать полноценным ZK-EVM типа 3.
• Большая часть инфраструктуры отладки не может быть перенесена , потому что такая инфраструктура работает с байт-кодом EVM. Тем не менее, этот недостаток смягчается более широким доступом к инфраструктуре отладки из «традиционных» языков высокого уровня или промежуточных языков (например, LLVM).

Будущее типов ZK-EVM

Типы не являются однозначно «лучше» или «хуже» других типов. 

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

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

• ZK-EVM может начаться как тип 3, решив не включать в себя некоторые функции, которые особенно сложно проверить с помощью ZK. Позже они могут добавлять эти функции с течением времени и переходить к типу 2.
• ZK-EVM может начинаться как тип 2, а затем стать гибридным ZK-EVM Типа 2/Типа 1, обеспечивая возможность работы либо в режиме полной совместимости с 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.

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

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

Заключение

Рассмотренные ранее проекты, такие как Starknet, zkSync, Scroll на шкале Виталика, можно распределить на следующие ступени:

Scroll относится к типу 3 -> стремится к типу 2.5/2.

zkSync, Starknet относятся к типу 4 -> стремятся к типу 3.

Как и сказал Виталик, разделение на типы весьма условно: между подобными проектами есть тонкие различия и компромиссы между практичностью и скоростью.

Это просто набор компромиссов. Одни компромиссы приближают к идеальному целевому типу 1 (полностью эквивалентен Ethereum), другие - нет.

В тоже время, можно сказать, что проект Scroll наиболее технически совершенен, относительно эталона.

Подготовлено каналом SMART INVESTOR

Источники (публичные данные из Интернет)