Исходный текст: «Еженедельный обзор IOSG | Как выжить в ZKVM, подробное объяснение фракционных споров № 159»

Автор: Брайан, IOSG Ventures

Оглавление

Схемная реализация системы доказательства ZKP — на основе схемы VS на основе виртуальной машины (на базе виртуальной машины)

Принципы проектирования ZKVM

Сравнение виртуальных машин на базе STARK

Почему Risc0 интересен

Основное внимание в дискуссиях по объединению в прошлом 2022 году, похоже, было сосредоточено на ZkEVM, но не забывайте, что ZkVM также является еще одним средством расширения. Хотя ZkEVM не является предметом данной статьи, стоит напомнить о различиях между ZkVM и ZkEVM по нескольким направлениям:

Совместимость: Хотя оба являются расширениями, их цели различны. ZkEVM ориентирован на непосредственное достижение совместимости с существующими EVM, в то время как ZkVM нацелен на полное расширение, то есть на оптимизацию логики и производительности dapps, совместимость не является приоритетом. После настройки нижнего уровня также может быть достигнута совместимость с EVM. Производительность: Оба имеют относительно предсказуемые узкие места в производительности. Основным узким местом ZkEVM являются дополнительные затраты, возникающие в случае, когда совместимость с EVM не подходит для упаковки в системе сертификации ZK. Узким местом ZkVM является то, что из-за введения набора команд ISA ограничения на конечный результат становятся более сложными. Опыт разработчиков: ZkEVM типа II (например, Scroll, Taiko) ориентирован на совместимость с байт-кодом EVM. Другими словами, коды EVM на уровне байт-кода и выше могут генерировать соответствующие доказательства с нулевым разглашением через ZkEVM. Для ZkVM есть два направления. Одно направление — сделать собственный DSL (например, Cairo), а другое — обеспечить совместимость с существующими более зрелыми языками, такими как C++/Rust (например, Risc0). В будущем мы ожидаем, что разработчики Solidity Ethereum смогут бесплатно перейти на ZkEVM, а на ZkVM будут работать более новые и мощные приложения. Многим стоит еще помнить эту картинку. CairoVM не имеет ничего общего с ZkEVM. Существенной причиной фракционной борьбы является разница в дизайнерских идеях.

Прежде чем обсуждать ZkVM, мы сначала подумаем о том, как реализовать систему доказательств ZK в блокчейне. Вообще говоря, существует два способа реализации схем — системы на основе схем и системы на основе виртуальных машин (на базе виртуальных машин).

Прежде всего, функция схемной системы заключается в непосредственном преобразовании программы в ограничения и отправке их в проверяющую систему. Система на основе виртуальной машины выполняет программу через набор команд (ISA). В этом процессе генерируется выполнение; след. Эта трассировка выполнения затем будет преобразована в ограничения и отправлена ​​в систему проверки.

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

Программа zkp на виртуальной машине, вероятно, выполняет следующий процесс:

Изображение предоставлено: Брайан, IOSG Ventures

Преимущества и недостатки:

С точки зрения разработчика, разработка схемных систем часто требует глубокого понимания стоимости каждого ограничения. Однако при написании программ для виртуальных машин схема статична, и разработчикам приходится больше заботиться об инструкциях. С точки зрения верификатора, системы на основе цепей и виртуальные машины существенно различаются по общности цепей, при условии, что в качестве серверной части используется один и тот же чистый SNARK. Система схем создает разные схемы для каждой программы, тогда как виртуальная машина создает одну и ту же схему для разных программ. Это означает, что при объединении цепной системе необходимо развернуть несколько контрактов верификатора на уровне L1. С точки зрения приложения виртуальная машина усложняет логику приложения за счет внедрения модели памяти в проект, а цель использования схемной системы — повысить производительность программы. С точки зрения сложности системы виртуальные машины включают в систему большую сложность, например, модели памяти, связь между хостом и гостем и т. д. По сравнению с этим схема системы проще.

Ниже приводится предварительный просмотр различных проектов на основе цепей и виртуальных машин, которые в настоящее время находятся на уровне L1/L2:

Изображение предоставлено: Брайан, IOSG Ventures. Принципы проектирования виртуальных машин.

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

1. Набор инструкций ISA

Указывает, как работает генератор цепей. Его основная задача — правильно сопоставить инструкции с ограничениями, которые затем передаются в систему проверки. Все системы zk используют RISC (сокращенный набор команд). Есть два варианта ISA:

Первый — собрать собственную ISA (кастомную ISA), которую можно увидеть в дизайне Cairo. Вообще говоря, существует четыре типа логики ограничений.

