Виталик: Обсудите различные типы версий «встроенных ZK-EVM» и проблемы проектирования

Текст: Виталик Бутерин

Компиляция: 1912212.eth, Форсайт-новости

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

Эта ситуация не идеальна, так как эти проекты копируют функциональность, которая уже существует в протоколе ETH Workshop, а ETH Governance уже отвечает за обновление и исправление ошибок: ZK-EVM — это, по сути, та же работа, что и валидация блоков Layer 1 ETH Workshop!Кроме того, в ближайшие годы мы ожидаем, что легкие клиенты будут становиться все более и более мощными, и скоро достигнут точки, когда ZK-SNARK будут использоваться для полной проверки выполнения EVM уровня 1. В этот момент ETH сеть эффективно сконструирует встроенный ZK-EVM. Итак, возникает вопрос: почему бы не сделать сам ZK-EVM пригодным и для роллапов?

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

Какие ключевые функции мы хотим получить от встроенного ZK-EVM?

• Базовая функция: Валидация ETH блоков. Функция протокола (которая пока не ясна, является ли она кодом операции, предварительной компиляцией или другим механизмом) должна принимать в качестве входных данных по крайней мере один корень предварительного состояния, один блок и один корень после состояния и проверять, что корень после состояния на самом деле является результатом выполнения блока.
• Совместим с несколькими клиентами ETH Square. Это означает, что мы хотим избежать только одной системы аттестации и вместо этого позволить разным клиентам использовать разные системы аттестации. Это приводит к следующим моментам:
• Требования к доступности данных: Для любого выполнения EVM, использующего встроенный ZK-EVM для подтверждений, мы хотим гарантировать доступность базовых данных, чтобы проверяющие, использующие другую систему аттестации, могли повторно подтвердить выполнение и позволить клиентам, которые полагаются на эту систему аттестации, проверять вновь созданные подтверждения.
• Доказательства существуют за пределами EVM и структур данных чанков: встроенная функция ZK-EVM не принимает SNARK в качестве входных данных в EVM, так как разные клиенты будут ожидать разные типы SNARK. Вместо этого это может быть похоже на проверку BLOB-объектов: транзакция может включать утверждения (pre-state, block body, post-state), которые необходимо подтвердить, содержимое которых может быть доступно опкоду или прекомпилятору, а правила консенсуса на стороне клиента будут проверять доступность данных и доказательство существования для каждого утверждения отдельно.
• Проверяемость. Если какое-либо выполнение доказано, мы хотим, чтобы базовые данные были пригодны для использования, чтобы в случае возникновения проблемы пользователи и разработчики могли их изучить. На самом деле, это еще одна причина, по которой требования к доступности данных так важны.
• Возможность модернизации. Если в решении ZK-EVM обнаружена ошибка, мы хотим иметь возможность быстро ее исправить. Это означает, что нет необходимости в хардфорке для исправления. Это объясняет, почему доказательства существуют за пределами EVM и блочных структур данных.
• Поддерживает практически все EVM. Одним из преимуществ L2 является внедрение инноваций на уровне исполнения и масштабирование EVM. Если виртуальная машина для данного L2 лишь немного отличается от EVM, то было бы неплохо, если бы L2 по-прежнему могла использовать ZK-EVM в рамках собственного протокола в тех же частях, что и EVM, и полагаться только на свой собственный код в других частях. Этого можно достичь, спроектировав функцию ZK-EVM, которая позволяет вызывающему объекту указывать битовые поля, списки кодов операций или адреса, которые обрабатываются таблицами, предоставляемыми извне, а не самим EVM. Мы также можем сделать стоимость газа в некоторой степени открытой для редактирования.

«Открытые» и «закрытые» мультиклиентские системы

«Философия мультиклиента» — это, пожалуй, самое субъективное требование в этом списке. Есть вариант отказаться от него и сосредоточиться на схеме ZK-SNARK, которая упростит дизайн, но ценой того, что это станет большим «философским поворотным моментом» для ETH Workshop (поскольку она фактически отказывается от давней философии мультиклиента ETH Workshop) и внесет большие риски. В будущем, когда технология формальной верификации станет лучше, возможно, лучше выбрать этот путь, но сейчас кажется, что риск слишком велик.

Другим вариантом является закрытая мультиклиентская система, в протоколе которой известен фиксированный набор систем аттестации. Например, мы можем решить использовать три ZK-EVM: PSE ZK-EVM, Polygon ZK-EVM и Kakarot. Для того, чтобы блок был действительным, требуется доказательство, предоставленное двумя из этих трех. Это лучше, чем единая система доказательств, но это делает систему менее адаптируемой, потому что пользователи должны поддерживать валидаторы для каждой существующей системы доказательств, и неизбежно возникнут процессы политического управления для включения новых систем доказательств и т. д.

