Ви Шэнь Синьвэнь: После ETH Fang встроенный ZK, куда движется Layer2?

Производство | Ежедневник

Компиляция | Лупи Лу

Сегодня Виталик Бутерин опубликовал в сообществе ETH новую статью под названием «Как может выглядеть встроенный ZK-EVM?». В этой статье рассказывается о том, как ETH Workshop будет иметь собственный ZK-EVM, встроенный в будущие обновления сети.

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

В этой статье Виталик Бутерин подчеркивает важность совместимости, доступности данных и возможности аудита, а также исследует возможности внедрения эффективных аттестеров с отслеживанием состояния. Кроме того, в статье исследуется возможность реализации доказательств с отслеживанием состояния для повышения эффективности, а также обсуждается роль проектов уровня 2 в обеспечении быстрого предварительного подтверждения и стратегий смягчения последствий MEV. В данной статье отражен баланс опережающего развития сети ETH с помощью ЗК-ЭВМ при сохранении ее гибкости.

Odaily Planet Daily собрал оригинальную статью, и полный текст статьи выглядит следующим образом:

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

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

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

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

Каковы основные характеристики, которые мы можем ожидать от ZK-EVM в упаковке?

Основная функция: Валидация ETH блоков. Функция протокола (которая еще не определена, является ли она кодом операции, предварительной компиляцией или каким-либо другим механизмом) должна быть в состоянии принимать в качестве входных данных по крайней мере корень предварительного состояния, блок и корень после состояния и проверять, что корень после состояния на самом деле является результатом выполнения этого блока поверх корня предыдущего состояния. Совместим с мультиклиентом ETH Workshop. Это означает, что мы хотим избежать единой встроенной системы аттестации, а вместо этого позволить разным клиентам использовать разные системы аттестации.

Это также означает несколько вещей:

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

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

Проверяемость: Если какое-либо выполнение доказано, мы хотим, чтобы базовые данные были пригодны для использования, чтобы, если что-то пойдет не так, и пользователи, и разработчики могли проверить их. На самом деле, это еще одна причина, по которой важны требования к доступности данных.

Возможность обновления: Если мы находим ошибку в конкретном решении 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:

класс ZKEVMClaimTransaction(Container):
pre_state_root: байт 32
post_state_root: байт 32
transaction_and_witness_blob_pointers: List[VersionedHash]
…

Как и в случае с EIP-4844, объект, передаваемый в мемпул, является модифицированной версией транзакции:

класс ZKEvmClaimNetworkTransaction(Container):
pre_state_root: байт 32
post_state_root: байт 32
доказательство: байты
транзакция_and_witness_blobs: List[Bytes[FIELD_ELEMENTS_PER_BLOB * 31 ]]

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

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

На уровне консенсуса мы добавили правило проверки, которое будет принимать блок только в том случае, если клиент видит действительное доказательство каждого утверждения в блоке. Доказательство должно быть конкатенацией доказательства ZK-SNARK, сериализованным как пара transaction_and_witness_blobs и pre_state_root допустимым с (i) и Witness (ii) выводить правильный post_state_root. (Блок, Свидетель) Потенциально клиенты могут подождать M-of-N для нескольких типов доказательств.

Обратите внимание, что само выполнение блока можно рассматривать просто как триплет, который необходимо проверить вместе с тройками, предоставленными в объекте ZKEVMClaimTransaction (σpre, σpost, Proof).

В результате пользовательская реализация ZK-EVM может заменить клиент выполнения, который по-прежнему будет использоваться (i) проверщиками и строителями блоков, а также (ii) узлами, которые заботятся об индексировании и хранении данных для локального использования.

Валидация и повторная валидация

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

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

Предположим, что кто-то выпускает ZKEvmClaimNetworkTransaction, но выпускает только версию подтверждения PSE ZK-EVM. Узел доказательства Polygon ZK-EVM видит это и использует доказательство Polygon ZK-EVM для вычисления и повторной публикации объекта.

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

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

Расширение: Поддержка “Приблизительного EVM”

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

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

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

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

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

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

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

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

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

• Установив used_precompile_addresses для включения списка обычных адресов учетных записей с определенными флагами в состоянии и создав SNARK, чтобы доказать, что он построен правильно, вы можете поддерживать функции в стиле Arbitrum Stylus, где контракт может быть написан в EVM или WASM (или другой виртуальной машине). Привилегированные транзакции можно использовать для того, чтобы учетные записи WASM могли быть отозваны обратно в EVM.
• Добавив внешнюю проверку, чтобы убедиться, что записи ввода/вывода и привилегированные транзакции, выполняемые несколькими EVM, правильно сопоставлены, вы можете продемонстрировать параллельную систему, состоящую из нескольких EVM, взаимодействующих друг с другом по каналу синхронизации.
• ZK-EVM типа 4 может работать с несколькими реализациями: одна, которая напрямую преобразует Solidity или другой высокоуровневый язык в виртуальную машину, совместимую со SNARK, а другая, которая компилирует его в код EVM и выполняет во встроенном ZK-EVM. Вторая (и неизбежно более медленная) реализация может выполняться только в том случае, если средство проверки ошибок отправляет транзакцию, которая утверждает, что существует ошибка, и получает вознаграждение, если он может предложить, чтобы эти две транзакции обрабатывались по-разному. Чисто асинхронная виртуальная машина может быть достигнута путем возврата нуля ко всем вызовам и сопоставления вызовов с привилегированными транзакциями, добавленными в конец блока.

Расширение: Поддержка сертификатов с отслеживанием состояния

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

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

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

1. Требования σpre Либо он пустой, либо это список доступных данных с объявленными ключами и значениями, либо он выполняется раньше определенного времени σпост 。

2. Навстречу ( σpre, σпост, Доказательство ) Тройной, чтобы добавить чек, сгенерированный для блока R обязательств BLOB-объектов. Любые ранее созданные или использованные обязательства BLOB-объектов, включая те, которые представляют блоки, следящие серверы, квитанции или даже простые транзакции BLOB-объектов EIP-4844, могут иметь некоторые ограничения по времени, на которые можно ссылаться в ZKEVMClaimTransaction и получать доступ во время их выполнения (возможно, с помощью серии инструкций: "Будет зафиксировано Я Байты N… N+k-1 вставляется в блок + следящие данные J "）。

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

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

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

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

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

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

• Быстрое предварительное подтверждение: Завершенность одного слота может замедлить работу слотов уровня 1, в то время как проекты уровня 2 уже предоставляют своим пользователям «предварительные подтверждения», которые поддерживаются собственной безопасностью уровня 2 с гораздо меньшей задержкой, чем один слот. Эта служба по-прежнему будет полностью находиться под ответственностью Уровня 2.

• Стратегии смягчения последствий MEV (Miner Extractable Value): Это может включать в себя зашифрованные мемпулы, выбор секвенсора на основе репутации и другие функции, которые Layer 1 неохотно реализуют.
• Расширения EVM: Проекты уровня 2 могут предоставлять значительные расширения EVM для своих пользователей. Это включает в себя «приблизительный EVM» и принципиально разные подходы, такие как поддержка WASM в Arbitrum Stylus и дружественный к SNARK язык Cairo. • Удобство для пользователей и разработчиков: команды уровня 2 сделали многое, чтобы привлечь пользователей и проекты в свою экосистему и сделать так, чтобы они чувствовали себя желанными гостями; они получают компенсацию за счет сбора MEV и платы за перегрузку в своей сети. Эти отношения никуда не денутся.