a16z: Как поэтапно реализовать безопасную и эффективную zkVM?

Автор: a16z crypto

Перевод: Odaily Planet Daily Golem

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

Проблемы

С точки зрения безопасности, zkVM — это высоко сложные программные проекты, все еще полные уязвимостей. С точки зрения производительности, доказательство правильного выполнения программы может быть в сотни тысяч раз медленнее, чем локальное выполнение, что делает большинство приложений непригодными для развертывания в реальном мире на данный момент.

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

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

Этапы безопасности

zkVM на основе SNARK обычно включают два основных компонента:

• Полиномиальное интерактивное оракул-доказательство (PIOP):框架 интерактивного доказательства для утверждений о полиномах (или ограничениях, выведенных из них).

• Схема полиномиального коммитмента (PCS): гарантирует, что доказывающий не может солгать об оценке полинома без被发现.

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

Единственный путь确保像 zkVM 这样复杂的系统没有错误的是 формальная верификация. Ниже приведена разбивка этапов безопасности. Этап 1 фокусируется на корректном протоколе, а этапы 2 и 3 фокусируются на корректной реализации.

Этап безопасности 1: Корректный протокол

1. Формально верифицированное доказательство надёжности PIOP;

2. Формально верифицированное доказательство того, что PCS является обязательным при определенных криптографических предположениях или в идеальной модели;

3. Если используется Fiat-Shamir, то формально верифицированное доказательство того, что краткое доказательство, полученное путем комбинации PIOP и PCS, безопасно в модели случайного оракула (с усилением другими криптографическими предположениями по мере необходимости);

4. Формально верифицированное доказательство того, что система ограничений, к которой применяется PIOP, эквивалентна семантике VM;

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

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

Этап безопасности 2: Корректная реализация верификатора

Формальная верификация доказывает, что фактическая реализация верификатора zkVM (используя Rust, Solidity и т.д.) соответствует протоколу, верифицированному на этапе 1. Достижение этого гарантирует, что реализованный протокол является обоснованным (а не просто дизайном на бумаге или неэффективной спецификацией, написанной на Lean и т.п.).

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

Этап безопасности 3: Корректная реализация доказывающего

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

Ожидаемый график

Прогресс этапа 1: мы можем ожидать постепенных достижений в следующем году (например, ZKLib). Но по крайней мере в течение двух лет ни одна zkVM не сможет полностью соответствовать требованиям этапа 1;

Этапы 2 и 3: эти этапы могут продвигаться одновременно с некоторыми аспектами этапа 1. Например, некоторые команды уже доказали, что реализация верификатора Plonk соответствует протоколу в статье (хотя сам протокол статьи может быть не полностью верифицирован). Тем не менее, я ожидаю, что ни одна zkVM не достигнет этапа 3 менее чем за четыре года——и, возможно, дольше.

Ключевые моменты: безопасность Fiat-Shamir и верифицированный байт-код

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

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

Еще один момент worth noting: если сам байт-код имеет дефекты, то доказательство того, что компьютерная программа была выполнена правильно (через байт-код), имеет ограниченную ценность. Таким образом, полезность zkVM в значительной степени зависит от методов генерации формально верифицированного байт-кода——это огромная проблема, выходящая за рамки обсуждения в этой статье.

О безопасности в постквантовую эру

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

Текущее состояние производительности zkVM

В настоящее время доказывающий zkVM создает коэффициент накладных расходов,接近 1 миллион раз по сравнению с стоимостью нативного выполнения. Если программе требуется X циклов для выполнения, то стоимость доказательства правильного выполнения составляет примерно X умноженное на 1 миллион циклов CPU. Так было год назад, и так остается сегодня.

Популярные нарративы часто описывают эти накладные расходы так, что это звучит приемлемо. Например:

• «Стоимость генерации доказательств для всей основной сети Ethereum ежегодно составляет менее одного миллиона долларов».

• «Мы почти можем генерировать доказательства блоков Ethereum в реальном времени, используя кластер из десятков GPU».

• «Наша последняя zkVM в 1000 раз быстрее своего предшественника».

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

• В 1000 раз быстрее, чем старая версия zkVM, но абсолютная скорость все еще очень медленная. Это скорее показывает, насколько все плохо, а не насколько хорошо.

• Уже было предложено увеличить объем вычислений, обрабатываемых основной сетью Ethereum, в 10 раз. Это сделает текущую производительность zkVM еще медленнее.

• То, что люди называют «почти реальным временем доказательства блоков Ethereum», все еще намного медленнее, чем требуют многие блокчейн-приложения (например, время блока в Optimism составляет 2 секунды, что намного быстрее 12-секундного времени блока Ethereum).