Это мотивирует меня предпочесть открытую мультиклиентскую систему, где доказательства размещаются «вне блока» и проверяются клиентом индивидуально. Отдельные пользователи могут использовать любой клиент, который они хотят проверить блоки, при условии, что хотя бы один проверяющий создает доказательство для этой системы аттестации. Система аттестации будет получать влияние, убеждая пользователей запускать их, а не убеждая процесс управления протоколом. Однако, как мы увидим, такой подход имеет более высокую цену сложности.

Какие ключевые свойства мы хотим получить от реализации ZK-EVM?

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

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

Как может выглядеть функция ZK-EVM в рамках протокола?

Аналогично транзакциям BLOB-объектов EIP-4844 мы ввели новый тип транзакции, содержащий утверждения ZK-EVM:

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

На уровне консенсуса мы добавили правило проверки, которое принимает блок только в том случае, если клиент видит допустимое доказательство каждого утверждения в блоке. Доказательство должно быть ZK-SNARK, доказывать, что конкатенация транзакции_and_witness_blobs является сериализацией пары (Block, Witness) и что блок выполняется с pre_state_root на Witness

(i) является действительным, и

(ii) Выведите правильный post_state_root. Возможно, клиент может выбрать ожидание нескольких типов доказательства M-of-N.

Здесь важно отметить, что само выполнение блока можно рассматривать просто как одну из троек, которые необходимо проверить вместе с тройками, предоставленными в объекте ZKEVMClaimTransaction (σpre, σpost, Proof). В результате, пользовательская реализация ZK-EVM может заменить клиент выполнения; клиент выполнения по-прежнему будет выполняться

(i) Испытатели и Строители блоков, а также:

и (ii) узлы, которые заботятся об индексировании и хранении данных для локального использования.

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

Верификация и переаттестация

Предположим, что есть два ETH клиента, один из которых использует PSE ZK-EVM, а другой — Polygon ZK-EVM, на данный момент обе реализации развились до такой степени, что они могут доказать выполнение ETH блока менее чем за 5 секунд, и для каждой системы доказательств есть достаточное количество независимых добровольцев, работающих с оборудованием для создания доказательств.

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

Допустим, кто-то публикует ZKEvmClaimNetworkTransaction, но публикует только доказательство версии PSE ZK-EVM. Узел Proof многоугольника ZK-EVM видит это, вычисляет и повторно публикует объект вместе с доказательством многоугольника ZK-EVM.

Это увеличит общую максимальную задержку между самым ранним честным узлом, принимающим блок, и последним честным узлом, принимающим тот же блок, с δ до 2δ+Tproof (предполагая, что Tprov<5s).

Хорошая новость, однако, заключается в том, что если мы примем однослотовую завершенность, мы почти наверняка сможем «конвейерить» эту дополнительную задержку вместе с многораундовой задержкой консенсуса, присущей SSF. Например, в этом предложении с 4 слотами для шага «головного голосования» может потребоваться только проверка действительности базового блока, а для шага «заморозить и подтвердить» потребуется наличие доказательства.

Расширение: Поддержка “почти-EVM”

Желательной целью функции ZK-EVM является поддержка “почти-EVM”: EVM с дополнительными функциями. Это может быть новая предкомпиляция, новые коды операций, контракты, которые могут быть EVM или совершенно разными виртуальными машинами (например, в Arbitrum Stylus), или даже несколько параллельных EVM с синхронным перекрестным взаимодействием.

Некоторые модификации могут быть поддержаны простым способом: мы можем определить язык, который позволяет ZKEVMClaimTransaction передавать полное описание измененного правила EVM. Это может быть использовано в следующих ситуациях:

1. Настраиваемая таблица стоимости газа (пользователям не разрешается снижать расходы на газ, но они могут их увеличить)
2. Отключите определенные коды операций
3. Установите номер блока (это будет означать, что в зависимости от хардфорка действуют разные правила)
4. Установите флаг, чтобы активировать полный набор изменений EVM, которые уже стандартизированы для L2, но не для использования L1, или другие более простые изменения

Чтобы пользователи могли добавлять новые функциональные возможности более открытым способом, например, путем введения нового предварительно скомпилированного кода (или кода операции), мы можем добавить способ включения предварительно скомпилированных записей ввода-вывода в раздел BLOB-объектов ZKEVMClaimNetworkTransaction:

class PrecompileInputOutputTran(Container):used_precompile_addresses: Список[Address][VersionedHash]inputs_commitments: Список[Bytes]выходы: Список

Выполнение EVM будет изменено следующим образом. Массив inputs будет инициализирован как пустой. Всякий раз, когда вызывается адрес в used_precompile_addresses, мы добавляем объект InputsRecord(callee_address, Gas, input_calldata) во входные данные и устанавливаем вызываемый RETURNDATA на выходные данные[i]。 Наконец, мы проверяем, что used_precompile_addresses вызывался len(outputs) в общей сложности несколько раз, и что inputs_commitments соответствует результату обязательства результирующего BLOB-объекта к сериализации входных данных SSZ. Цель предоставления входных данных_commitments состоит в том, чтобы позволить внешнему SNARK доказать взаимосвязь между входами и выходами.

