Подробно объясните пять типов ZK-EVM: архитектуру, преимущества и недостатки и решения.

Автор исходного текста: s Составление исходного текста: Deep Tide TechFlow

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

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

Давайте рассмотрим типы ZK-EVM, их плюсы и минусы.

1. Тип 1: полностью эквивалентен Ethereum;

2. Тип 2: полностью эквивалентен EVM;

3. Тип 2.5: Частично эквивалентен EVM;

4. Тип 3: почти эквивалентно EVM;

5. Тип 4: где язык высокого уровня эквивалентен.

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

Архитектура: точно такая же, как у Эфириума, и никакая часть системы Эфириума не меняется.

преимущество

Идеальная совместимость:

• Возможность проверки блоков Ethereum;
• Помогите сделать Ethereum L1 более масштабируемым;
• Подходит для накопительных пакетов, поскольку они могут повторно использовать большую часть инфраструктуры.

недостаток

Идеальная совместимость:

• Эфириум изначально не был разработан для функциональности ZK;
• Многие компоненты Ethereum требуют большого количества вычислений для генерации доказательств ZK (ZKP);
• Для генерации доказательств для блоков Ethereum требуется много часов.

Решение проблемы:

• Масштабный распараллеливающий прувер;
• ZK-SNARK ASIC.

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

Архитектура:

• Структура данных (блочная структура и дерево состояний) существенно отличается от Ethereum;
• Полностью совместим с существующими приложениями;
• Незначительные модификации Ethereum для упрощения разработки и более быстрого создания доказательств.

преимущество

• Обеспечивает более быстрое подтверждение, чем тип 1;
• EVM не имеет прямого доступа к структуре данных;
• Приложения, работающие на Ethereum: скорее всего, будут работать на Type 2;
• Поддержка существующих средств отладки EVM и другой инфраструктуры разработки.

недостаток

Прежде чем разобраться в недостатках, сначала разберитесь, что такое «Кекчак»:

• Алгоритм хеширования блокчейна Ethereum;
• Используется для защиты данных на Ethereum;
• Убедитесь, что сообщение преобразовано в хэш.

Тип 2 не совместим с приложениями, которые проверяют доказательства Merkle исторических блоков для проверки информации об исторических транзакциях, поступлениях/состояниях. Это связано с тем, что если алгоритм хеширования изменится (уже не Keccak), доказательство станет недействительным.

Мы можем думать о Keccak как о языке, который использует доказательства Меркла (алфавиты). Если ZK-EVM заменит Keccak другим алгоритмом хэширования (например, Poseidon), доказательства Меркла станут незнакомыми, и приложения не смогут их читать и подтверждать их утверждения.

Потенциальное решение недостатков: Ethereum может добавить в будущем масштабируемую предварительную компиляцию доступа к истории.

проект

• Прокрутка;
• Полигон Гермез.

Однако в этих проектах еще не реализована более сложная прекомпиляция, поэтому их можно считать незавершенными Type 2.

Тип 2.5: Частично эквивалентно EVM

Архитектура:

Увеличить стоимость газа для конкретных операций EVM, которые трудно доказать ZK;

• Предварительно скомпилирован;
• Код операции Keccak;
• Режим вызова контракта;
• доступ к памяти;
• хранилище.

преимущество

• Значительно улучшено время доказательства в худшем случае;
• Безопаснее, чем вносить более глубокие изменения в стек EVM.

недостаток

• Снижена совместимость средств разработки;
• Некоторые приложения не будут работать.

Тип 3: Почти эквивалентно EVM

Архитектура:

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

преимущество

• сократить время проверки;
• Сделать EVM проще в разработке;
• Цель состоит в том, чтобы требовать минимальной перезаписи для менее совместимых приложений.

недостаток

• Больше несовместимостей;
• Приложения, использующие предварительную компиляцию, которые были удалены в типе 3, необходимо будет переписать.

проект

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

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

Архитектура:

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

преимущество

• Очень быстрое время доказательства;
• Снижение накладных расходов (стоимость, время и вычислительные усилия);
• Снизьте барьер для того, чтобы стать испытателем: увеличьте степень децентрализации.

недостаток

• В системе типа 4 адрес контракта может отличаться от адреса в EVM, потому что адрес зависит от точного байткода;
• Это означает, что если ZK-EVM типа 4 не имеют байт-кода, они не смогут создавать адреса;
• Тип 4 будет несовместим с приложениями, основанными на контрафактных контрактах в вышеуказанных случаях;
• Многие инфраструктуры отладки не переносимы, потому что они работают на байт-коде EVM.

проект

• зксинк

Наконец, мы можем сравнить вышеупомянутые типы вместе, чтобы помочь каждому понять различные zkEVM с первого взгляда.