• «Десятки GPU, работающих постоянно, без ошибок» не обеспечивают приемлемых гарантий доступности.

• Трата менее одного миллиона долларов в год на доказательство всей активности в основной сети Ethereum отражает тот факт, что полным узлам Ethereum требуется всего около 25 долларов в год для выполнения вычислений.

Для приложений за пределами блокчейна такие накладные расходы явно слишком высоки. Никакая параллелизация или инженерия не могут компенсировать такие огромные накладные расходы. Мы должны взять за базовый基准 то, что zkVM замедляется не более чем в 100 000 раз по сравнению с нативным выполнением——даже если это только первый шаг.真正的 массовое внедрение может потребовать накладных расходов,接近 10 000 раз или ниже.

Как измерять производительность

Производительность SNARK имеет три основных компонента:

• Внутренняя эффективность базовой системы доказательств.

• Оптимизации, специфичные для приложения (например, прекомпиляты).

• Инженерия и аппаратное ускорение (например, GPU, FPGA или многоядерные CPU).

Хотя последние два критически важны для фактического развертывания, они обычно применимы к любой системе доказательств, поэтому они не обязательно отражают базовые накладные расходы. Например, добавление ускорения GPU и прекомпилятов в zkEVM может легко обеспечить 50-кратное ускорение, что намного быстрее, чем纯基于 CPU 的方法 без прекомпилятов——достаточно, чтобы система, по сути менее эффективная, выглядела лучше, чем система, не прошедшая такую же доработку.

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

Этапы производительности

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

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

Эти метрики фокусируются на стоимости доказывающего. Однако, если允许 неограниченная стоимость верификатора (т.е. нет上限 на размер доказательства или время верификации), то можно легко удовлетворить любые метрики доказывающего. Поэтому для системы, чтобы соответствовать описанным этапам, должны быть указаны максимальные значения для размера доказательства и времени верификации.

Требования к производительности

Требования этапа 1: «Разумная и нетривиальная стоимость верификации»:

• Размер доказательства: размер доказательства должен быть меньше размера свидетеля.

• Время верификации: скорость верификации доказательства не должна быть медленнее, чем нативное выполнение программы (т.е. выполнение вычислений без доказательства корректности).

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

Требования этапа 2 и далее:

• Максимальный размер доказательства: 256 КБ.

• Максимальное время верификации: 16 мс.

Эти cutoff значения故意 завышены, чтобы accommodate новые быстрые технологии доказательств, которые могут带来 более высокую стоимость верификации. В то же время они исключают очень дорогие доказательства, настолько дорогие, что немногие проекты готовы включить их в блокчейн.

Этап скорости 1

Однопоточное доказательство должно быть медленнее нативного выполнения не более чем в сто тысяч раз, измеренное на ряде приложений (не только доказательство блоков Ethereum), без зависимости от прекомпилятов.

Конкретно, представьте процесс RISC-V, работающий со скоростью около 3 миллиардов циклов в секунду на современном ноутбуке. Достижение этапа 1 означает, что вы можете доказывать около 30 000 циклов RISC-V в секунду на том же ноутбуке (однопоточно). Но стоимость верификации должна быть «разумной и нетривиальной», как указано выше.

Этап скорости 2

Однопоточное доказательство должно быть медленнее нативного выполнения не более чем в десять тысяч раз.

Или, поскольку некоторые перспективные методы SNARK (особенно基于二进制 поля的方法) ограничены текущими CPU и GPU, вы можете сравнить использование FPGA (или даже ASIC) для достижения этого этапа:

• Количество ядер RISC-V, которые FPGA могут эмулировать с нативной скоростью;

• Количество FPGA, необходимых для эмуляции и доказательства (почти) выполнения RISC-V в реальном времени.

Если后者 не более чем в 10 000 раз больше前者, то вы qualifies для этапа 2. На стандартном CPU размер доказательства должен быть не более 256 КБ, а время верификатора не более 16 мс.

Этап скорости 3

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

Этап памяти 1

Скорость этапа 1 достигается при условии, что доказывающему требуется менее 2 ГБ памяти (при этом также реализуется нулевое разглашение).

Это критически важно для многих мобильных устройств или браузеров, thus открывая бесчисленные клиентские用例 zkVM. Клиентские доказательства важны, потому что наши телефоны являются нашей постоянной связью с реальным миром: они отслеживают наше местоположение, учетные данные и т.д. Если генерация доказательства требует более 1-2 ГБ памяти, то для большинства современных мобильных устройств это实在是 слишком много. Нужно прояснить два момента:

• Граница пространства в 2 ГБ applies к large statements (утверждениям, требующим триллионов циклов CPU для нативного выполнения). Системы доказательств, реализующие границу пространства только для small statements, lack широкой применимости.

