Соучредитель Scroll Чжан Е рассказал о четырех частях. В первой части Чжан Е рассказал об истории разработки, о том, почему нам вообще нужен zkEVM и почему он стал таким популярным за последние два года. Во второй части он рассказал о четырех частях. объяснил, как это сделать, в рамках полного процесса. Создание zkEVM с нуля включает в себя системы арифметики и доказательства. Третья часть рассказывает о проблемах, с которыми Scroll столкнулся при создании zkEVM, через некоторые интересные исследовательские вопросы и, наконец, знакомит с некоторыми другими приложениями, использующими zkEVM.
В традиционном блокчейне уровня 1 некоторые узлы будут поддерживаться вместе через сеть P2P. Когда они получат транзакцию пользователя, они выполнят ее на виртуальной машине EVM, прочитают контракт вызова и хранилище и обновят глобальное дерево состояний в соответствии с транзакцией.
Преимущество такой архитектуры — децентрализация и безопасность. Недостаток — высокие комиссии за транзакции на уровне L1, а подтверждение транзакций происходит медленно.
В архитектуре ZK-Rollup сети L2 необходимо только загрузить данные и доказательство для проверки правильности данных в L1, где доказательство рассчитывается с помощью схемы доказательства с нулевым разглашением.
В ранней версии ZK-Rollup схема была разработана для конкретных приложений. Пользователям нужно было отправлять транзакции разным проверяющим, а затем ZK-Rollup различных приложений отправлял свои собственные данные и доказательства в L1. Проблема заключается в том, что компонуемость исходного контракта L1 теряется.
То, что делает Scroll, — это собственное решение zkEVM, которое представляет собой ZK-Rollup общего назначения. Это не только более удобно для пользователя, но и предоставляет разработчикам лучший опыт разработки на уровне L1. Конечно, разработка, стоящая за этим, очень сложна, и стоимость создания текущих доказательств также очень высока.
К счастью, эффективность доказательств с нулевым разглашением значительно возросла за последние два года, поэтому zkEVM стал настолько популярен за последние два года. Есть как минимум четыре причины, по которым это становится возможным. Первая — появление полиномиального обязательства. В исходной системе доказательств Грота16 масштаб ограничений был очень большим, но полиномиальное обязательство может поддерживать ограничения более высокого порядка и уменьшать масштаб. доказательство; во-вторых, появление таблиц поиска и пользовательских вентилей может обеспечить более гибкие конструкции и сделать доказательства более эффективными; в-третьих, это прорывы в аппаратном ускорении, которые могут сократить время доказательства на 1-2 порядка с помощью графических процессоров, FPGA и ASIC; Четвертое. При рекурсивном доказательстве несколько доказательств могут быть объединены в одно, что делает доказательство меньше и его легче проверить. Таким образом, объединив эти четыре фактора, эффективность генерации доказательств с нулевым разглашением на три порядка выше, чем два года назад, что также является источником Сколла.
Согласно определению Джастина Дрейка, zkEVM можно разделить на три категории. Первая категория — совместимость на уровне языка. Основная причина заключается в том, что EVM не предназначен для ZK и имеет множество кодов операций, несовместимых с ZK, поэтому это приведет к ошибке. много дополнительных накладных расходов. Поэтому такие компании, как Starkware и zkSync, предпочитают компилировать Solidity или Yul в ZK-дружественные компиляторы на уровне языка.
Второй тип — это совместимость на уровне байт-кода, которую выполняет Scroll, которая напрямую доказывает, корректна ли обработка байт-кода EVM, и напрямую наследует среду выполнения Ethereum. Некоторые компромиссы, которые здесь можно сделать, заключаются в использовании корня состояния, отличного от EVM, например, использования структуры данных, совместимой с ZK. Hermez и Consensys делают нечто подобное.
Третья категория — совместимость на уровне консенсуса. Компромисс здесь заключается в том, что необходимо не только сохранить EVM неизменной, но и включить структуру хранения для достижения полной совместимости с Ethereum за счет более длительного времени проверки. Scroll создается в сотрудничестве с командой PSE Фонда Ethereum для реализации ZKизации Ethereum.
Во второй части Чжан Е показал всем, как собрать ZKVM с нуля.
Полный процесс
Прежде всего, во фронтенд-части ZKP вам необходимо выражать свои вычисления посредством математической арифметики. Наиболее часто используются линейные R1CS, а также Plonkish и AIR. После получения ограничений с помощью арифметики вам необходимо запустить алгоритм доказательства на серверной части ZKP, чтобы доказать правильность расчета. Вот наиболее часто используемые полиномиальные интерактивные доказательства оракула (Polynomial IOP) и полиномиальная схема обязательств (PCS).
Здесь нам нужно доказать, что zkEVM и Scroll используют комбинацию Plonkish, Plonk IOP и KZG.
Чтобы понять, почему мы используем эти три решения. Сначала мы начнем с простейшего R1CS. Ограничение в R1CS заключается в том, что умножение линейной комбинации на линейную комбинацию равно линейной комбинации. Вы можете добавить любую линейную комбинацию переменных без дополнительных затрат, но максимальный порядок в каждом ограничении равен 2. Следовательно, для операций более высокого порядка требуется больше ограничений.
В Plonkish вам необходимо заполнить все переменные в таблице, включая входные, выходные и свидетели для промежуточных переменных. Кроме того, вы можете определить различные ограничения. В Plonkish доступно три типа ограничений.
Первый тип ограничения — это настраиваемый вентиль. Вы можете определить отношения полиномиальных ограничений между различными ячейками, например va3 * vb3 * vc3 — vb4 =0. По сравнению с R1CS порядок может быть выше, поскольку вы можете определить ограничения для любой переменной, а также вы можете определить некоторые совершенно разные ограничения.
Второй тип ограничений — это перестановка или проверка на равенство. Его можно использовать для проверки эквивалентности различных ячеек и часто используют для связывания разных элементов в схеме, например, для доказательства того, что выход предыдущего элемента равен входу следующего элемента.
Последний тип ограничения — это таблица поиска. Мы можем понимать таблицу поиска как связь между переменными, которую можно выразить в виде таблицы. Например, мы хотим доказать, что vc7 находится в диапазоне 0–15. В R1CS сначала нужно разложить это значение на 4-битное двоичное число, а затем доказать, что каждый бит находится в диапазоне 0–1, что означает. потребует четырех ограничений. В Plonkish вы можете перечислить все возможные диапазоны в одном столбце, и вам нужно будет только доказать, что vc7 принадлежит этому столбцу. Это очень эффективно для проверки диапазонов. В zkEVM таблицы поиска очень полезны для проверки операций чтения и записи в памяти.
Подводя итог, Plonkish также поддерживает пользовательские вентили, проверки эквивалентности и таблицы поиска, которые могут быть очень гибкими для удовлетворения различных потребностей схемы. Простое сравнение STARK. Каждая строка в STARK является ограничением. Ограничение должно отражать переход состояний между строками, но гибкость пользовательских ограничений в Plonkish явно выше.
Теперь вопрос в том, как нам выбрать интерфейс в zkEVM. Перед zkEVM стоят четыре основные проблемы. Первая проблема заключается в том, что поле EVM составляет 256 бит, а это означает, что переменные должны быть эффективно ограничены по диапазону. Вторая проблема заключается в том, что EVM имеет много несовместимых с ZK кодов операций, поэтому для доказательства этих операций необходимы очень крупномасштабные ограничения; . код, такой как Keccak-256; третья проблема — проблема чтения и записи в память, вам нужно какое-то эффективное сопоставление, чтобы доказать, что то, что вы читаете, соответствует тому, что вы написали ранее; четвертая проблема — это трассировка выполнения EVM; Динамически меняется, поэтому нам нужны специальные шлюзы для адаптации к различным трассировкам выполнения. Мы выбрали Plonkish по вышеуказанным соображениям.
Далее давайте посмотрим на весь процесс zkEVM. На основе исходного глобального дерева состояний после поступления новой транзакции EVM прочитает байт-код сохраненных и вызванных контрактов и сгенерирует соответствующие трассировки выполнения на основе транзакции, например: PUSH, PUSH, STORE, CALLVALUE, а затем постепенно обновляйте глобальное состояние, чтобы получить глобальное дерево состояний после транзакции. zkEVM принимает исходное глобальное дерево состояний, саму транзакцию и глобальное дерево состояний после транзакции в качестве входных данных и использует спецификацию EVM для доказательства правильности трассировки выполнения.
Если углубляться в детали схемы EVM, каждый шаг трассировки выполнения имеет соответствующие ограничения схемы. В частности, ограничения схемы каждого шага включают контекст шага, переключение регистра и свидетельство конкретного кода операции. Контекст шага содержит хэш кода, оставшийся газ и счетчик, соответствующий трассировке выполнения; Case Switch содержит все коды операций, все ошибочные состояния и соответствующие операции шага, специфичные для кода операции, содержат дополнительные свидетели, необходимые для кода операции, такие как ожидание операндов.
Если взять в качестве примера простое сложение, вам необходимо убедиться, что управляющая переменная sADD кода операции сложения установлена в 1, а все управляющие переменные других кодов операции равны нулю. В контексте шага потребление газа ограничивается значением 3, устанавливая gas' - gas - 3 = 0. Аналогично, счетчик стека накапливает 1 после шага в переключателе случая, сумму. переменные управляются значением 1 через код операции. Чтобы ограничить этот шаг операцией сложения в Свидетельстве по конкретному коду, ограничьте фактическое добавление операндов.
Кроме того, необходимы дополнительные ограничения схемы для обеспечения корректности чтения операндов из памяти. Здесь нам сначала нужно построить справочную таблицу, чтобы доказать, что операнд принадлежит памяти. И проверьте правильность таблицы памяти через схему памяти (RAM Circuit).
Тот же метод можно применить к несовместимым с zk хеш-функциям. Создайте справочную таблицу хеш-функции, сопоставьте входные и выходные хеш-коды в трассировке выполнения с справочной таблицей и используйте дополнительную хэш-схему для проверки хеш-функции. корректность таблицы поиска.
Теперь давайте посмотрим на архитектуру схемы zkEVM. Базовая схема EVM используется для ограничения правильности каждого шага трассировки выполнения. В некоторых местах, где ограничения схемы EVM затруднены, для сопоставления мы используем таблицы поиска, включая фиксированную таблицу, Keccak. Таблица, таблица RAM, байт-код, транзакция, контекст блока, а затем используйте отдельные схемы для ограничения этих таблиц поиска, например схемы Keccak для ограничения таблиц Keccak.
Подводя итог, полный рабочий процесс zkEVM показан на рисунке ниже.
система доказательств
Поскольку непосредственная проверка вышеупомянутых схем EVM, схем памяти, схем хранения и т. д. на уровне L1 обходится дорого, система проверки Scroll использует двухуровневую архитектуру.
Первый уровень отвечает за непосредственное доказательство самой EVM, требуя большого объема вычислений для генерации доказательства. Таким образом, система доказательства первого уровня должна поддерживать пользовательские элементы и таблицы поиска, быть дружественной к аппаратному ускорению, параллельно генерировать вычисления при малой пиковой нагрузке памяти и иметь небольшую схему проверки, которую можно быстро проверить. Многообещающие альтернативы включают Plonky2, Starky и eSTARK. Все они в основном используют Plonk на внешней стороне, но могут использовать FRI на внутренней стороне, и все они соответствуют четырем вышеперечисленным характеристикам. Другой тип альтернативных решений включает Halo2, разработанный Zcash, и версию Halo2 KZG.
Есть также несколько многообещающих новых систем доказательства, таких как HyperPlonk, который недавно удалил БПФ, а система доказательств NOVA может достигать меньших рекурсивных доказательств. Но они поддерживают R1CS только в исследованиях. Если они смогут поддержать Plonkish в будущем и применить его на практике, это будет очень практично и эффективно.
Система подтверждения второго уровня используется для доказательства правильности доказательства первого уровня и должна быть эффективно проверена в EVM. В идеале она должна поддерживать аппаратное ускорение и поддерживать прозрачную или универсальную настройку. Многообещающие альтернативы включают Groth16 и систему доказательств Plonkish без колонн. Groth16 по-прежнему является представителем чрезвычайно высокой эффективности доказательства в текущих исследованиях, а система доказательства Plonkish также может достигать высокой эффективности доказательства даже при небольшом количестве колонок.
В Scroll мы используем систему доказательств Halo2-KZG в обеих наших двухуровневых системах доказательств. Поскольку Halo2-KZG может поддерживать пользовательские вентили и таблицы поиска, он хорошо работает при аппаратном ускорении графического процессора, а схема проверки имеет небольшой размер и может быть проверена быстро. Разница в том, что мы используем хеширование Poseidon в системе доказательства первого уровня для дальнейшего повышения эффективности доказательства, в то время как система доказательства второго уровня по-прежнему использует хеширование Keccak, поскольку оно проверяется непосредственно на Ethereum. Scroll также изучает возможность создания многоуровневой системы доказательств для дальнейшего объединения совокупных доказательств, созданных системой доказательств второго уровня.
В текущей реализации схема EVM системы проверки первого уровня Scroll имеет 116 столбцов, 2496 пользовательских вентилей, 50 справочных таблиц, высший порядок - 9 и требует 2 ^ 18 строк под 1 М газа, в то время как система проверки второго уровня имеет The; Схема агрегации имеет только 23 столбца, 1 пользовательский вентиль, 7 справочных таблиц, а наивысший порядок равен 5. Для агрегирования схемы EVM, схемы памяти и схемы хранения необходимо 2 ^ 25 строк.
Компания Scroll также провела большую работу по исследованию и оптимизации аппаратного ускорения графического процессора. Для схем EVM оптимизированная проверка графического процессора занимает всего 30 секунд, что в 9 раз эффективнее, чем проверка процессора. Для схем агрегации после оптимизации используется только проверка графического процессора. занимает 149 с, что в 15 раз эффективнее процессора. В текущих условиях оптимизации работа системы проверки первого уровня 1M Gas занимает около 2 минут, а системы проверки второго уровня — около 3 минут.
В третьей части Чжан Е рассказал о некоторых интересных вопросах исследования процесса создания zkEVM с помощью Scroll, от арифметической схемы внешнего интерфейса до реализации доказывающего устройства.
схема
Во-первых, это случайность в схеме. Поскольку поле EVM имеет длину 256 бит, нам нужно разделить его на 32 8-битных поля, чтобы более эффективно выполнить проверку диапазона. Затем мы используем метод случайной линейной комбинации (RLC) для кодирования 32 полей в 1 с использованием случайных чисел. Нам нужно только проверить это поле, чтобы проверить исходное 256-битное поле. Но проблема в том, что случайное число необходимо генерировать после разделения полей, чтобы гарантировать, что оно не будет подделано. Поэтому Свиток и команда PSE предложили многоэтапное решение для проверки, гарантирующее, что после разделения полей для генерации RLC используются случайные числа. Это решение инкапсулировано в Challenge API. RLC имеет множество сценариев применения в zkEVM. Он может не только сжимать поле EVM в одно поле, но также шифровать входные данные переменной длины или оптимизировать структуру таблицы поиска. Однако остается еще много открытых проблем, которые необходимо решить.
Второй интересный вопрос исследования схем — это компоновка схем. Причина, по которой интерфейс Scroll использует Plonkish, заключается в том, что трассировка выполнения EVM изменяется динамически и должна иметь возможность поддерживать различные ограничения и изменяющиеся тесты эквивалентности, в то время как стандартизированный вентиль R1CS требует для реализации схемы большего масштаба. Однако в настоящее время Scroll использует более 2000 пользовательских вентилей для соответствия динамически изменяющимся трассировкам выполнения, а также изучает способы дальнейшей оптимизации схемы схемы, включая разделение кода операции на микрокод операции или повторное использование ячеек в одной и той же таблице.
Третий интересный вопрос исследования схем — динамическое масштабирование. Поскольку масштабы схем разных кодов операций различны, но для того, чтобы соответствовать динамически изменяющейся трассировке выполнения, код операции каждого шага должен соответствовать максимальному масштабу схемы, например, хешированию Keccak, поэтому мы фактически платим дополнительные накладные расходы. Если предположить, что мы сможем заставить zkEVM динамически адаптироваться к динамически изменяющимся трассировкам выполнения, это сэкономит ненужные накладные расходы.
доказывающий
Что касается пруверов, то Scroll провел множество оптимизаций для MSM и NTT с точки зрения ускорения графического процессора, но теперь узкое место сместилось в сторону генерации свидетелей и копирования данных. Поскольку предполагается, что MSM и NTT занимают 80% времени проверки, даже если аппаратное ускорение может повысить эту эффективность на несколько порядков, исходное 20%-ное время проверки на создание свидетелей и копирование данных станет новым узким местом. Другая проблема с прувером заключается в том, что он требует много памяти, поэтому необходимо изучить более дешевые и децентрализованные аппаратные решения.
В то же время Scroll также изучает аппаратное ускорение и алгоритмы проверки, чтобы повысить эффективность проверки. В настоящее время существует два основных направления: либо перейти на меньший домен, например, использовать 64-битный домен Златовласки, 32-битный Мерсенн Прайм и т. д., либо придерживаться новой системы доказательства, основанной на эллиптических кривых (EC), например SuperNova. . Конечно, есть и другие возможные пути, и друзья, у которых есть идеи, могут напрямую связаться со Scroll.
безопасность
При создании zkEVM безопасность имеет первостепенное значение. zkEVM, созданный совместно PSE и Scroll, содержит около 34 000 строк кода. С точки зрения разработки программного обеспечения эти сложные базы кода не могут быть свободны от уязвимостей в течение длительного времени. В настоящее время Scroll проверяет базу кода zkEVM посредством большого количества проверок, в том числе проводимых ведущими аудиторскими фирмами отрасли.
В части 4 рассматриваются другие приложения, использующие zkEVM.
В архитектуре zkRollup мы проверяем, что n транзакций на L2 действительны через смарт-контракт на L1.
Если мы напрямую проверяем блок L1, то узлу L1 не нужно повторно выполнять транзакцию, а нужно только проверять достоверность каждого сертификата блока. Такое архитектурное решение называется Enshrine Blockchain. В настоящее время его очень сложно реализовать непосредственно на Ethereum, поскольку необходимо проверить весь блок Ethereum, что потребует проверки большого количества подписей, что приведет к увеличению времени проверки и снижению безопасности. Конечно, уже есть некоторые другие публичные сети, которые используют рекурсивные доказательства для проверки всей цепочки блоков с использованием одного доказательства, например Mina.
Поскольку zkEVM может доказывать переходы между состояниями, его также могут использовать «белые шляпы», чтобы доказать, что они знают об уязвимостях определенных смарт-контрактов и добиваются вознаграждения от участников проекта.
Последний вариант использования — доказать утверждения об исторических данных с помощью доказательства с нулевым разглашением и использовать его в качестве оракула. Axiom в настоящее время создает продукты в этой области. На недавнем хакатоне ETHBeijing команда GasLockR воспользовалась этой функцией, чтобы доказать исторические накладные расходы Gas.
Наконец, Scroll создает универсальное решение zkRollup для масштабирования для Ethereum, используя очень продвинутые арифметические схемы и системы доказательства, а также создавая быстрые верификаторы с помощью аппаратного ускорения для доказательства рекурсии. В настоящее время тестовая сеть «Альфа» подключена к сети и работает стабильно в течение длительного времени.
Конечно, есть еще некоторые интересные проблемы, которые необходимо решить, включая проектирование протоколов и механизмов, разработку с нулевым разглашением и фактическую эффективность. Каждый может присоединиться к Scroll, чтобы строить вместе!