Обратите внимание на асимметрию между входами и выходами, где входные данные хранятся в хешах, а выходные — в байтах, которые должны быть предоставлены. Это связано с тем, что выполнение должно выполняться клиентом, который видит только входные данные и понимает EVM. Выполнение EVM уже сгенерировало входные данные для них, поэтому им нужно только проверить, совпадают ли сгенерированные входные данные с объявленными входными данными, для чего требуется только проверка хэша. Тем не менее, выходные данные должны быть предоставлены им в полном объеме, поэтому доступность данных должна быть доступна.

Еще одна полезная функция может заключаться в том, чтобы разрешить вызов «привилегированных транзакций» из любой учетной записи отправителя. Эти транзакции могут выполняться между двумя другими транзакциями или внутри другой (и, возможно, привилегированной) транзакции при вызове предварительной компиляции. Это может быть использовано для того, чтобы позволить механизмам, не относящимся к EVM, выполнять обратный вызов EVM.

Дизайн может быть изменен для поддержки новых или измененных кодов операций в дополнение к новым или измененным предварительным компиляциям. Даже при наличии только предварительной компиляции дизайн очень мощный. Например:

Такие функции, как Arbitrum Stylus, можно поддерживать, устанавливая used_precompile_addresses для включения списка обычных адресов учетных записей с определенным флагом, установленным в их объекте учетной записи в состоянии, и генерируя SNARK, которые доказывают, что они построены правильно, где контракт может писать свой код в EVM или WASM (или другой виртуальной машине). Привилегированные транзакции могут быть использованы для того, чтобы разрешить учетным записям WASM отзывать EVM.

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

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

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

Расширение: Поддержка Proof of State

Проблема с приведенной выше схемой заключается в том, что она полностью не имеет состояния, что делает ее плохой с точки зрения эффективности данных. При идеальном сжатии данных сжатие с сохранением состояния может сделать отправку ERC20 более компактной до 3 раз по сравнению со сжатием без сохранения состояния.

Кроме того, EVM с отслеживанием состояния не обязаны предоставлять данные следящего сервера. В обоих случаях принцип один и тот же: напрасно просить о доступности данных, когда мы уже знаем, что данные доступны, потому что они были введены или получены в результате предыдущего выполнения EVM. **

Если мы хотим сделать функцию ZK-EVM с отслеживанием состояния, у нас есть два варианта:

Требует, чтобы σpre было либо null, либо предварительно объявленным списком ключей и значений, для которых доступны данные, либо каким-либо ранее выполненным σpost.

Добавьте обязательство BLOB-объекта в кортеж (σpre, σpost, proof) для квитанции R, созданной блоком. Любые ранее созданные или использованные обязательства BLOB-объектов, на которые можно ссылаться в ZKEVMClaimTransaction и к которым можно получить доступ во время их выполнения, включая обязательства, представляющие блоки, следящие серверы, квитанции или даже обычные транзакции BLOB-объектов EIP-4844 (могут быть некоторые ограничения по времени, на которые можно ссылаться с помощью серии инструкций: “Вставьте байт N обязательства i в позицию j блока + следящие данные… N+k-1”)

(1) Основной смысл таков: вместо того, чтобы устанавливать проверку EVM без сохранения состояния, мы создадим дочернюю цепочку EVM.

и (2) по существу создает минимальный встроенный алгоритм сжатия с отслеживанием состояния, который использует ранее использованный или созданный большой двоичный объект в качестве словаря. И то, и другое накладывает нагрузку на проверочный узел, и только проверяющий узел должен хранить больше информации;

В случае (2) это бремя легче ограничить по времени, а в случае (1) сложнее.

Аргументы в пользу закрытых мультипроверных систем и оффчейн-данных

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

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

Если мы встроим ZK-EVM и сделаем его функцией протокола, какова будет текущая роль проекта L2?

Функции валидации EVM, которые в настоящее время реализуются самой командой L2, будут обрабатываться протоколом, но проект L2 по-прежнему будет отвечать за ряд важных функций:

• Быстрое предварительное подтверждение: Завершение в один слот может замедлить слоты L1, в то время как L2 уже предоставляет пользователям сервис с предварительным подтверждением и собственной безопасностью, с задержкой намного меньше, чем один слот. Ответственность за эту услугу по-прежнему будет лежать исключительно на L2.
• Стратегии смягчения последствий MEV: Это может включать в себя такие функции, как зашифрованные мемпулы, последовательный выбор на основе репутации и т. д., которые L1 неохотно реализует.
• Расширения EVM: Проекты уровня 2 могут вводить значительные расширения EVM, которые обеспечивают значительную ценность для их пользователей. Это включает в себя «почти-EVM» и совершенно другие подходы, такие как поддержка WASM в Arbitrum Stylus и дружественный язык SNARK Cairo.
• Удобство для пользователей и разработчиков: команды Tier 2 прилагают много усилий, чтобы привлечь пользователей и проекты в свою экосистему и сделать так, чтобы они чувствовали себя желанными гостями; они получают оплату, собирая MEV и плату за перегрузку в своей сети. Эти отношения никуда не денутся.