• Если доказывающий очень медленный, то легко keep пространство доказывающего ниже 2 ГБ памяти. Поэтому, чтобы этап памяти 1 не был тривиальным, я требую удовлетворения этапа скорости 1 в пределах границы пространства 2 ГБ.

Этап памяти 2

Скорость этапа 1 достигается при использовании памяти менее 200 МБ (в 10 раз лучше, чем этап памяти 1).

Зачем push ниже 2 ГБ? Consider не блокчейн пример: каждый раз, когда вы accesses сайт через HTTPS, вы загружаете сертификат для аутентификации и шифрования. Вместо этого сайт может отправить zk-доказательство владения этими сертификатами. Large сайты могут issue миллионы таких доказательств в секунду. Если каждое доказательство требует 2 ГБ памяти для генерации, то в total требуется петабайтный уровень RAM. Дальнейшее снижение использования памяти критически важно для не блокчейн развертываний.

Прекомпиляты: последняя миля или костыль?

В дизайне zkVM прекомпиляты refer к специализированным SNARK (или системам ограничений), tailored для specific функций, таких как хеширование Keccak/SHA для цифровых подписей или операции групп эллиптических кривых. В Ethereum (где大部分 тяжелая работа involves Merkle хеширование и проверку подписей), некоторые manually crafted прекомпиляты могут уменьшить накладные расходы доказывающего. Но reliance на них как на костыль не позволяет SNARK достичь того, что им нужно. Причины следующие:

• Все еще слишком медленно для большинства приложений (внутри и снаружи блокчейна): даже с прекомпилятами хеширования и подписей, текущие zkVM все еще слишком медленные (как в блокчейн среде, так и вне ее), потому что базовая система доказательств неэффективна.

• Сбои безопасности: handwritten прекомпиляты без формальной верификации почти наверняка full of ошибок, potentially leading к катастрофическим сбоям безопасности.

• Плохой опыт разработчиков: в большинстве современных zkVM добавление новых прекомпилятов означает manual writing системы ограничений для каждой функции——по сути, возвращение к workflow стиля 1960-х годов. Даже с existing прекомпилятами, разработчики должны refactor код для вызова каждого прекомпила. Мы должны оптимизировать для безопасности и опыта разработчиков, а не жертвовать обоими ради pursuit incremental производительности. Doing so только proves, что производительность не там, где она должна быть.

• Накладные расходы на ввод/вывод и отсутствие RAM: хотя прекомпиляты могут улучшить производительность для тяжелых криптографических задач, они may not provide meaningful acceleration для более diverse workloads, потому что они generate значительные накладные расходы при passing input / output, и они cannot use RAM. Даже в блокчейн среде, как только вы выходите за рамки монолитного L1, like Ethereum (например, вы хотите build series кросс-чейн мостов), вы сталкиваетесь с different хеш-функциями и схемами подписей. Doing прекомпиляты again and again на问题上 cannot scale и brings огромные риски безопасности.

По всем этим причинам, our首要任务 должно быть повышение эффективности базовой zkVM. Технологии, производящие лучшие zkVM, также будут производить лучшие прекомпиляты. Я действительно believe, что прекомпиляты останутся критически важными в long run, но только если они автоматически synthesized и формально верифицированы. Таким образом, можно maintain преимущества опыта разработчиков zkVM, одновременно avoiding катастрофические риски безопасности. Эта точка зрения отражена в этапе скорости 3.

Ожидаемый график

Я ожидаю, что少数 zkVM реализуют этап скорости 1 и этап памяти 1 позже в этом году. Я think мы также реализуем этап скорости 2 в течение следующих двух лет, но currently unclear, можем ли мы achieve this без一些 new ideas, которые еще не appeared. Я ожидаю, что remaining этапы (этап скорости 3 и этап памяти 2) потребуют нескольких лет для реализации.

Резюме

Хотя я в этой статье отдельно identified этапы безопасности и производительности zkVM, эти аспекты zkVM не completely independent. По мере того, как в zkVM обнаруживается больше уязвимостей, ожидается, что некоторые уязвимости можно будет исправить только ценой значительного снижения производительности. Производительность должна быть paused до того, как zkVM достигнет этапа безопасности 2.

zkVM обещают сделать доказательства с нулевым разглашением truly массовыми, но они все еще на起步阶段——full of вызовов безопасности и огромных накладных расходов производительности. Хайп и маркетинговые заявления make it difficult оценить реальный прогресс. Путем outlining clear вех безопасности и производительности, hopefully можно provide roadmap, eliminating distractions. Мы достигнем цели, но это requires время и continuous efforts.