Руководство разработчика по zkGalaxy

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

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

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

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

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

Аркворкс-РС — это экосистема библиотек Rust, обеспечивающая эффективную и безопасную реализацию подкомпонентов приложения zkSNARK. Arkworks предоставляет интерфейсы, необходимые разработчикам для настройки стека программного обеспечения для приложения zk без повторной реализации общих черт с другими существующими библиотеками.

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

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

Чтобы создать доказательство для некоторого вычисления, сначала это вычисление должно быть выражено в форме, понятной системе zkSNARK. Несколько предметных языков создали языки программирования, которые позволяют разработчикам приложений таким образом выражать свои вычисления. К ним относятся Ацтекский нуар, Старкнет Каир, Цирком, ЗоКратеси Алео Лев среди прочих. Базовая система проверки и математические детали обычно не раскрываются разработчику приложения.

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

Каир – Starkware DSL, необходимый для создания приложений в Starknet. Компилируется в специфический для Cairo язык ассемблера, который может быть интерпретирован Cairo zkVM.

ЗоКратес — ZoKrates — это набор инструментов для общих нужд SNARK, включая язык высокого уровня для написания схем. ZoKrates также имеет некоторую гибкость в отношении кривых, схемы проверки и бэкэнда, что позволяет разработчикам осуществлять горячую замену с помощью простого аргумента CLI.

Цирком — Circom — это специально созданный язык для построения схем. В настоящее время это де-факто язык для схем в производстве. Язык не отличается особой эргономикой. Сам язык заставляет вас остро осознавать тот факт, что вы пишете схемы.

Лев — Leo был разработан как язык для блокчейна Aleo. Leo имеет синтаксис, похожий на Rust, и специально создан для переходов между состояниями внутри блокчейна.

Noir - Синтаксис, вдохновленный Rust. Архитектура основана на IR, а не на самом языке, что означает, что он может иметь произвольный интерфейс. 

Любой разработчик приложений, который хочет воспользоваться уникальными свойствами zk в своем приложении. Некоторые из этих языков прошли боевые испытания, и через них через такие сети, как ZCash и Starknet, перемещаются миллиарды долларов. Хотя некоторые из проектов, которые мы обсудим, не совсем готовы к использованию в производственной среде, написание схем на одном из этих языков в настоящее время является лучшей стратегией, если только вам не нужны более точные элементы управления, предоставляемые набором инструментов, таким как Arkworks.

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

Основное техническое различие между ними заключается именно в том, где именно в языковом стеке вычисление преобразуется в форму (арифметизацию), которую можно использовать в системе доказательства. В некоторых zkEVM это происходит на языках высокого уровня (Solidity, Vyper, Yul), в то время как другие подходы пытаются доказать EVM на всем пути до уровня кода операции. Компромиссы между этими подходами подробно описаны в посте Виталика, но я резюмирую его в одном предложении: чем меньше преобразование/арифметизация происходит в стеке, тем больше потеря производительности.

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

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

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

В современных реализациях zkEVM используются разные стратегии для смягчения последствий этой проблемы… Например, zkSync вырывает более дорогостоящие операции (в основном криптографические предварительные компиляции, такие как хэши и ECDSA) из основной схемы проверки выполнения в отдельные схемы, которые объединяются вместе на конец через рекурсию snark. zkSync применил этот подход после того, как понял, что большая часть их затрат связана с несколькими сложными инструкциями.

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

Идеальные клиенты для zkEVM — это приложения для смарт-контрактов, которым требуются транзакции на несколько порядков дешевле, чем те, которые доступны в L1 Ethereum. У этих разработчиков не обязательно есть опыт или пропускная способность, чтобы писать zk-приложения с нуля. Поэтому они предпочитают писать свои приложения на знакомых им языках более высокого уровня, таких как Solidity. 

Масштабирование Ethereum в настоящее время является наиболее востребованным применением технологии zk.

ZkEVM — это решение для масштабирования Ethereum, которое легко устраняет проблему перегрузки, которая ограничивает разработчиков L1 dApp.

Целью zkEVM является поддержка опыта разработчиков, максимально приближенного к текущей разработке Ethereum. Полная поддержка Solidity означает, что командам не нужно создавать и поддерживать несколько кодовых баз. Это несколько непрактично, чтобы сделать идеально, потому что zkEVM должны пожертвовать некоторой совместимостью, чтобы иметь возможность генерировать доказательства разумного размера за разумное время.

Основное различие между zkSync и Scroll заключается в том, где и когда в стеке они выполняют арифметизацию, то есть, где они преобразуют обычные конструкции EVM в представление, удобное для SNARK. Для zkSync это происходит, когда они преобразуют байт-код YUL в свой собственный набор инструкций zk. Для прокрутки это происходит в конце, когда фактическая трассировка выполнения генерируется с фактическими кодами операций EVM.

Итак, для zkSync все аналогично взаимодействию с EVM, пока не будет сгенерирован байт-код zk. Для прокрутки все то же самое, пока не будет выполнен фактический байт-код. Это тонкая разница, которая жертвует производительностью ради поддержки. Например, zkSync не будет поддерживать инструменты байт-кода EVM, такие как отладчик, из коробки, потому что это совершенно другой байт-код. В то время как Scroll будет сложнее добиться хорошей производительности из набора инструкций, он не был разработан для zk. У обеих стратегий есть свои плюсы и минусы, и, в конечном счете, существует множество экзогенных факторов, которые будут влиять на их относительный успех.

???? Несмотря на свое название, LLVM не является VM (виртуальная машина). LLVM — это название набора инструментов компилятора, привязанного к промежуточному представлению (IR), которое не зависит от языка.

