Автор: Justin Thaler источник: a16z Перевод: Шан О, Golden Finance
Виртуальная машина с нулевым знанием (zkVMs) призвана сделать SNARKs более доступными, позволяя даже людям без специализированных знаний по SNARK доказать, что они правильно выполнили определенную программу на конкретном вводе (или свидетельстве). Ее основное преимущество заключается в опыте разработчика, но в настоящее время zkVMs все еще сталкиваются с огромными вызовами в области безопасности и производительности. Если zkVMs хотят оправдать свои обещания, разработчики должны преодолеть эти препятствия. В этой статье будет рассмотрено возможное развитие zkVM, и весь процесс, вероятно, потребует несколько лет для завершения - не верьте тем, кто говорит, что это можно быстро сделать.
Изложение вызовов
В аспекте безопасности zkVMs являются сложным программным проектом, который все еще полон уязвимостей.
В аспекте производительности доказательство правильного выполнения программы может быть медленным на десятки тысяч раз, что делает большинство приложений непригодными для развертывания в реальном мире.
Тем не менее, многие голоса в отрасли блокчейнов до сих пор пропагандируют, что zkVMs можно немедленно развернуть, и даже некоторые проекты уже платят высокую цену за вычислительные затраты для генерации нулевых доказательств активности на цепи. Однако, поскольку у zkVMs все еще существует множество уязвимостей, такой подход на самом деле является дорогим обманом, который делает систему похожей на защищенную SNARK, тогда как на самом деле она или зависит от управления разрешениями, или, что еще хуже, — подвергается риску атак.
Фактическая ситуация такова, что до построения действительно безопасного и эффективного zkVM нам еще много лет. В этой статье предлагается ряд конкретных и поэтапных целей, чтобы помочь нам отслеживать реальный прогресс zkVM, уменьшить спекуляции и направить внимание сообщества на действительные технические прорывы.
Этап развития безопасности
Фон
На базе SNARK обычно есть два основных компонента zkVMs:
Интерактивное доказательство оракула полиномиальной сложности (Polynomial Interactive Oracle Proof, PIOP): фреймворк для доказательства полиномиальных (или ограничений, происходящих от полинома) взаимодействий.
Схема обязательства полинома (Polynomial Commitment Scheme, PCS): гарантирует, что доказатель не может подделать результат оценки полинома, не будучи обнаруженным.
zkVM через кодирование действительных исполнительных следов в виде систем ограничений обеспечивает правильное использование регистров и памяти виртуальной машины, а затем с использованием SNARK доказывает удовлетворение этих ограничений.
В такой сложной системе единственным способом обеспечения отсутствия уязвимостей в zkVM являетсяформальная проверка. Ниже приведены различные этапы безопасности zkVM, где первый этап фокусируется на правильности протокола, второй и третий этапы фокусируются на правильности реализации.
PCS в некоторых криптографических предположениях или идеальных моделях имеет формальное доказательство обязательства;
Если использовать Fiat-Shamir, то компактное доказательство, полученное путем объединения PIOP и PCS, формально подтверждается как безопасное подтверждение в случайной модели предсказания (при необходимости с использованием других криптографических предположений для усиления).
Система ограничений, применяемая в PIOP, эквивалентна формальному доказательству семантики VM;
Все эти части должны быть полностью «склеены» в одно единственное формализованное проверенное безопасное доказательство SNARK для выполнения любой программы, указанной в байт-коде VM. Если протокол предполагает реализацию нулевого разглашения, это свойство также должно быть формализовано и проверено, чтобы гарантировировать, что не будет раскрыта чувствительная информация о свидетеле.
Если zkVM использует рекурсию, то в процессе рекурсии все, что касается PIOP, обязательств и систем ограничений, должно быть проверено, в противном случае этап не будет считаться завершенным.
Этап 2 безопасности: правильная реализация валидатора
Этап требует проведения формальной верификации фактической реализации валидатора zkVM (например, на Rust, Solidity и т. д.), чтобы убедиться, что она соответствует протоколу, который уже был проверен на первом этапе. Завершение этого этапа означает, что реализация zkVM соответствует теоретическому дизайну и не является просто бумажным безопасным протоколом или неэффективной спецификацией, написанной на Lean или подобных языках.
Почему только о валидаторах, а не о доказателях есть две основные причины: во-первых, обеспечение правильности валидаторов гарантирует целостность системы доказательств zkVM (т. е. гарантирует, что валидаторы не будут обмануты и примут неверное доказательство). Во-вторых, реализация валидатора zkVM проще реализации доказателя более чем на порядок, и правильность валидатора легче гарантировать в краткосрочной перспективе.
Этап безопасности 3: достижение правильного подтверждающего лица
На этапе требуется провести формальную верификацию доказательств выполнения zkVM, чтобы гарантировать, что оно сможет правильно генерировать доказательства системы, которые уже были проверены на первом и втором этапах. Цель этого этапа - полнота: любая система, использующая zkVM, не должна зависать из-за невозможности доказать какое-либо правомерное утверждение. Если zkVM должен обладать нулевым разглашением, необходимо провести формальную верификацию, чтобы гарантировать, что доказательства не раскроют никакой информации о свидетельствах.
Временное расписание
Этап 1 Прогресс: Мы можем ожидать некоторого прогресса в следующем году (например, усилия по ZKLib). Но как минимум два года ни один zkVM не сможет полностью удовлетворить требования 1 этапа.
Этап 2 и этап 3 : Эти этапы могут параллельно развиваться с некоторыми аспектами этапа 1. Например, некоторые команды уже доказали соответствие реализации Plonk-верификатора протоколу из статьи (хотя сам протокол из статьи может быть не полностью проверен). Тем не менее, я ожидаю, что ни один zkVM не достигнет этапа 3 менее чем за четыре года - возможно, даже дольше.
Ключевые моменты: безопасность Fiat-Shamir и верифицированный байт-код
Одной из основных проблем сложности является то, что безопасность преобразования Фиата-Шамира по-прежнему является неразрешенной проблемой исследований. Все три этапа безопасности рассматривают Фиата-Шамира и случайное предсказание как абсолютно безопасные, но на самом деле вся парадигма может иметь уязвимости. Это происходит из-за различий между идеализированной моделью случайного предсказания и фактически используемой хэш-функцией.
В худшем случае система, которая уже достигла этапа безопасности 2, может оказаться полностью небезопасной из-за связанных проблем Fiat-Shamir. Это требует нашего внимания и продолжения исследований. Возможно, нам потребуется изменить само преобразование Fiat-Shamir, чтобы лучше защититься от подобных уязвимостей.
Система, не использующая рекурсию, в теории более безопасна, поскольку некоторые известные атаки включают схемы, аналогичные схемам, используемым в рекурсивных доказательствах. Однако это рискованно и остается нерешенной основной проблемой.
Еще одним важным аспектом является то, что даже если zkVM доказывает, что определенная программа (заданная байт-кодом) выполняется правильно, если сам байт-код содержит ошибки, то ценность такого доказательства крайне ограничена. Таким образом, практическая применимость zkVM во многом зависит от способа генерации формально верифицированного байт-кода, что представляет собой огромное вызов и выходит за рамки данной статьи.
О квантовой устойчивости
В течение ближайших пяти лет (а может быть, и дольше) квантовые компьютеры не представляют серьезной угрозы, в то время как уязвимости программного обеспечения - вопрос жизни и смерти. Поэтому первоочередной задачей в настоящее время должно быть достижение поставленных в этой статье целей безопасности и производительности. Если неквантовоустойчивые SNARKs могут быстрее достичь этих целей, их следует использовать в первую очередь. Когда неквантовоустойчивые SNARKs догонят развитие или появятся признаки того, что квантовые компьютеры представляют реальную угрозу, можно будет рассмотреть вопрос о переключении.
Конкретный уровень безопасности
100-бит классическая безопасность - это минимальный стандарт, который должен соблюдаться для защиты ценных активов с использованием любого SNARK (но все же есть некоторые системы, не соответствующие этому низкому стандарту). Тем не менее это недопустимо, поскольку стандартные криптографические практики обычно требуют безопасности от 128 бит и выше. Если производительность SNARK действительно соответствует стандартам, мы не должны жертвовать безопасностью ради повышения производительности.
Этап производительности
текущая ситуация
В настоящее время затраты на вычисления проверяющего zkVM примерно в 1 000 000 раз превышают затраты на нативное выполнение. Иными словами, если для нативного выполнения программы требуется X циклов процессора, то примерно X × 1 000 000 циклов процессора потребуется для генерации правильного выполнения. Это было так год назад и так остается и сегодня (хотя существуют некоторые недоразумения).
Некоторые популярные термины в отрасли могут привести к недопониманию, например:
«Стоимость генерации подтверждения для всей основной сети Ethereum менее 1 миллиона долларов в год.»
«Мы почти достигли мгновенной генерации доказательств блоков Ethereum, нужно всего несколько десятков GPU».
"Наша новая zkVM в 1000 раз быстрее, чем предыдущее поколение."
Однако без контекста эти утверждения могут быть вводящими в заблуждение:
• ** В 1000 раз быстрее, чем предыдущая версия zkVM, все еще может быть очень медленным **, что скорее говорит о ** том, насколько плохо было раньше, а не насколько хорошо сейчас **.
• Вычислительная мощность основной сети Ethereum может увеличиться в 10 раз в будущем, что приведет к тому, что текущая производительность zkVM значительно не удовлетворит потребности.
• Так называемое «почти в реальном времени» создание подтверждений все еще слишком медленное для многих приложений блокчейн (например, время блока в Optimism составляет 2 секунды, что намного быстрее, чем 12 секунд в Ethereum).
• "Несколько десятков GPU, работающих 24/7 в течение длительного времени", в действительности, не может гарантировать достаточной активности.
• Это обычно относится к размеру доказательства более 1 МБ, что слишком велико для многих приложений**。
• «Затраты менее 1 миллиона долларов в год» происходят только потому, что полный узел Ethereum выполняет примерно за 25 долларов расчетов в год.
Для приложений вне блокчейна такие вычислительные затраты явно слишком высоки. Ни количество параллельных вычислений, ни инженерная оптимизация не могут компенсировать такие огромные вычислительные затраты.
Мы должны установить базовую цель: производительность не должна превышать 100 000 раз оригинального исполнения. Но даже это всего лишь первый шаг. Чтобы действительно реализовать крупномасштабные приложения для массового потребления, нам возможно потребуется снизить расходы до 10 000 раз или даже меньше оригинального исполнения.
Измерение производительности
SNARK производительность состоит из трех основных компонентов:
Эффективность фиксации системы доказывания в основании.
Оптимизация под конкретное применение (например, предварительная компиляция).
Инженерные и аппаратные ускорители (например, GPU, FPGA или многоядерный процессор).
Хотя (2) и (3) крайне важны для реального развертывания, они применимы к любой системе доказательств, поэтому не обязательно отражают улучшение основных издержек. Например, добавление ускорения GPU и предварительной компиляции к zkEVM может легко увеличить скорость в 50 раз по сравнению с простой зависимостью от ЦП — это может заставить одну систему с низкой эффективностью выглядеть лучше, чем другую систему без такой же оптимизации.
Поэтому в этой статье основное внимание уделяется основной производительности SNARK без специализированного оборудования и предварительной компиляции. Это отличается от текущих методов базового тестирования, которые обычно объединяют все три фактора в одно «общее значение». Это похоже на оценку бриллианта по времени полировки, а не по его врожденной четкости.
Наша цель - изолировать встроенные издержки общей системы удостоверения, снизить порог вхождения в технологии, которые еще не были тщательно исследованы, и помочь сообществу избавиться от помех, чтобы сосредоточиться на истинном прогрессе в проектировании системы удостоверения.
Этап производительности
Вот пять вех в моей предложенной производительности. Сначала нам нужно существенно снизить расходы на доказательство на CPU, прежде чем мы сможем дальше полагаться на аппаратное обеспечение для снижения расходов. В то же время должно быть улучшение использования памяти.
На всех этапах разработчики не должны изменять код ради производительности zkVM. Пользовательский опыт разработчиков является основным преимуществом zkVM. Если ради соответствия производительностным стандартам жертвовать DevEx, это не только лишает смысла стандартные тесты, но и противоречит первоначальной цели zkVM.
Эти показатели в основном сосредоточены на стоимости подтверждения. Однако, если допустить неограниченный рост стоимости для проверяющих (т. е. нет ограничения на размер подтверждения или время проверки), то любые показатели подтверждения могут легко быть выполнены. Поэтому, чтобы удовлетворить требования следующих этапов, необходимо одновременно ограничить максимальный размер подтверждения и максимальное время проверки.
Этап 1 требует: "разумные не тривиальные затраты на проверку"
• Размер подтверждения: должен быть меньше размера подтверждения.
• Время проверки: Скорость проверки доказательства не должна быть медленнее нативного выполнения программы (т. е. медленнее прямого выполнения вычислений).
Это минимальные требования к краткости, чтобы гарантировать, что размер подтверждения и время проверки не будут хуже, чем если бы вы просто отправили свидетельство наблюдателю и позволили ему проверить.
Этап 2 и выше
• Максимальный размер подтверждения：256 KB。
• Максимальное время проверки: 16 миллисекунд.
Эти верхние пределы намеренно установлены довольно свободно, чтобы соответствовать новым быстрым технологиям доказательства, даже если они могут привести к более высоким затратам на проверку. В то же время эти пределы исключают доказательства, столь дорогие, что практически ни один проект не захочет использовать их на блокчейне.
Этап скорости 1
Однопоточное доказательство не должно быть медленнее наивного выполнения более чем в 100 000 раз (применимо к нескольким приложениям, а не только к блокчейну Ethereum), и не должно зависеть от предварительной компиляции.
Конкретно, предположим, что процессор RISC-V на современном ноутбуке работает со скоростью около 30 миллиардов циклов в секунду. Тогда достижение этапа 1 означает, что этот ноутбук способен генерировать доказательства со скоростью 30 000 циклов RISC-V в секунду (однопоточно).
Стоимость валидатора должна соответствовать ранее определенному стандарту "разумной не тривиальной стоимости проверки".
Скоростной этап 2
Доказательство однопоточности не должно быть медленнее оригинальной реализации более чем в 10,000 раз。
ИЛИ, из-за ограничений текущих ЦП и ГПУ, вызванных некоторыми многообещающими методами SNARK (особенно в бинарном поле SNARK), эту стадию можно выполнить с использованием FPGA (или даже ASIC):
Рассчитайте количество ядер RISC-V, эмулируемых FPGA с нативной скоростью.
Рассчитать и смоделировать количество FPGA, необходимых для выполнения (почти в реальном времени) RISC-V.
Если количество (2) не превышает 10,000 раз (1), то выполняется этап 2.
• Размер подтверждения: максимум 256 KB.
• Время проверки: до 16 миллисекунд на стандартном процессоре.
Этап скорости 3
Обеспечьте накладные расходы на доказательство в пределах 1000× в дополнение к Speed Stage 2 (для широкого спектра приложений) и используйте предварительную компиляцию для автоматического синтеза и формальной проверки. По сути, набор инструкций каждой программы динамически настраивается для ускорения генерации доказательств, но он должен быть простым в использовании и формально проверенным. (См. следующий раздел о том, почему прекомпиляция — это палка о двух концах, и почему прекомпиляция «от руки» не является устойчивым подходом.) ）
Этап памяти 1
**Важно достигнуть скоростного этапа 1 на памяти менее 2 ГБ и одновременно удовлетворить требования к нулевому знанию. Этот этап крайне важен для мобильных устройств или браузеров и открывает двери для множества клиентских сценариев zkVM. Например, смартфоны используются для защиты конфиденциальности местоположения, удостоверений личности и т. д. Если генерация доказательств требует более 1-2 ГБ памяти, большинство мобильных устройств не смогут справиться.
Два важных объяснения:
Даже для крупномасштабных вычислений (требующих выполнения оригинального кода в течение десятков триллионов циклов процессора), система подтверждения также должна оставаться в пределах 2 ГБ оперативной памяти, в противном случае ее применимость будет ограничена.
Если доказать, что скорость крайне медленная, то легко сохранить ограничение 2 ГБ памяти. Таким образом, чтобы сделать фазу 1 памяти осмысленной, необходимо достигнуть скорости фазы 1 в пределах ограничения памяти 2 ГБ.
Этап памяти 2
В том случае, если объем оперативной памяти составляет менее 200 МБ, достигаетсяфаза скорости 1 (увеличивает производительность на 10 раз по сравнению с фазой памяти 1).
Почему снизить до 200 МБ? Рассмотрим не блокчейн сценарий: когда вы посещаете веб-сайт по HTTPS, вы загружаете аутентификационные и шифровальные сертификаты. Если сайт начнет отправлять эти сертификаты в форме zk-доказательств, крупные веб-сайты могут потребовать генерацию миллионов доказательств в секунду. Если каждое доказательство требует 2 ГБ памяти, потребности в вычислительных ресурсах достигнут петабайтного уровня, что явно не выполнимо. Поэтому дальнейшее снижение использования памяти критически важно для неблокчейн приложений.
Предварительная компиляция: последний метр - это все еще трость?
Предварительная компиляция означает оптимизацию системы ограничений SNARK, специально предназначенной для конкретных функций (например, хэширования, эллиптической кривой подписи). В Ethereum предварительная компиляция позволяет снизить затраты на хэширование Merkle и проверку подписи, но чрезмерная зависимость от предварительной компиляции не может действительно повысить основную эффективность SNARK.
Проблемы предварительной компиляции
1.По-прежнему слишком медленно: даже при использовании хешей и предварительной компиляции подписей zkVM по-прежнему существует проблема низкой эффективности основной системы доказательств как внутри, так и вне блокчейна.
2. Уязвимости безопасности: Если ручная предварительная компиляция не прошла формализованной проверки, то практически наверняка существуют уязвимости, которые могут привести к катастрофическим сбоям в безопасности.
3.Плохой опыт разработчика: В настоящее время многие zkVM требуют ручного написания системы ограничений разработчиками, что напоминает способ программирования 1960-х годов и серьезно влияет на опыт разработки.
4.Ошибка при тестировании на стендах: если тестирование на стендах зависит от оптимизации конкретного предварительного компилятора, это может привести к тому, что внимание людей будет сосредоточено на оптимизации системы ручных ограничений, а не на улучшении самого дизайна SNARK.
5.Затраты на ввод/вывод и отсутствие доступа к ОЗУХотя предварительная компиляция может повысить производительность тяжелых задач по шифрованию, она может оказаться бесполезной для более разнообразных нагрузок, поскольку при передаче ввода/вывода она вызывает большие затраты и не может использовать ОЗУ.
Даже в среде блокчейна, если вы превосходите единственный L1, такой как Ethereum (например, вы хотите создать ряд мостов между блокчейнами), вы столкнетесь с различными хеш-функциями и схемами подписи. Чтобы решить эту проблему, постоянно проводятся предварительные компиляции, что не только не масштабируется, но и представляет огромные риски безопасности.
Я действительно верю, что предварительная компиляция остается важной в долгосрочной перспективе, но только если она автоматически синтезируется и проходит официальную проверку. Таким образом, мы можем сохранить преимущества разработчика zkVM, избежав при этом катастрофических безопасностных рисков. Это отражено в этапе 3.
Расписание
Я ожидаю, что небольшое количество zkVM достигнет фазы скорости 1 и фазы памяти 1 в более поздний этот год. Я думаю, что мы также сможем достичь фазы скорости 2 в течение следующих двух лет, но пока не ясно, можно ли достичь эту цель без новых исследовательских идей.
Я ожидаю, что оставшиеся этапы (этап ** 3 скорости ** и этап ** 2 памяти **) потребуют нескольких лет для достижения.
Хотя в этой статье были изложены отдельно безопасность и производительность zkVM, они не являются полностью независимыми. Поскольку постоянно обнаруживаются уязвимости в zkVM, я ожидаю, что исправление некоторых из них неизбежно приведет к значительному снижению производительности. Таким образом, результаты тестирования производительности zkVM до достижения Этапа безопасности 2 должны рассматриваться как предварительные данные.
zkVM имеет огромный потенциал для реального распространения доказательств нулевого разглашения, но в настоящее время он все еще находится на ранней стадии - полон вызовов безопасности и страдает от серьезных узких мест в производительности. Спекуляции на рынке и маркетинговая реклама делают трудным измерение реального прогресса. Через четкие вехи безопасности и производительности я надеюсь предоставить карту пути, способную развеять туман. Мы в конечном итоге достигнем цели, но это потребует времени и постоянных усилий в области исследований и инженерии.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
a16z: путь к эффективной безопасности zkVM исследования
Автор: Justin Thaler источник: a16z Перевод: Шан О, Golden Finance
Виртуальная машина с нулевым знанием (zkVMs) призвана сделать SNARKs более доступными, позволяя даже людям без специализированных знаний по SNARK доказать, что они правильно выполнили определенную программу на конкретном вводе (или свидетельстве). Ее основное преимущество заключается в опыте разработчика, но в настоящее время zkVMs все еще сталкиваются с огромными вызовами в области безопасности и производительности. Если zkVMs хотят оправдать свои обещания, разработчики должны преодолеть эти препятствия. В этой статье будет рассмотрено возможное развитие zkVM, и весь процесс, вероятно, потребует несколько лет для завершения - не верьте тем, кто говорит, что это можно быстро сделать.
Изложение вызовов
В аспекте безопасности zkVMs являются сложным программным проектом, который все еще полон уязвимостей.
В аспекте производительности доказательство правильного выполнения программы может быть медленным на десятки тысяч раз, что делает большинство приложений непригодными для развертывания в реальном мире.
Тем не менее, многие голоса в отрасли блокчейнов до сих пор пропагандируют, что zkVMs можно немедленно развернуть, и даже некоторые проекты уже платят высокую цену за вычислительные затраты для генерации нулевых доказательств активности на цепи. Однако, поскольку у zkVMs все еще существует множество уязвимостей, такой подход на самом деле является дорогим обманом, который делает систему похожей на защищенную SNARK, тогда как на самом деле она или зависит от управления разрешениями, или, что еще хуже, — подвергается риску атак.
Фактическая ситуация такова, что до построения действительно безопасного и эффективного zkVM нам еще много лет. В этой статье предлагается ряд конкретных и поэтапных целей, чтобы помочь нам отслеживать реальный прогресс zkVM, уменьшить спекуляции и направить внимание сообщества на действительные технические прорывы.
Этап развития безопасности
Фон
На базе SNARK обычно есть два основных компонента zkVMs:
Интерактивное доказательство оракула полиномиальной сложности (Polynomial Interactive Oracle Proof, PIOP): фреймворк для доказательства полиномиальных (или ограничений, происходящих от полинома) взаимодействий.
Схема обязательства полинома (Polynomial Commitment Scheme, PCS): гарантирует, что доказатель не может подделать результат оценки полинома, не будучи обнаруженным.
zkVM через кодирование действительных исполнительных следов в виде систем ограничений обеспечивает правильное использование регистров и памяти виртуальной машины, а затем с использованием SNARK доказывает удовлетворение этих ограничений.
В такой сложной системе единственным способом обеспечения отсутствия уязвимостей в zkVM является формальная проверка. Ниже приведены различные этапы безопасности zkVM, где первый этап фокусируется на правильности протокола, второй и третий этапы фокусируются на правильности реализации.
Этап 1 безопасности: правильный протокол
Если zkVM использует рекурсию, то в процессе рекурсии все, что касается PIOP, обязательств и систем ограничений, должно быть проверено, в противном случае этап не будет считаться завершенным.
Этап 2 безопасности: правильная реализация валидатора
Этап требует проведения формальной верификации фактической реализации валидатора zkVM (например, на Rust, Solidity и т. д.), чтобы убедиться, что она соответствует протоколу, который уже был проверен на первом этапе. Завершение этого этапа означает, что реализация zkVM соответствует теоретическому дизайну и не является просто бумажным безопасным протоколом или неэффективной спецификацией, написанной на Lean или подобных языках.
Почему только о валидаторах, а не о доказателях есть две основные причины: во-первых, обеспечение правильности валидаторов гарантирует целостность системы доказательств zkVM (т. е. гарантирует, что валидаторы не будут обмануты и примут неверное доказательство). Во-вторых, реализация валидатора zkVM проще реализации доказателя более чем на порядок, и правильность валидатора легче гарантировать в краткосрочной перспективе.
Этап безопасности 3: достижение правильного подтверждающего лица
На этапе требуется провести формальную верификацию доказательств выполнения zkVM, чтобы гарантировать, что оно сможет правильно генерировать доказательства системы, которые уже были проверены на первом и втором этапах. Цель этого этапа - полнота: любая система, использующая zkVM, не должна зависать из-за невозможности доказать какое-либо правомерное утверждение. Если zkVM должен обладать нулевым разглашением, необходимо провести формальную верификацию, чтобы гарантировать, что доказательства не раскроют никакой информации о свидетельствах.
Временное расписание
Этап 1 Прогресс: Мы можем ожидать некоторого прогресса в следующем году (например, усилия по ZKLib). Но как минимум два года ни один zkVM не сможет полностью удовлетворить требования 1 этапа.
Этап 2 и этап 3 : Эти этапы могут параллельно развиваться с некоторыми аспектами этапа 1. Например, некоторые команды уже доказали соответствие реализации Plonk-верификатора протоколу из статьи (хотя сам протокол из статьи может быть не полностью проверен). Тем не менее, я ожидаю, что ни один zkVM не достигнет этапа 3 менее чем за четыре года - возможно, даже дольше.
Ключевые моменты: безопасность Fiat-Shamir и верифицированный байт-код
Одной из основных проблем сложности является то, что безопасность преобразования Фиата-Шамира по-прежнему является неразрешенной проблемой исследований. Все три этапа безопасности рассматривают Фиата-Шамира и случайное предсказание как абсолютно безопасные, но на самом деле вся парадигма может иметь уязвимости. Это происходит из-за различий между идеализированной моделью случайного предсказания и фактически используемой хэш-функцией.
В худшем случае система, которая уже достигла этапа безопасности 2, может оказаться полностью небезопасной из-за связанных проблем Fiat-Shamir. Это требует нашего внимания и продолжения исследований. Возможно, нам потребуется изменить само преобразование Fiat-Shamir, чтобы лучше защититься от подобных уязвимостей.
Система, не использующая рекурсию, в теории более безопасна, поскольку некоторые известные атаки включают схемы, аналогичные схемам, используемым в рекурсивных доказательствах. Однако это рискованно и остается нерешенной основной проблемой.
Еще одним важным аспектом является то, что даже если zkVM доказывает, что определенная программа (заданная байт-кодом) выполняется правильно, если сам байт-код содержит ошибки, то ценность такого доказательства крайне ограничена. Таким образом, практическая применимость zkVM во многом зависит от способа генерации формально верифицированного байт-кода, что представляет собой огромное вызов и выходит за рамки данной статьи.
О квантовой устойчивости
В течение ближайших пяти лет (а может быть, и дольше) квантовые компьютеры не представляют серьезной угрозы, в то время как уязвимости программного обеспечения - вопрос жизни и смерти. Поэтому первоочередной задачей в настоящее время должно быть достижение поставленных в этой статье целей безопасности и производительности. Если неквантовоустойчивые SNARKs могут быстрее достичь этих целей, их следует использовать в первую очередь. Когда неквантовоустойчивые SNARKs догонят развитие или появятся признаки того, что квантовые компьютеры представляют реальную угрозу, можно будет рассмотреть вопрос о переключении.
Конкретный уровень безопасности
100-бит классическая безопасность - это минимальный стандарт, который должен соблюдаться для защиты ценных активов с использованием любого SNARK (но все же есть некоторые системы, не соответствующие этому низкому стандарту). Тем не менее это недопустимо, поскольку стандартные криптографические практики обычно требуют безопасности от 128 бит и выше. Если производительность SNARK действительно соответствует стандартам, мы не должны жертвовать безопасностью ради повышения производительности.
Этап производительности
текущая ситуация
В настоящее время затраты на вычисления проверяющего zkVM примерно в 1 000 000 раз превышают затраты на нативное выполнение. Иными словами, если для нативного выполнения программы требуется X циклов процессора, то примерно X × 1 000 000 циклов процессора потребуется для генерации правильного выполнения. Это было так год назад и так остается и сегодня (хотя существуют некоторые недоразумения).
Некоторые популярные термины в отрасли могут привести к недопониманию, например:
«Стоимость генерации подтверждения для всей основной сети Ethereum менее 1 миллиона долларов в год.»
«Мы почти достигли мгновенной генерации доказательств блоков Ethereum, нужно всего несколько десятков GPU».
"Наша новая zkVM в 1000 раз быстрее, чем предыдущее поколение."
Однако без контекста эти утверждения могут быть вводящими в заблуждение:
• ** В 1000 раз быстрее, чем предыдущая версия zkVM, все еще может быть очень медленным **, что скорее говорит о ** том, насколько плохо было раньше, а не насколько хорошо сейчас **.
• Вычислительная мощность основной сети Ethereum может увеличиться в 10 раз в будущем, что приведет к тому, что текущая производительность zkVM значительно не удовлетворит потребности.
• Так называемое «почти в реальном времени» создание подтверждений все еще слишком медленное для многих приложений блокчейн (например, время блока в Optimism составляет 2 секунды, что намного быстрее, чем 12 секунд в Ethereum).
• "Несколько десятков GPU, работающих 24/7 в течение длительного времени", в действительности, не может гарантировать достаточной активности.
• Это обычно относится к размеру доказательства более 1 МБ, что слишком велико для многих приложений**。
• «Затраты менее 1 миллиона долларов в год» происходят только потому, что полный узел Ethereum выполняет примерно за 25 долларов расчетов в год.
Для приложений вне блокчейна такие вычислительные затраты явно слишком высоки. Ни количество параллельных вычислений, ни инженерная оптимизация не могут компенсировать такие огромные вычислительные затраты.
Мы должны установить базовую цель: производительность не должна превышать 100 000 раз оригинального исполнения. Но даже это всего лишь первый шаг. Чтобы действительно реализовать крупномасштабные приложения для массового потребления, нам возможно потребуется снизить расходы до 10 000 раз или даже меньше оригинального исполнения.
Измерение производительности
SNARK производительность состоит из трех основных компонентов:
Эффективность фиксации системы доказывания в основании.
Оптимизация под конкретное применение (например, предварительная компиляция).
Инженерные и аппаратные ускорители (например, GPU, FPGA или многоядерный процессор).
Хотя (2) и (3) крайне важны для реального развертывания, они применимы к любой системе доказательств, поэтому не обязательно отражают улучшение основных издержек. Например, добавление ускорения GPU и предварительной компиляции к zkEVM может легко увеличить скорость в 50 раз по сравнению с простой зависимостью от ЦП — это может заставить одну систему с низкой эффективностью выглядеть лучше, чем другую систему без такой же оптимизации.
Поэтому в этой статье основное внимание уделяется основной производительности SNARK без специализированного оборудования и предварительной компиляции. Это отличается от текущих методов базового тестирования, которые обычно объединяют все три фактора в одно «общее значение». Это похоже на оценку бриллианта по времени полировки, а не по его врожденной четкости.
Наша цель - изолировать встроенные издержки общей системы удостоверения, снизить порог вхождения в технологии, которые еще не были тщательно исследованы, и помочь сообществу избавиться от помех, чтобы сосредоточиться на истинном прогрессе в проектировании системы удостоверения.
Этап производительности
Вот пять вех в моей предложенной производительности. Сначала нам нужно существенно снизить расходы на доказательство на CPU, прежде чем мы сможем дальше полагаться на аппаратное обеспечение для снижения расходов. В то же время должно быть улучшение использования памяти.
На всех этапах разработчики не должны изменять код ради производительности zkVM. Пользовательский опыт разработчиков является основным преимуществом zkVM. Если ради соответствия производительностным стандартам жертвовать DevEx, это не только лишает смысла стандартные тесты, но и противоречит первоначальной цели zkVM.
Эти показатели в основном сосредоточены на стоимости подтверждения. Однако, если допустить неограниченный рост стоимости для проверяющих (т. е. нет ограничения на размер подтверждения или время проверки), то любые показатели подтверждения могут легко быть выполнены. Поэтому, чтобы удовлетворить требования следующих этапов, необходимо одновременно ограничить максимальный размер подтверждения и максимальное время проверки.
Этап 1 требует: "разумные не тривиальные затраты на проверку"
• Размер подтверждения: должен быть меньше размера подтверждения.
• Время проверки: Скорость проверки доказательства не должна быть медленнее нативного выполнения программы (т. е. медленнее прямого выполнения вычислений).
Это минимальные требования к краткости, чтобы гарантировать, что размер подтверждения и время проверки не будут хуже, чем если бы вы просто отправили свидетельство наблюдателю и позволили ему проверить.
Этап 2 и выше
• Максимальный размер подтверждения：256 KB。
• Максимальное время проверки: 16 миллисекунд.
Эти верхние пределы намеренно установлены довольно свободно, чтобы соответствовать новым быстрым технологиям доказательства, даже если они могут привести к более высоким затратам на проверку. В то же время эти пределы исключают доказательства, столь дорогие, что практически ни один проект не захочет использовать их на блокчейне.
Этап скорости 1
Однопоточное доказательство не должно быть медленнее наивного выполнения более чем в 100 000 раз (применимо к нескольким приложениям, а не только к блокчейну Ethereum), и не должно зависеть от предварительной компиляции.
Конкретно, предположим, что процессор RISC-V на современном ноутбуке работает со скоростью около 30 миллиардов циклов в секунду. Тогда достижение этапа 1 означает, что этот ноутбук способен генерировать доказательства со скоростью 30 000 циклов RISC-V в секунду (однопоточно).
Стоимость валидатора должна соответствовать ранее определенному стандарту "разумной не тривиальной стоимости проверки".
Скоростной этап 2
Доказательство однопоточности не должно быть медленнее оригинальной реализации более чем в 10,000 раз。
ИЛИ, из-за ограничений текущих ЦП и ГПУ, вызванных некоторыми многообещающими методами SNARK (особенно в бинарном поле SNARK), эту стадию можно выполнить с использованием FPGA (или даже ASIC):
Рассчитайте количество ядер RISC-V, эмулируемых FPGA с нативной скоростью.
Рассчитать и смоделировать количество FPGA, необходимых для выполнения (почти в реальном времени) RISC-V.
Если количество (2) не превышает 10,000 раз (1), то выполняется этап 2.
• Размер подтверждения: максимум 256 KB.
• Время проверки: до 16 миллисекунд на стандартном процессоре.
Этап скорости 3
Обеспечьте накладные расходы на доказательство в пределах 1000× в дополнение к Speed Stage 2 (для широкого спектра приложений) и используйте предварительную компиляцию для автоматического синтеза и формальной проверки. По сути, набор инструкций каждой программы динамически настраивается для ускорения генерации доказательств, но он должен быть простым в использовании и формально проверенным. (См. следующий раздел о том, почему прекомпиляция — это палка о двух концах, и почему прекомпиляция «от руки» не является устойчивым подходом.) ）
Этап памяти 1
**Важно достигнуть скоростного этапа 1 на памяти менее 2 ГБ и одновременно удовлетворить требования к нулевому знанию. Этот этап крайне важен для мобильных устройств или браузеров и открывает двери для множества клиентских сценариев zkVM. Например, смартфоны используются для защиты конфиденциальности местоположения, удостоверений личности и т. д. Если генерация доказательств требует более 1-2 ГБ памяти, большинство мобильных устройств не смогут справиться.
Два важных объяснения:
Даже для крупномасштабных вычислений (требующих выполнения оригинального кода в течение десятков триллионов циклов процессора), система подтверждения также должна оставаться в пределах 2 ГБ оперативной памяти, в противном случае ее применимость будет ограничена.
Если доказать, что скорость крайне медленная, то легко сохранить ограничение 2 ГБ памяти. Таким образом, чтобы сделать фазу 1 памяти осмысленной, необходимо достигнуть скорости фазы 1 в пределах ограничения памяти 2 ГБ.
Этап памяти 2
В том случае, если объем оперативной памяти составляет менее 200 МБ, достигаетсяфаза скорости 1 (увеличивает производительность на 10 раз по сравнению с фазой памяти 1).
Почему снизить до 200 МБ? Рассмотрим не блокчейн сценарий: когда вы посещаете веб-сайт по HTTPS, вы загружаете аутентификационные и шифровальные сертификаты. Если сайт начнет отправлять эти сертификаты в форме zk-доказательств, крупные веб-сайты могут потребовать генерацию миллионов доказательств в секунду. Если каждое доказательство требует 2 ГБ памяти, потребности в вычислительных ресурсах достигнут петабайтного уровня, что явно не выполнимо. Поэтому дальнейшее снижение использования памяти критически важно для неблокчейн приложений.
Предварительная компиляция: последний метр - это все еще трость?
Предварительная компиляция означает оптимизацию системы ограничений SNARK, специально предназначенной для конкретных функций (например, хэширования, эллиптической кривой подписи). В Ethereum предварительная компиляция позволяет снизить затраты на хэширование Merkle и проверку подписи, но чрезмерная зависимость от предварительной компиляции не может действительно повысить основную эффективность SNARK.
Проблемы предварительной компиляции
1.По-прежнему слишком медленно: даже при использовании хешей и предварительной компиляции подписей zkVM по-прежнему существует проблема низкой эффективности основной системы доказательств как внутри, так и вне блокчейна.
2. Уязвимости безопасности: Если ручная предварительная компиляция не прошла формализованной проверки, то практически наверняка существуют уязвимости, которые могут привести к катастрофическим сбоям в безопасности.
3.Плохой опыт разработчика: В настоящее время многие zkVM требуют ручного написания системы ограничений разработчиками, что напоминает способ программирования 1960-х годов и серьезно влияет на опыт разработки.
4.Ошибка при тестировании на стендах: если тестирование на стендах зависит от оптимизации конкретного предварительного компилятора, это может привести к тому, что внимание людей будет сосредоточено на оптимизации системы ручных ограничений, а не на улучшении самого дизайна SNARK.
5.Затраты на ввод/вывод и отсутствие доступа к ОЗУХотя предварительная компиляция может повысить производительность тяжелых задач по шифрованию, она может оказаться бесполезной для более разнообразных нагрузок, поскольку при передаче ввода/вывода она вызывает большие затраты и не может использовать ОЗУ.
Даже в среде блокчейна, если вы превосходите единственный L1, такой как Ethereum (например, вы хотите создать ряд мостов между блокчейнами), вы столкнетесь с различными хеш-функциями и схемами подписи. Чтобы решить эту проблему, постоянно проводятся предварительные компиляции, что не только не масштабируется, но и представляет огромные риски безопасности.
Я действительно верю, что предварительная компиляция остается важной в долгосрочной перспективе, но только если она автоматически синтезируется и проходит официальную проверку. Таким образом, мы можем сохранить преимущества разработчика zkVM, избежав при этом катастрофических безопасностных рисков. Это отражено в этапе 3.
Расписание
Я ожидаю, что небольшое количество zkVM достигнет фазы скорости 1 и фазы памяти 1 в более поздний этот год. Я думаю, что мы также сможем достичь фазы скорости 2 в течение следующих двух лет, но пока не ясно, можно ли достичь эту цель без новых исследовательских идей.
Я ожидаю, что оставшиеся этапы (этап ** 3 скорости ** и этап ** 2 памяти **) потребуют нескольких лет для достижения.
Хотя в этой статье были изложены отдельно безопасность и производительность zkVM, они не являются полностью независимыми. Поскольку постоянно обнаруживаются уязвимости в zkVM, я ожидаю, что исправление некоторых из них неизбежно приведет к значительному снижению производительности. Таким образом, результаты тестирования производительности zkVM до достижения Этапа безопасности 2 должны рассматриваться как предварительные данные.
zkVM имеет огромный потенциал для реального распространения доказательств нулевого разглашения, но в настоящее время он все еще находится на ранней стадии - полон вызовов безопасности и страдает от серьезных узких мест в производительности. Спекуляции на рынке и маркетинговая реклама делают трудным измерение реального прогресса. Через четкие вехи безопасности и производительности я надеюсь предоставить карту пути, способную развеять туман. Мы в конечном итоге достигнем цели, но это потребует времени и постоянных усилий в области исследований и инженерии.