Основная цель разработки пользовательской ISA — обеспечить как можно меньше ограничений, чтобы как выполнение, так и проверка программы выполнялись быстро.

Второй — использовать существующую ISA (existing ISA), которая принята в конструкции Risc0. Помимо обеспечения чистого времени выполнения, существующие ISA, такие как Risc-V, предлагают дополнительные преимущества, такие как совместимость с интерфейсными языками и серверным оборудованием. Один вопрос (возможно, еще предстоит решить) заключается в том, будут ли существующие ISA отставать во времени проверки (поскольку время проверки не является основной целью проектирования Risc-V).

2. Компилятор

Грубо говоря, компилятор постепенно переводит язык программирования в машинный код. В контексте ZK это относится к низкоуровневому представлению кода, скомпилированному в систему ограничений (R1CS, QAP, AIR и т. д.) с использованием языков высокого уровня, таких как C, C++, Rust и т. д. Есть два метода,

Спроектируйте компилятор на основе существующих представлений схем в ZK — например, в ZK представления схем начинаются с напрямую вызываемых библиотек, таких как Bellman, и языков низкого уровня, таких как Circcom. Чтобы объединить различные представления, такой компилятор, как Zokrates (который сам является DSL), стремится предоставить уровень абстракции, который можно скомпилировать в произвольные представления более низкого уровня. Опирайтесь на (существующую) инфраструктуру компилятора. Основная логика заключается в использовании промежуточного представления для нескольких интерфейсов и серверов.

Компилятор Risc0 основан на многоуровневом промежуточном представлении (MLIR) и может генерировать несколько IR (аналогично LLVM). Различные IR предоставляют разработчикам гибкость, поскольку разные IR имеют свои собственные приоритеты проектирования. Например, некоторые из них оптимизированы специально для аппаратного обеспечения, поэтому разработчики могут выбирать в соответствии со своими пожеланиями. Похожие идеи можно увидеть в vnTinyRAM и TinyRAM с использованием GCC. ZkSync — еще один пример использования инфраструктуры компилятора.

Кроме того, вы также можете увидеть некоторую инфраструктуру компилятора для zk, например CirC, которая также заимствует некоторые дизайнерские идеи из LLVM.

Помимо двух наиболее важных этапов проектирования, описанных выше, есть еще несколько соображений:

1. Компромисс между безопасностью системы и стоимостью проверки

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

2. Совместимость с фронтендом и бэкендом

Совместимость зависит от наличия промежуточного представления схемы. IR необходимо найти баланс между правильностью (соответствуют ли выходные данные программы входным + соответствуют ли выходные данные системе доказательства) и гибкостью (поддерживает несколько интерфейсных и серверных частей). Если бы IR изначально разрабатывался для решения систем ограничений низкой степени, таких как R1CS, совместимость с другими системами ограничений более высокой степени, такими как AIR, была бы затруднена.

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

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

Кратко опишем некоторые предыдущие теории,

До протокола Пиноккио: реализованы проверяемые расчеты, но время проверки было очень медленным. Протокол Пиноккио: Обеспечена теоретическая осуществимость с точки зрения проверяемости и успешности проверки (т. е. время проверки короче времени выполнения программы) и основано. Протокол системы Circuit TinyRAM: по сравнению с протоколом Pinocchio, TinyRAM больше похож на виртуальную машину, представляющую ISA, поэтому он избавляется от некоторых ограничений, таких как доступ к памяти (RAM), поток управления (поток управления) и т. д. Протокол vnTinyRAM : позволяет генерировать ключи (генерация ключей) не зависит от каждой программы, обеспечивая дополнительную универсальность. Расширьте генератор цепей, чтобы он мог обрабатывать более крупные программы.

Все вышеперечисленные модели используют SNARK в качестве бэкэнд-системы проверки, но особенно при работе с виртуальными машинами STARK и Plonk кажутся более подходящим бэкэндом, главным образом потому, что их системы ограничений больше подходят для реализации логики, подобной ЦП.

Далее в этой статье будут представлены три виртуальные машины на базе STARK — Risc0, MidenVM и CairoVM. Короче говоря, за исключением того, что они оба используют STARK в качестве системы доказательств, у них есть некоторые различия:

Risc0 использует Risc-V для простоты набора команд. R0 компилируется в MLIR, варианте LLVM-IR, предназначенном для поддержки нескольких существующих языков программирования общего назначения, таких как Rust и C++. Risc-V также имеет некоторые дополнительные преимущества, например, более удобен для аппаратного обеспечения.

