*Примечание редактора: автор составил его на основе вводной статьи ZK-EVM, ранее написанной Виталиком, и подробно представил различные типы ZK-EVM и различия между ними. *
Около года назад группа ZK-EVM объявила, что собирается запустить тестовую сеть. Эти шаги пробудили любопытство сообщества Ethereum и вызвали дискуссию о нюансах, лежащих в основе таких терминов, как эквивалент Ethereum и эквивалентность EVM.
Для ясности Виталик написал важную статью под названием «Различные типы ЗК-ЭВМ», в которой различные ЗК-ЭВМ классифицируются на четыре типа и объясняются их различия.
Основная идея такова: тип 1 (например, Taiko) полностью эквивалентен Ethereum, а тип 4 (например, zkSync) превосходит других по эффективности генерации доказательств. Все остальные типы, Тип 2, Тип 2.5 и Тип 3, находятся между ними (например, Polygon zkEVM, Scroll, Linea).
Большинство ZK-EVM изначально относятся к типам 2.5 и 3, с некоторым намерением развиваться в сторону типа 1 или типа 2, хотя в этих проектах не предусмотрены конкретные сроки или обязательства для этого.
**В этой статье основное внимание уделяется различиям между типом 1 и типом 2/типом 2.5, а также описываются возможные последствия нарушения эквивалентности Ethereum. Мы также кратко коснемся других типов. **
Основная цель ZK-EVM — масштабировать Ethereum, то есть увеличить пропускную способность Ethereum, сохранив при этом другие его функции (безопасность, опыт разработчиков и т. д.). В идеале ZK-EVM должен уметь:
Демонстрирует выполнение немодифицированного собственного байт-кода (охватывающего 100% кодов операций Ethereum) в соответствии со спецификацией виртуальной машины Ethereum в Желтой книге.
Быстрое создание доказательств по низкой цене.
Позволяет на 100% повторно использовать инструменты и инфраструктуру, разработанные для Ethereum.
Разрешить повторное развертывание любого децентрализованного приложения Ethereum на ZK-EVM «как есть» («как есть» означает, что никаких изменений не требуется, никаких компромиссов).
Различия между типами ЗК-ЭВМ
В мире ZK-EVM различия в основном связаны с уровнем эквивалентности Ethereum/EVM, влиянием недружественных к ZK элементов на стоимость и скорость генерации доказательств, а также сложностью реализации схемы (например, построение виртуальной машины или состояние деревья).
Давайте проанализируем эти различия, особенно отличая Тип 1 от Типа 2/Типа 2,5. Мы также коснемся вариантов использования, наиболее подходящих для каждого типа.
При сравнении различных типов часто используют следующую таблицу:
Тем, кто не работает полный рабочий день в сфере ZK-EVM, эта таблица может показаться запутанной, поэтому давайте переведем эти термины на понятный язык и посмотрим:
Эта диаграмма дает более четкое представление о том, как на самом деле выглядит каждый тип, но она все же может быть немного неясной.Давайте полностью изучим мир ZK-EVM, объяснив каждый тип индивидуально.
Тип 1: эквивалент Эфириума
Виталик Бутерин:
«ZK-EVM типа 1 — это то, что нам в конечном итоге нужно, чтобы сделать сам уровень 1 Ethereum более масштабируемым».
Тип 1 означает отсутствие изменений в какой-либо части системы Ethereum, чтобы упростить создание доказательств. Отсутствие изменений в Ethereum означает отсутствие компромиссов с безопасностью, поскольку большинство криптографических примитивов (например, хэш-функций), инфраструктуры разработчиков (например, отладчиков) или цепной инфраструктуры (например, клиентов выполнения) уже 9 лет проходят полевые испытания.
ZK-EVM типа 1 ничего не заменяет: хеши, деревья состояний, деревья транзакций, предварительную компиляцию или любую другую логику консенсуса, все точно так же, как EVM основной сети.
Тип 1 — единственный тип, который может проверять саму цепочку Ethereum — от целых блоков до выполнения транзакций, смарт-контрактов и логики учетной записи.
Тип 2: эквивалент EVM
Тип 2 ускоряет создание доказательства и упрощает разработку схемы за счет удаления некоторых частей, не способствующих ZK. Однако из-за последствий этого это может усложнить разработку других частей ZK-rollup (например, программного обеспечения узла). Эти сложности могут быть вызваны несовместимостью между устоявшимися лучшими практиками и инструментами тестирования и внедряемыми изменениями (например, измененным деревом состояний).
*Примечание. Эквивалент Ethereum и эквивалент EVM — это не одно и то же. Хотя эквивалентность Ethereum означает, что ни одна часть Ethereum не была изменена, а это означает, что он полностью совместим со всеми децентрализованными приложениями Ethereum, эквивалентность EVM позволяет вносить изменения в структуры данных (например, структуры блоков или деревья состояний). *
Хотя эти изменения могут показаться незначительными, они влияют на совместимость Ethereum. Изменение структур данных может привести к несовместимости децентрализованных приложений Ethereum с ZK-EVM типа 2, особенно при проверке доказательств Меркла о прошлых транзакциях, квитанциях или состояниях (например, через цепные мосты).
Удалить недружественные элементы ЗК
Модификации Ethereum призваны упростить разработку и увеличить скорость генерации доказательств. Цель состоит в том, чтобы сократить те части Эфириума, которые полагаются на недружественную криптографию с нулевым разглашением. Говоря более техническим языком, части, которые требуют большого количества вентилей (операций сложения и умножения) из-за нелокальных областей (например, хеш-функций), большого количества мультискалярных умножений и/или быстрых преобразований Фурье (БПФ); или Просто та часть, которая требует большого количества манипуляций.
Конкретные примеры недружественных элементов с нулевым разглашением, которые ZK-EVM типа 2 может изменять:
Хэш-функция: в то время как Ethereum использует хеш-функцию Keccak, многие ZK-EVM используют хеш-функцию Poseidon, которая требует значительно меньшего количества вентилей. Например, оценим, сколько хэш-функций каждого типа можно вычислить в секунду (т.е. сравнение, демонстрирующее скорость генерации).
Хэш-функции Poseidon имеют значительные преимущества в скорости генерации доказательств.
Однако важно отметить, что новые криптографические примитивы не так популярны по сравнению с традиционными криптографическими примитивами, широко признанными сообществом. Хотя «Посейдон» может предложить скорость, проверенные в боях характеристики «Кечака» делают его более надежным и безопасным, поскольку он широко применяется.
Вот почему Keccak, несмотря на то, что он старше и принят более широким сообществом (в других отраслях, таких как системы безопасности или датчики в интеллектуальных устройствах), можно считать более проверенным и проверенным, чем Poseidon, который, в конце концов, находится в сообществе ZK. Новый хеш функции для создания и использования.
Деревья состояний для хранения данных: например, в то время как Ethereum использует деревья Меркла Патриции (с использованием хеширования Кекчака), некоторые ZK-EVM типа 2 выбирают разреженные деревья Меркла (с использованием хеширования Посейдона). Изменение дерева состояний может вызвать некоторые несовместимости. Например, дерево Меркла в Ethereum имеет разные типы узлов и использует RLP для кодирования данных, что сложно сделать в ZK.
Блочная структура: блоки содержат большой объем информации. Однако при изучении L2 нас интересует только ution_payload_header (т. е. хеш блока). На изображении ниже представлена структура (хэш блока) всех данных, содержащихся в ution_payload_header.
**Обратите внимание: изменение любого из этих компонентов нарушит эквивалентность Ethereum. **
Тип 2.5: эквивалент EVM, с учетом стоимости газа
ЗК-ЭВМ типа 2,5 увеличивает затраты газа на специфические операции, которые сложно доказать с помощью технологии ЗК в ЭВМ.
Учитывая ограничение газа на блок Эфириума (30 М газа), увеличение стоимости газа на код операции приводит к меньшему количеству кодов операций на блок. Следовательно, в блок можно включать менее сложные коды операций. Более простые коды операций позволяют уменьшить размер схем и ускорить создание доказательств.
газ — единица измерения работы.
Цены на коды операций рассчитываются в газе.
Коды операций определяют операции в инструкциях машинного языка.
Программа представляет собой статический список кодов операций. Выполнение программы — это трассировка выполнения.
Трассировка выполнения — это определенный упорядоченный список кодов операций, выполняемых программой.
Части, ZK которых трудно доказать, включают:
Коды операций Keccak и некоторые другие коды операций, зависящие от Keccak.
Предварительно скомпилированные: функции, доступные EVM. Некоторые из них предоставляют сложные или математически сложные задачи, например криптографические функции (например, blake 2 f или sha 256). Они выполняются не внутри EVM, а скорее как функции, жестко закодированные в клиенте выполнения и доступные для EVM с использованием вызовов по специальным адресам.
Доступ к памяти: например, увеличение размера слота памяти (например, Ethereum использует память с байтовым выравниванием, а Polygon zkEVM использует 32-байтовые слоты памяти). Чтобы сделать это изменение возможным, пришлось изменить внутреннюю логику некоторых кодов операций (например, MLOAD).
Хранение (т.е. изменение хэш-функции или дерева состояний, как описано выше).
Изменение стоимости газа может снизить совместимость инструментов разработчика и привести к поломке некоторых децентрализованных приложений. Например, смарт-контракт, который часто выполняет коды операций с увеличением затрат на газ, может превысить лимит газа на блок и не выполниться.
Тип 3: Почти эквивалентен EVM
ZK-EVM типа 3 исключает предварительную компиляцию, неприменимую к ZK, и может регулировать доступ к памяти и хранилищу.
dApps, которые использовали удаленные предварительно скомпилированные приложения, необходимо будет переписать. В необычных случаях различия в том, как пограничные случаи обрабатываются ZK-EVM типа 3 и исходной EVM, могут потребовать внесения изменений в dApp.
Тип 4 (эквивалент языка высокого уровня)
Тип 4 уже далеко от ЭВМ.
Исходный код смарт-контракта, написанный на языке высокого уровня (например, Solidity, Zinc), компилируется в промежуточное представление, генерируя коды операций, подходящие для виртуальных машин, дружественных к ZK.
Этот метод позволяет избежать создания доказательств ZK для каждого шага выполнения EVM, тем самым значительно сокращая работу по проверке.
Даже если контракт можно скомпилировать, потребуется дальнейшая работа, если dApp использует рукописный байт-код EVM.
*Для ZK-EVM типа 4 также требуются собственные инструменты разработчика (только на уровне кода операции), такие как отладчики и трассировщики.
В схеме ZK, подтверждающей траекторию выполнения, каждый шаг реализует ограничение, а стоимость каждого шага представляет собой сумму всех кодов операций. Таким образом, ZK-EVM типа 4 предназначен для использования как можно меньшего количества сложных кодов операций для оптимизации эффективности.
Стоит отметить, что пользовательские коды операций (коды операций, не предусмотренные в Ethereum) позволяют передавать новые функции, которые по умолчанию недоступны в Ethereum. Например, сделайте несколько вызовов для выполнения с помощью функции абстракции учетной записи или запустите кошелек со смарт-контрактом, используя готовое решение, такое как Argent.
Подведем итог
Разные типы ZK-EVM ставят в приоритет разные цели и характеристики. Тип 1 ориентирован на эквивалентность Ethereum, а тип 4 отдает приоритет эффективному генерированию доказательств. Другие типы находятся между этими крайностями, и многие протоколы ZK-EVM типов 2 и 3 объявили о своем намерении перейти на эквиваленты Ethereum.
Эти четыре типа классификации, возможно, не являются окончательным состоянием объединения ZK и в будущем могут быть подвергнуты дальнейшим изменениям. Например, некоторые ZK-EVM могут стать гибридными, тип 1/2 может разрабатывать решения типа 4 (с максимально возможной эффективностью) и предоставлять децентрализованным приложениям оба варианта, тогда как ZK-EVM типа 3 и 4 могут добавлять эквивалентную опцию Ethereum.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
От Тип1 до Тип4, каковы различия между различными типами ЗК-ЭВМ?
Автор оригинала| Лиза Аксельрод
Составлено | Odaily Planet Daily 0xAyA
*Примечание редактора: автор составил его на основе вводной статьи ZK-EVM, ранее написанной Виталиком, и подробно представил различные типы ZK-EVM и различия между ними. *
Около года назад группа ZK-EVM объявила, что собирается запустить тестовую сеть. Эти шаги пробудили любопытство сообщества Ethereum и вызвали дискуссию о нюансах, лежащих в основе таких терминов, как эквивалент Ethereum и эквивалентность EVM.
Для ясности Виталик написал важную статью под названием «Различные типы ЗК-ЭВМ», в которой различные ЗК-ЭВМ классифицируются на четыре типа и объясняются их различия.
Основная идея такова: тип 1 (например, Taiko) полностью эквивалентен Ethereum, а тип 4 (например, zkSync) превосходит других по эффективности генерации доказательств. Все остальные типы, Тип 2, Тип 2.5 и Тип 3, находятся между ними (например, Polygon zkEVM, Scroll, Linea).
Большинство ZK-EVM изначально относятся к типам 2.5 и 3, с некоторым намерением развиваться в сторону типа 1 или типа 2, хотя в этих проектах не предусмотрены конкретные сроки или обязательства для этого.
**В этой статье основное внимание уделяется различиям между типом 1 и типом 2/типом 2.5, а также описываются возможные последствия нарушения эквивалентности Ethereum. Мы также кратко коснемся других типов. **
Основная цель ZK-EVM — масштабировать Ethereum, то есть увеличить пропускную способность Ethereum, сохранив при этом другие его функции (безопасность, опыт разработчиков и т. д.). В идеале ZK-EVM должен уметь:
Различия между типами ЗК-ЭВМ
В мире ZK-EVM различия в основном связаны с уровнем эквивалентности Ethereum/EVM, влиянием недружественных к ZK элементов на стоимость и скорость генерации доказательств, а также сложностью реализации схемы (например, построение виртуальной машины или состояние деревья).
Давайте проанализируем эти различия, особенно отличая Тип 1 от Типа 2/Типа 2,5. Мы также коснемся вариантов использования, наиболее подходящих для каждого типа.
При сравнении различных типов часто используют следующую таблицу:
Тем, кто не работает полный рабочий день в сфере ZK-EVM, эта таблица может показаться запутанной, поэтому давайте переведем эти термины на понятный язык и посмотрим:
Эта диаграмма дает более четкое представление о том, как на самом деле выглядит каждый тип, но она все же может быть немного неясной.Давайте полностью изучим мир ZK-EVM, объяснив каждый тип индивидуально.
Тип 1: эквивалент Эфириума
Виталик Бутерин:
Тип 1 означает отсутствие изменений в какой-либо части системы Ethereum, чтобы упростить создание доказательств. Отсутствие изменений в Ethereum означает отсутствие компромиссов с безопасностью, поскольку большинство криптографических примитивов (например, хэш-функций), инфраструктуры разработчиков (например, отладчиков) или цепной инфраструктуры (например, клиентов выполнения) уже 9 лет проходят полевые испытания.
ZK-EVM типа 1 ничего не заменяет: хеши, деревья состояний, деревья транзакций, предварительную компиляцию или любую другую логику консенсуса, все точно так же, как EVM основной сети.
Тип 2: эквивалент EVM
Тип 2 ускоряет создание доказательства и упрощает разработку схемы за счет удаления некоторых частей, не способствующих ZK. Однако из-за последствий этого это может усложнить разработку других частей ZK-rollup (например, программного обеспечения узла). Эти сложности могут быть вызваны несовместимостью между устоявшимися лучшими практиками и инструментами тестирования и внедряемыми изменениями (например, измененным деревом состояний).
*Примечание. Эквивалент Ethereum и эквивалент EVM — это не одно и то же. Хотя эквивалентность Ethereum означает, что ни одна часть Ethereum не была изменена, а это означает, что он полностью совместим со всеми децентрализованными приложениями Ethereum, эквивалентность EVM позволяет вносить изменения в структуры данных (например, структуры блоков или деревья состояний). *
Хотя эти изменения могут показаться незначительными, они влияют на совместимость Ethereum. Изменение структур данных может привести к несовместимости децентрализованных приложений Ethereum с ZK-EVM типа 2, особенно при проверке доказательств Меркла о прошлых транзакциях, квитанциях или состояниях (например, через цепные мосты).
Удалить недружественные элементы ЗК
Модификации Ethereum призваны упростить разработку и увеличить скорость генерации доказательств. Цель состоит в том, чтобы сократить те части Эфириума, которые полагаются на недружественную криптографию с нулевым разглашением. Говоря более техническим языком, части, которые требуют большого количества вентилей (операций сложения и умножения) из-за нелокальных областей (например, хеш-функций), большого количества мультискалярных умножений и/или быстрых преобразований Фурье (БПФ); или Просто та часть, которая требует большого количества манипуляций.
Конкретные примеры недружественных элементов с нулевым разглашением, которые ZK-EVM типа 2 может изменять:
Хэш-функции Poseidon имеют значительные преимущества в скорости генерации доказательств.
Однако важно отметить, что новые криптографические примитивы не так популярны по сравнению с традиционными криптографическими примитивами, широко признанными сообществом. Хотя «Посейдон» может предложить скорость, проверенные в боях характеристики «Кечака» делают его более надежным и безопасным, поскольку он широко применяется.
Вот почему Keccak, несмотря на то, что он старше и принят более широким сообществом (в других отраслях, таких как системы безопасности или датчики в интеллектуальных устройствах), можно считать более проверенным и проверенным, чем Poseidon, который, в конце концов, находится в сообществе ZK. Новый хеш функции для создания и использования.
**Обратите внимание: изменение любого из этих компонентов нарушит эквивалентность Ethereum. **
Тип 2.5: эквивалент EVM, с учетом стоимости газа
ЗК-ЭВМ типа 2,5 увеличивает затраты газа на специфические операции, которые сложно доказать с помощью технологии ЗК в ЭВМ.
Учитывая ограничение газа на блок Эфириума (30 М газа), увеличение стоимости газа на код операции приводит к меньшему количеству кодов операций на блок. Следовательно, в блок можно включать менее сложные коды операций. Более простые коды операций позволяют уменьшить размер схем и ускорить создание доказательств.
Части, ZK которых трудно доказать, включают:
Изменение стоимости газа может снизить совместимость инструментов разработчика и привести к поломке некоторых децентрализованных приложений. Например, смарт-контракт, который часто выполняет коды операций с увеличением затрат на газ, может превысить лимит газа на блок и не выполниться.
Тип 3: Почти эквивалентен EVM
ZK-EVM типа 3 исключает предварительную компиляцию, неприменимую к ZK, и может регулировать доступ к памяти и хранилищу.
dApps, которые использовали удаленные предварительно скомпилированные приложения, необходимо будет переписать. В необычных случаях различия в том, как пограничные случаи обрабатываются ZK-EVM типа 3 и исходной EVM, могут потребовать внесения изменений в dApp.
Тип 4 (эквивалент языка высокого уровня)
Тип 4 уже далеко от ЭВМ.
Исходный код смарт-контракта, написанный на языке высокого уровня (например, Solidity, Zinc), компилируется в промежуточное представление, генерируя коды операций, подходящие для виртуальных машин, дружественных к ZK.
В схеме ZK, подтверждающей траекторию выполнения, каждый шаг реализует ограничение, а стоимость каждого шага представляет собой сумму всех кодов операций. Таким образом, ZK-EVM типа 4 предназначен для использования как можно меньшего количества сложных кодов операций для оптимизации эффективности.
Стоит отметить, что пользовательские коды операций (коды операций, не предусмотренные в Ethereum) позволяют передавать новые функции, которые по умолчанию недоступны в Ethereum. Например, сделайте несколько вызовов для выполнения с помощью функции абстракции учетной записи или запустите кошелек со смарт-контрактом, используя готовое решение, такое как Argent.
Подведем итог
Разные типы ZK-EVM ставят в приоритет разные цели и характеристики. Тип 1 ориентирован на эквивалентность Ethereum, а тип 4 отдает приоритет эффективному генерированию доказательств. Другие типы находятся между этими крайностями, и многие протоколы ZK-EVM типов 2 и 3 объявили о своем намерении перейти на эквиваленты Ethereum.
Эти четыре типа классификации, возможно, не являются окончательным состоянием объединения ZK и в будущем могут быть подвергнуты дальнейшим изменениям. Например, некоторые ZK-EVM могут стать гибридными, тип 1/2 может разрабатывать решения типа 4 (с максимально возможной эффективностью) и предоставлять децентрализованным приложениям оба варианта, тогда как ZK-EVM типа 3 и 4 могут добавлять эквивалентную опцию Ethereum.