= ноль; Фонд (насчет названия, это Шутка о SQL-инъекциях если вам интересно) создает компилятор, который может преобразовать любой интерфейсный язык LLVM в промежуточное представление, которое можно проверить в SNARK. ZkLLVM спроектирован как расширение существующей инфраструктуры LLVM, стандартной цепочки инструментов, которая поддерживает множество языков высокого уровня, таких как Rust, C, C++ и т. д.

Пользователь, который хочет доказать некоторые вычисления, просто реализует эти вычисления на C++. ZkLLVM берет этот высокоуровневый исходный код, который поддерживается их модифицированным компилятором clang (в настоящее время C++), и создает некоторое промежуточное представление схемы. На данный момент схема готова для проверки, но пользователь может захотеть проверить схему на основе некоторых динамических входных данных. Для обработки динамических входных данных zkLLVM имеет дополнительный компонент, называемый присваивателем, который создает таблицу назначений со всеми входными данными и свидетелями, полностью предварительно обработанными и готовыми к проверке вместе со схемой.

Эти 2 компонента — все, что необходимо для создания доказательства. Теоретически пользователь может сгенерировать доказательство самостоятельно, но, поскольку это несколько специализированная вычислительная задача, он может захотеть заплатить кому-то другому, у кого есть оборудование, чтобы сделать это за него. Для этого механизма обнаружения контрагента =nil; Фонд также создал «рынок доказательств», где доказывающие соревнуются, чтобы доказать вычисление для пользователей, которые будут платить им за это. Эта динамика свободного рынка приведет к тому, что пруверы оптимизируют наиболее ценные задачи прувинга.

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

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

ZkVM описывает надмножество всех виртуальных машин zk, а zkEVM — это особый тип zkVM, который стоило обсудить как отдельную тему из-за его распространенности сегодня. Есть несколько других проектов, которые работают над созданием более универсальных zkVM, основанных на ISA, помимо специализированных крипто-VM.

Вместо проверки EVM система может проверить другую архитектуру набора инструкций (ISA), такую ​​как RISC-V или WASM, в новой виртуальной машине. Над этими обобщенными виртуальными машинами zkVM работают два проекта: RISC Zero и zkWASM. Давайте немного углубимся в RISC Zero, чтобы продемонстрировать, как работает эта стратегия и некоторые из ее преимуществ/недостатков. 

RISC Zero может подтвердить любое вычисление, выполняемое на архитектуре RISC-V. RISC-V — это стандарт архитектуры набора инструкций (ISA) с открытым исходным кодом, который набирает все большую популярность. Философия RISC (компьютер с сокращенным набором команд) заключается в создании чрезвычайно простого набора инструкций с минимальной сложностью. Это означает, что разработчики на более высоких уровнях стека в конечном итоге берут на себя большую нагрузку по реализации инструкций с использованием этой архитектуры, в то же время упрощая аппаратную реализацию.

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

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

С точки зрения разработчика, использование RISC Zero для обработки доказательств zk очень похоже на использование функций AWS Lambda для обработки серверной архитектуры. Разработчики взаимодействуют с RISC Zero или AWS Lambda, просто написав код, а сервис берет на себя всю сложность серверной части.

Для RISC Zero разработчики пишут Rust или C++ (в конечном итоге все, что нацелено на RISC-V). Затем система берет файл ELF, сгенерированный во время компиляции, и использует его в качестве входного кода для схемы VM. Разработчики просто вызывают объект proof, который возвращает квитанцию ​​(которая содержит zk-доказательство трассировки выполнения), который любой может вызвать `verify` из любого места. С точки зрения разработчика нет необходимости понимать, как работает zk, со всей этой сложностью справляется базовая система.

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

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

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

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

Надеюсь, я убедил вас, любознательного разработчика программного обеспечения, что вы можете начать использовать zk в своих приложениях уже сегодня. Удачного взлома 🙂

Раскрытие информации: Blockchain Capital является инвестором нескольких упомянутых выше протоколов.

Мнения, выраженные в каждом сообщении в блоге, могут быть личными взглядами каждого автора и не обязательно отражают взгляды Blockchain Capital и ее аффилированных лиц. Ни Blockchain Capital, ни автор не гарантируют точность, адекватность или полноту информации, представленной в каждом сообщении блога. Blockchain Capital, автор или любое другое лицо не дает никаких заявлений или гарантий, явных или подразумеваемых, или от их имени в отношении точности, полноты или достоверности информации, содержащейся в любом сообщении в блоге, и мы не несем никакой ответственности или обязательств. за любую такую ​​информацию. Ничто, содержащееся в каждом сообщении в блоге, не является инвестиционным, нормативным, юридическим, налоговым или другим советом, и на него нельзя полагаться при принятии инвестиционного решения. Сообщения в блогах не следует рассматривать как текущие или прошлые рекомендации или предложения о покупке или продаже каких-либо ценных бумаг или принятии какой-либо инвестиционной стратегии. Сообщения в блогах могут содержать прогнозы или другие прогнозные заявления, основанные на убеждениях, предположениях и ожиданиях, которые могут измениться в результате многих возможных событий или факторов. В случае изменения фактические результаты могут существенно отличаться от тех, которые указаны в прогнозных заявлениях. Все прогнозные заявления действительны только на дату таких заявлений, и ни Blockchain Capital, ни каждый автор не берут на себя никаких обязательств по обновлению таких заявлений, за исключением случаев, предусмотренных законом. В тех случаях, когда любые документы, презентации или другие материалы, подготовленные, опубликованные или иным образом распространяемые Blockchain Capital, упоминаются в любом сообщении в блоге, такие материалы следует читать с особым вниманием к любым заявлениям об отказе от ответственности, содержащимся в них.