Miden стремится быть совместимым с виртуальной машиной Ethereum (EVM) и, по сути, представляет собой совокупность EVM. Сейчас у Miden есть собственный язык программирования, но он также работает над поддержкой Move в будущем.

Cairo VM разработан Starkware. Система доказательств STARK, используемая этими тремя системами, была изобретена Эли Бен-Сассоном, в настоящее время президентом Starkware.

Давайте подробнее рассмотрим их различия:

* Как читать приведенную выше таблицу? Некоторые примечания...

Размер слова. Поскольку в качестве системы ограничений, на которой основаны эти виртуальные машины, используется AIR, она функционирует аналогично архитектуре ЦП. Поэтому целесообразнее выбирать длину слова ЦП (32/64 бита).

Доступ к памяти. Risc0 использует регистры главным образом потому, что набор инструкций Risc-V основан на регистрах. Miden в основном использует стеки для хранения данных, поскольку AIR функционирует как стек. CairoVM не использует регистры общего назначения, поскольку стоимость доступа к памяти (основной памяти) в модели Cairo невелика.

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

Недетерминизм. Недетерминизм является важным свойством NP-полных задач. Использование недетерминизма помогает быстро проверить прошлые исполнения. С другой стороны, это добавляет больше ограничений и, следовательно, некоторые компромиссы при проверке.

Ускорение сложных операций. Некоторые вычисления выполняются на ЦП очень медленно. Например, битовые операции, такие как XOR и AND, хеш-программы, такие как ECDSA, и проверка диапазона... в основном встроенные в технологию блокчейна/шифрования, но не собственные операции ЦП (за исключением битовых операций). Реализация этих операций напрямую через DSL может легко привести к исчерпанию циклов проверки.

Перестановка/мультимножество — широко используется в большинстве zkVM для двух целей: 1. Уменьшить стоимость верификатора за счет уменьшения необходимости хранить полную трассировку выполнения. 2. Доказать, что верификатор знает полную трассировку выполнения.

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

Текущее развитие R0:

a. Инфраструктура компилятора «Зирген» собственной разработки находится в стадии разработки. Было бы интересно сравнить производительность Zirgen с некоторыми существующими компиляторами, специфичными для zk.

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

c. Учитывая проблемы, возникающие при интеграции компаний ZK Hardware и ZK Software, Risc0 использует уровень абстракции оборудования, чтобы обеспечить лучшую разработку аппаратного обеспечения.

d.Все еще в разработке!

Поддерживает схемы ручной работы и поддерживает несколько алгоритмов хеширования. В настоящее время реализованы выделенные схемы SHA256, однако они не удовлетворяют всем потребностям. Автор считает, что конкретный выбор типа схемы для оптимизации зависит от варианта использования, предоставляемого Risc0. SHA256 — очень хорошее начало. С другой стороны, ZKVM может дать людям возможность, например, не беспокоиться о Кечаке, если они этого не хотят :)

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

Обработка недетерминизма: это свойство, с которым ZKVM должен иметь дело, в то время как традиционные виртуальные машины не имеют этой проблемы. Недетерминизм может помочь виртуальным машинам работать быстрее. MLIR относительно лучше справляется с проблемами, связанными с традиционными виртуальными машинами, и стоит с нетерпением ждать, как Risc0 встраивает недетерминизм в конструкцию системы ZKVM.

ЧТО МЕНЯ ВОЛНУЕТ:

а. Просто и проверяемо!

В распределенной системе PoW требует высокого уровня избыточности, поскольку люди не доверяют другим и, следовательно, им приходится неоднократно выполнять одни и те же вычисления для достижения консенсуса. А используя доказательства с нулевым разглашением, реализовать состояние должно быть так же просто, как согласиться с тем, что 1+1=2.

б. Более практические варианты использования:

Помимо самого прямого расширения, станут возможными и более интересные варианты использования, такие как машинное обучение с нулевым разглашением, анализ данных и т. д. По сравнению с конкретными языками ZK, такими как Cairo, Rust/C++ имеет более универсальные и мощные функции, а на виртуальной машине Risc0 выполняется больше вариантов использования web2.

c. Более инклюзивное/зрелое сообщество разработчиков:

Разработчикам, заинтересованным в STARK и блокчейне, больше не нужно заново изучать DSL, они могут просто использовать Rust/C++.

Благодарим Xin Gao, Boyuan из p0xeidon, Daniel из Taiko и Sin7Y за поддержку и предложения по доработке этой статьи!