Путь к безопасным и эффективным zkVMs: как отслеживать прогресс
Автор оригинала: a16z crypto
Golem, Оdaily планетарная газета
zkVM (Zero Knowledge Virtual Machine) обещает 'демократизировать SNARK', позволяя любому человеку (даже без специальных знаний о SNARK) доказать, что они правильно выполнили любую программу на данном входе (или свидетельстве). Их основные преимущества заключаются в опыте разработчика, но в настоящее время они сталкиваются с огромными вызовами в области безопасности и производительности. Чтобы претворить в жизнь обещание zkVM, разработчики должны преодолеть эти вызовы. В этой статье я перечислил возможные этапы развития zkVM, завершение которых займет несколько лет.
Вызов
В аспекте безопасности zkVM является высоко сложным программным проектом, который все еще полон уязвимостей. В плане производительности скорость доказательства правильного выполнения программы может быть медленнее на несколько порядков по сравнению с локальным выполнением, что делает невозможным развертывание большинства приложений в реальном мире.
Несмотря на эти реальные вызовы, большинство компаний в сфере блокчейн описывают zkVM как то, что можно немедленно развернуть. На самом деле, некоторые проекты уже заплатили огромные вычислительные затраты для генерации доказательств цепочечной активности. Однако, поскольку zkVM все еще несовершенен, это просто дорогой способ притвориться, что система защищена SNARK, когда на самом деле она либо защищена разрешением, либо, что хуже, подвержена атакам.
Нам осталось несколько лет до реализации безопасной и высокопроизводительной zkVM. В этой статье предлагается ряд конкретных этапных целей для отслеживания прогресса zkVM - эти цели могут устранить раздутость и помочь сообществу сосредоточиться на реальном прогрессе.
Этап безопасности
ZkVM, основанный на SNARK, обычно включает в себя две основные компоненты:
· Интерактивное доказательство Oracle для полиномиальной интеракции (PIOP): используется для доказательства утверждений о полиноме (или выводимых из него ограничений) в интерактивной рамке доказательства.
· Схема обязательства полинома (PCS): гарантирует, что доказатель не может лгать при оценке полинома, не будучи обнаруженным.
zkVM в сущности преобразует эффективное выполнение в трассировку кода в системе ограничений - что в общем смысле означает, что они заставляют виртуальную машину правильно использовать регистры и память - и затем применяет SNARK для доказательства того, что эти ограничения выполняются.
Убедитесь, что единственным способом избежать ошибок в сложных системах, таких как zkVM, является формальная верификация. Вот разделение на этапы безопасности. Фаза 1 фокусируется на правильном протоколе, в то время как фазы 2 и 3 фокусируются на правильной реализации.
Этап безопасности 1: Правильный протокол
1、Формальное подтверждение надежности PIOP；
2、PCS в некоторых криптографических предположениях или идеальных моделях имеет силу ограничительного доказательства;
3、Если использовать Fiat-Shamir, то сочетая краткое доказательство, полученное с помощью PIOP и PCS, в случайной оракульской модели безопасно формально подтверждать доказательства (при необходимости с применением других криптографических предположений для усиления).
4、Система ограничений, используемая в PIOP, эквивалентна формальному доказательству семантики VM;
5、Сложите все эти части в одно целое, прошедшее формализованную проверку, безопасное доказательство SNARK, для выполнения любой программы, указанной в байт-коде ВМ. Если протокол планирует реализацию нулевого разглашения, это свойство также должно быть формализовано для обеспечения неразглашения чувствительной информации о свидетеле.
Предупреждение о рекурсии: Если zkVM использует рекурсию, то необходимо проверить каждый PIOP, коммитмент и систему ограничений, связанные с этой рекурсией, прежде чем можно считать эту фазу завершенной.
Этап безопасности 2: правильная реализация валидатора
Формальное доказательство соответствия фактической реализации верификатора zkVM (используя Rust, Solidity и т. д.) протоколу первой фазы проверки. Это обеспечивает разумность реализованного протокола (а не только дизайн на бумаге или неэффективную спецификацию, написанную на Lean и т. д.).
Вторая фаза сосредоточена исключительно на реализации валидатора (а не доказывателя) по двум причинам. Во-первых, правильное использование валидатора достаточно для обеспечения надежности (то есть гарантия того, что валидатор не может доверять никаким ложным утверждениям на самом деле является истинным). Во-вторых, реализация валидатора zkVM проще, чем реализация доказывателя на порядок.
Этап безопасности 3: правильная реализация доказателя
Реализация проверяющего zkVM действительно генерирует доказательства системы проверки фазы 1 и фазы 2, то есть формальная проверка. Это обеспечивает целостность, то есть ни одна система, использующая zkVM, не застревает на недоказуемых высказываниях. Если проверяющий намерен реализовать нулевое знание, то это свойство должно быть формально проверено.
План времени
**· Этап 1: **Мы можем ожидать постепенных достижений в следующем году (например, ZKLib). Но как минимум в течение двух лет zkVM не сможет полностью удовлетворить требования этапа 1;
· Этапы 2 и 3: Эти этапы могут одновременно продвигаться с некоторыми аспектами этапа 1. Например, некоторые команды уже доказали соответствие реализации валидатора Plonk с протоколом из статьи (хотя сам протокол из статьи может быть не полностью проверен). Тем не менее, я ожидаю, что ни один zkVM не достигнет 3-го этапа менее чем за четыре года - и, возможно, дольше.
Важные заметки: безопасность Fiat-Shamir и проверенный байт-код
Одним из основных сложных факторов является наличие нерешенных исследовательских проблем в области безопасности вокруг преобразования Фиата-Шамира. Все три этапа рассматривают Фиата-Шамира и случайного предсказателя как непоколебимую часть их безопасности, но, на самом деле, вся парадигма может иметь уязвимости. Это связано с излишне идеализированным случайным предсказателем и различиями между ним и фактически используемыми хэш-функциями. В худшем случае система, находящаяся на втором этапе из-за проблемы Фиата-Шамира, может позднее оказаться полностью небезопасной. Это вызывает серьезные опасения и продолжительные исследования. Возможно, нам потребуется изменить само преобразование для более эффективной защиты от таких уязвимостей.
Система без рекурсии в теории более устойчива, потому что некоторые известные атаки связаны с использованием схем, аналогичных схемам, используемым в рекурсивных доказательствах.
Еще одним важным моментом является то, что если сам байт-код содержит дефекты, то даже если компьютерная программа выполняется правильно (по указанию байт-кода), ее ценность ограничена. Таким образом, практическая ценность zkVM во многом зависит от методов создания формальной верификации байт-кода - это огромное вызов, выходящий за рамки обсуждения в данной статье.
О безопасности в постквантовую эпоху
По крайней мере, в течение ближайших пяти лет (а возможно, и дольше) квантовые компьютеры не представляют серьезной угрозы, в то время как уязвимости являются риском выживания. Поэтому основное внимание сейчас следует уделять обеспечению безопасности и производительности, о которых говорится в данной статье. Если мы можем использовать неквантово-безопасные SNARK для более быстрого удовлетворения этих требований к безопасности, то мы должны это сделать до тех пор, пока квантовые SNARK не догонят нас, или пока люди серьезно начнут беспокоиться о появлении квантовых компьютеров, связанных с шифрованием.
Текущее состояние производительности zkVM
В настоящее время коэффициент издержек, генерируемых доказывателем zkVM, близок к сто миллионам первоначальных затрат на выполнение. Если программе требуется X циклов для работы, то стоимость правильного выполнения составляет примерно X умножить на сто миллионов циклов ЦП. Это было так год назад, и так остается и по сей день.
Популярные повествования обычно описывают этот расход таким образом, чтобы звучало приемлемо. Например:
·«Стоимость создания подтверждения главной сети Ethereum не превышает один миллион долларов в год.»
·「Мы почти можем использовать кластер из десятков GPU для реального времени генерации доказательства блока Ethereum.」
«Наша последняя zkVM в 1000 раз быстрее, чем ее предшественник».
Хотя с технической точки зрения эти утверждения являются точными, но без соответствующего контекста они могут ввести в заблуждение. Например:
· По сравнению с предыдущей версией zkVM скорость увеличилась в 1000 раз, но абсолютная скорость все еще очень медленная. Это скорее указывает на то, насколько плохи дела, а не насколько хороши они.
· Кто-то уже предложил увеличить объем вычислений на главной сети 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 в угоду производительности будет противоречить смыслу zkVM.
Эти показатели сосредоточены на затратах для подтверждающих лиц. Однако, если разрешить неограниченные затраты на подтверждающие лица (т. е. нет ограничений на размер подтверждения или время проверки), то легко можно удовлетворить любые показатели подтверждающих лиц. Поэтому для системы, которая должна соответствовать этапу, необходимо определить максимальные значения для размера подтверждения и времени проверки.
требования к производительности
Этап 1 требует: «разумные и необычные затраты на проверку»:
· Размер подтверждения: размер подтверждения должен быть меньше размера свидетельства.
· Время проверки: скорость проверки утверждений не должна быть медленнее скорости выполнения локальной программы (т. е. выполнение вычислений без доказательства правильности).
Это минимальные требования к компактности. Они гарантируют, что размер доказательства и время проверки не будут хуже, чем отправка свидетельства проверяющему и непосредственная проверка его правильности проверяющим.
Требования с 2 этапа и далее:
· Максимальный размер подтверждения: 256 KB。
· Максимальное время проверки: 16 миллисекунд.
Эти пороговые значения специально увеличены, чтобы адаптироваться к новым технологиям быстрого доказательства, которые могут привести к повышенным затратам на проверку. В то же время они исключают очень дорогостоящие доказательства, из-за чего мало какие проекты готовы включить их в блокчейн.
Стадия скорости 1
Доказательство однопоточности должно быть медленнее, по меньшей мере, в сто тысяч раз, чем локальное выполнение, измеренное на ряде приложений (не только на блоках Ethereum), не зависящих от предварительной компиляции.
Конкретно, представьте себе процесс RISC-V, который работает на современном ноутбуке на частоте около 30 миллиардов циклов в секунду. Достижение 1-й фазы означает, что вы можете каждую секунду доказать примерно 30 000 циклов RISC-V (однопоточный) на том же ноутбуке. Но стоимость верификации должна быть, как уже упоминалось, "разумной и не тривиальной".
Стадия скорости 2
Доказательство однопоточности должно быть медленнее, чем локальное выполнение как минимум в десять тысяч раз.
Или, возможно, из-за того, что некоторые перспективные методы SNARK (особенно те, основанные на бинарных полях) в настоящее время затруднены процессором и видеокартой, вы можете достичь этой стадии, сравнивая использование FPGA (или даже ASIC):
FPGA может имитировать количество ядер RISC-V с местной скоростью;
Моделирование и демонстрация (почти) в реальном времени требуемого количества FPGA для выполнения RISC-V.
Если последнее не более чем в 10 000 раз больше, чем первое, вы имеете право перейти ко второму этапу. На стандартном процессоре размер доказательства должен быть не более 256 КБ, а время проверки - не более 16 мс.
Стадия скорости 3
Помимо достижения скорости уровня 2, можно использовать предварительную компиляцию с автоматическим синтезом и формальной верификацией для снижения затрат на доказательства на порядок менее 1000 (применимо к широкому спектру приложений). В сущности, можно настраивать наборы инструкций для ускорения доказательств для каждой программы, но это должно происходить способом, удобным для использования и формальной верификации.
Этап памяти 1
Скорость на этапе 1 достигается при условии, что для доказательства требуется менее 2 ГБ оперативной памяти (при этом также достигается нулевое знание).
Для многих мобильных устройств или браузеров это критически важно, поэтому открывается бесчисленное количество применений zkVM для клиентов. Важность клиентского подтверждения заключается в том, что наши мобильные телефоны являются нашей постоянной связью с реальным миром: они отслеживают наше местоположение, удостоверения и т. д. Если для генерации подтверждений требуется более 1-2 ГБ памяти, то для большинства современных мобильных устройств это слишком много. Необходимо уточнить два момента:
· 2 ГБ предела пространства применимы для крупных выражений (выражений, требующих выполнения десятков триллионов циклов ЦП на локальном уровне). Системы доказательства предела пространства для малых выражений имеют ограниченную применимость.
· Если проверяющий работает очень медленно, то легко держать потребление памяти проверяющего ниже 2 ГБ. Поэтому, чтобы сделать этап памяти 1 не настолько простым, я требую, чтобы этап 1 выполнялся в пределах 2 ГБ.
Этап 2 памяти
Скорость этапа 1 достигается при использовании менее 200 МБ оперативной памяти (в 10 раз лучше, чем этап 1 по памяти).
Зачем снижать объем до 2 ГБ? Рассмотрим пример не блокчейн-приложения: каждый раз при доступе к веб-сайту через HTTPS вы загружаете сертификаты для аутентификации и шифрования. Вместо этого сайт может отправлять zk-доказательства, имеющие эти сертификаты. Большие веб-сайты могут генерировать сотни тысяч таких доказательств в секунду. Если каждое доказательство требует 2 ГБ памяти для создания, то в общей сложности потребуется оперативная память уровня PB. Дальнейшее снижение использования памяти критически важно для не блокчейн-решений.
Предварительная компиляция: последняя миля или трость?
В конструкции zkVM предварительная компиляция означает специализированные SNARK (или системы ограничений), настроенные на конкретные функции, такие как хеш-функции Keccak/SHA для цифровой подписи или операции над группами эллиптических кривых. В Ethereum (где большая часть тяжелой работы связана с Merkle-хешами и проверкой подписей), некоторые ручные предварительные компиляции могут сократить расходы на верификатор. Однако полагаться на них как на костыль не позволит SNARK достичь свой цели. Причины следующие:
· Для большинства приложений (внутри и снаружи блокчейна) все еще слишком медленно: даже с использованием предварительной компиляции хэшей и подписей, текущая zkVM все еще слишком медленна (как внутри, так и вне блокчейна), потому что основная система доказательств неэффективна.
· Проблемы безопасности: Неофициальная ручная предварительная компиляция практически наверняка содержит ошибки, что может привести к катастрофическим сбоям безопасности.
· Опыт разработчика неудовлетворителен: В большинстве существующих zkVM добавление новых прекомпиляций означает ручное написание систем ограничений для каждой функции — это суть возвращения к рабочему процессу стиля 1960-х годов. Даже при использовании существующих прекомпиляций разработчики должны переписывать код для вызова каждой прекомпиляции. Мы должны оптимизировать безопасность и опыт разработчика, а не жертвовать ими в погоне за приростом производительности. Такой подход лишь доказывает, что производительность не соответствует ожидаемому уровню.
· I/O расходы и отсутствие ОЗУ: Хотя предварительная компиляция может повысить производительность тяжелых задач по шифрованию, она может быть неспособной обеспечить смысловое ускорение для более разнообразных рабочих нагрузок из-за больших расходов на ввод/вывод при их передаче и невозможности использования ОЗУ. Даже в среде блокчейна, при преодолении ограничений одноплатформенных L1, таких как Ethereum (например, если вы хотите построить серию межцепных мостов), вам придется столкнуться с другими хэш-функциями и схемами подписи. Многократное использование предварительной компиляции для решения проблем неспособно масштабироваться и несет значительные риски безопасности.
По всем этим причинам наш главный приоритет - повысить эффективность базовой zkVM. Лучшая технология zkVM приведет к лучшим предварительным компиляциям. Я действительно верю, что предварительные компиляции останутся важными в долгосрочной перспективе, но только если они будут автоматически синтезированы и официально проверены. Таким образом, можно сохранить преимущества разработчиков zkVM и избежать катастрофических безопасностей. Это отражено в этапе 3 скорости.
План времени
Я ожидаю, что некоторые zkVM будут реализованы позднее в этом году, включая этап 1 скорости и этап 1 памяти. Я думаю, что мы также достигнем этапа 2 скорости в течение следующих двух лет, но пока неясно, сможем ли мы достичь этой цели без новых идей, которые еще не появились. Я предполагаю, что для завершения оставшихся этапов (этап 3 скорости и этап 2 памяти) потребуется несколько лет.
Обзор
Хотя я разделил этапы безопасности и производительности zkVM в этой статье, эти аспекты zkVM не являются полностью независимыми. По мере обнаружения большего количества уязвимостей в zkVM ожидается, что некоторые из них можно будет исправить только при значительном снижении производительности. До достижения zkVM уровня безопасности 2 производительность должна быть отложена.
zkVM имеет потенциал сделать доказательства с нулевым разглашением действительно широко распространенными, но они все еще находятся на начальном этапе, полном вызовов безопасности и огромных затрат на производительность. Рекламная деятельность и маркетинг делают оценку реальных успехов затруднительной. Путем уточнения конкретных безопасных и производительностных вех мы надеемся предоставить карту пути, свободную от помех. Мы достигнем поставленных целей, но это потребует времени и упорного труда.
Ссылка на оригинал
：
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
a16z: Как поэтапно реализовать безопасную и эффективную zkVM (обязательно для разработчиков)
Путь к безопасным и эффективным zkVMs: как отслеживать прогресс
zkVM (Zero Knowledge Virtual Machine) обещает 'демократизировать SNARK', позволяя любому человеку (даже без специальных знаний о SNARK) доказать, что они правильно выполнили любую программу на данном входе (или свидетельстве). Их основные преимущества заключаются в опыте разработчика, но в настоящее время они сталкиваются с огромными вызовами в области безопасности и производительности. Чтобы претворить в жизнь обещание zkVM, разработчики должны преодолеть эти вызовы. В этой статье я перечислил возможные этапы развития zkVM, завершение которых займет несколько лет.
Вызов
В аспекте безопасности zkVM является высоко сложным программным проектом, который все еще полон уязвимостей. В плане производительности скорость доказательства правильного выполнения программы может быть медленнее на несколько порядков по сравнению с локальным выполнением, что делает невозможным развертывание большинства приложений в реальном мире.
Несмотря на эти реальные вызовы, большинство компаний в сфере блокчейн описывают zkVM как то, что можно немедленно развернуть. На самом деле, некоторые проекты уже заплатили огромные вычислительные затраты для генерации доказательств цепочечной активности. Однако, поскольку zkVM все еще несовершенен, это просто дорогой способ притвориться, что система защищена SNARK, когда на самом деле она либо защищена разрешением, либо, что хуже, подвержена атакам.
Нам осталось несколько лет до реализации безопасной и высокопроизводительной zkVM. В этой статье предлагается ряд конкретных этапных целей для отслеживания прогресса zkVM - эти цели могут устранить раздутость и помочь сообществу сосредоточиться на реальном прогрессе.
Этап безопасности
ZkVM, основанный на SNARK, обычно включает в себя две основные компоненты:
· Интерактивное доказательство Oracle для полиномиальной интеракции (PIOP): используется для доказательства утверждений о полиноме (или выводимых из него ограничений) в интерактивной рамке доказательства.
· Схема обязательства полинома (PCS): гарантирует, что доказатель не может лгать при оценке полинома, не будучи обнаруженным.
zkVM в сущности преобразует эффективное выполнение в трассировку кода в системе ограничений - что в общем смысле означает, что они заставляют виртуальную машину правильно использовать регистры и память - и затем применяет SNARK для доказательства того, что эти ограничения выполняются.
Убедитесь, что единственным способом избежать ошибок в сложных системах, таких как zkVM, является формальная верификация. Вот разделение на этапы безопасности. Фаза 1 фокусируется на правильном протоколе, в то время как фазы 2 и 3 фокусируются на правильной реализации.
Этап безопасности 1: Правильный протокол
1、Формальное подтверждение надежности PIOP；
2、PCS в некоторых криптографических предположениях или идеальных моделях имеет силу ограничительного доказательства;
3、Если использовать Fiat-Shamir, то сочетая краткое доказательство, полученное с помощью PIOP и PCS, в случайной оракульской модели безопасно формально подтверждать доказательства (при необходимости с применением других криптографических предположений для усиления).
4、Система ограничений, используемая в PIOP, эквивалентна формальному доказательству семантики VM;
5、Сложите все эти части в одно целое, прошедшее формализованную проверку, безопасное доказательство SNARK, для выполнения любой программы, указанной в байт-коде ВМ. Если протокол планирует реализацию нулевого разглашения, это свойство также должно быть формализовано для обеспечения неразглашения чувствительной информации о свидетеле.
Предупреждение о рекурсии: Если zkVM использует рекурсию, то необходимо проверить каждый PIOP, коммитмент и систему ограничений, связанные с этой рекурсией, прежде чем можно считать эту фазу завершенной.
Этап безопасности 2: правильная реализация валидатора
Формальное доказательство соответствия фактической реализации верификатора zkVM (используя Rust, Solidity и т. д.) протоколу первой фазы проверки. Это обеспечивает разумность реализованного протокола (а не только дизайн на бумаге или неэффективную спецификацию, написанную на Lean и т. д.).
Вторая фаза сосредоточена исключительно на реализации валидатора (а не доказывателя) по двум причинам. Во-первых, правильное использование валидатора достаточно для обеспечения надежности (то есть гарантия того, что валидатор не может доверять никаким ложным утверждениям на самом деле является истинным). Во-вторых, реализация валидатора zkVM проще, чем реализация доказывателя на порядок.
Этап безопасности 3: правильная реализация доказателя
Реализация проверяющего zkVM действительно генерирует доказательства системы проверки фазы 1 и фазы 2, то есть формальная проверка. Это обеспечивает целостность, то есть ни одна система, использующая zkVM, не застревает на недоказуемых высказываниях. Если проверяющий намерен реализовать нулевое знание, то это свойство должно быть формально проверено.
План времени
**· Этап 1: **Мы можем ожидать постепенных достижений в следующем году (например, ZKLib). Но как минимум в течение двух лет zkVM не сможет полностью удовлетворить требования этапа 1;
· Этапы 2 и 3: Эти этапы могут одновременно продвигаться с некоторыми аспектами этапа 1. Например, некоторые команды уже доказали соответствие реализации валидатора Plonk с протоколом из статьи (хотя сам протокол из статьи может быть не полностью проверен). Тем не менее, я ожидаю, что ни один zkVM не достигнет 3-го этапа менее чем за четыре года - и, возможно, дольше.
Важные заметки: безопасность Fiat-Shamir и проверенный байт-код
Одним из основных сложных факторов является наличие нерешенных исследовательских проблем в области безопасности вокруг преобразования Фиата-Шамира. Все три этапа рассматривают Фиата-Шамира и случайного предсказателя как непоколебимую часть их безопасности, но, на самом деле, вся парадигма может иметь уязвимости. Это связано с излишне идеализированным случайным предсказателем и различиями между ним и фактически используемыми хэш-функциями. В худшем случае система, находящаяся на втором этапе из-за проблемы Фиата-Шамира, может позднее оказаться полностью небезопасной. Это вызывает серьезные опасения и продолжительные исследования. Возможно, нам потребуется изменить само преобразование для более эффективной защиты от таких уязвимостей.
Система без рекурсии в теории более устойчива, потому что некоторые известные атаки связаны с использованием схем, аналогичных схемам, используемым в рекурсивных доказательствах.
Еще одним важным моментом является то, что если сам байт-код содержит дефекты, то даже если компьютерная программа выполняется правильно (по указанию байт-кода), ее ценность ограничена. Таким образом, практическая ценность zkVM во многом зависит от методов создания формальной верификации байт-кода - это огромное вызов, выходящий за рамки обсуждения в данной статье.
О безопасности в постквантовую эпоху
По крайней мере, в течение ближайших пяти лет (а возможно, и дольше) квантовые компьютеры не представляют серьезной угрозы, в то время как уязвимости являются риском выживания. Поэтому основное внимание сейчас следует уделять обеспечению безопасности и производительности, о которых говорится в данной статье. Если мы можем использовать неквантово-безопасные SNARK для более быстрого удовлетворения этих требований к безопасности, то мы должны это сделать до тех пор, пока квантовые SNARK не догонят нас, или пока люди серьезно начнут беспокоиться о появлении квантовых компьютеров, связанных с шифрованием.
Текущее состояние производительности zkVM
В настоящее время коэффициент издержек, генерируемых доказывателем zkVM, близок к сто миллионам первоначальных затрат на выполнение. Если программе требуется X циклов для работы, то стоимость правильного выполнения составляет примерно X умножить на сто миллионов циклов ЦП. Это было так год назад, и так остается и по сей день.
Популярные повествования обычно описывают этот расход таким образом, чтобы звучало приемлемо. Например:
·«Стоимость создания подтверждения главной сети Ethereum не превышает один миллион долларов в год.»
·「Мы почти можем использовать кластер из десятков GPU для реального времени генерации доказательства блока Ethereum.」
«Наша последняя zkVM в 1000 раз быстрее, чем ее предшественник».
Хотя с технической точки зрения эти утверждения являются точными, но без соответствующего контекста они могут ввести в заблуждение. Например:
· По сравнению с предыдущей версией zkVM скорость увеличилась в 1000 раз, но абсолютная скорость все еще очень медленная. Это скорее указывает на то, насколько плохи дела, а не насколько хороши они.
· Кто-то уже предложил увеличить объем вычислений на главной сети 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 в угоду производительности будет противоречить смыслу zkVM.
Эти показатели сосредоточены на затратах для подтверждающих лиц. Однако, если разрешить неограниченные затраты на подтверждающие лица (т. е. нет ограничений на размер подтверждения или время проверки), то легко можно удовлетворить любые показатели подтверждающих лиц. Поэтому для системы, которая должна соответствовать этапу, необходимо определить максимальные значения для размера подтверждения и времени проверки.
требования к производительности
Этап 1 требует: «разумные и необычные затраты на проверку»:
· Размер подтверждения: размер подтверждения должен быть меньше размера свидетельства.
· Время проверки: скорость проверки утверждений не должна быть медленнее скорости выполнения локальной программы (т. е. выполнение вычислений без доказательства правильности).
Это минимальные требования к компактности. Они гарантируют, что размер доказательства и время проверки не будут хуже, чем отправка свидетельства проверяющему и непосредственная проверка его правильности проверяющим.
Требования с 2 этапа и далее:
· Максимальный размер подтверждения: 256 KB。
· Максимальное время проверки: 16 миллисекунд.
Эти пороговые значения специально увеличены, чтобы адаптироваться к новым технологиям быстрого доказательства, которые могут привести к повышенным затратам на проверку. В то же время они исключают очень дорогостоящие доказательства, из-за чего мало какие проекты готовы включить их в блокчейн.
Стадия скорости 1
Доказательство однопоточности должно быть медленнее, по меньшей мере, в сто тысяч раз, чем локальное выполнение, измеренное на ряде приложений (не только на блоках Ethereum), не зависящих от предварительной компиляции.
Конкретно, представьте себе процесс RISC-V, который работает на современном ноутбуке на частоте около 30 миллиардов циклов в секунду. Достижение 1-й фазы означает, что вы можете каждую секунду доказать примерно 30 000 циклов RISC-V (однопоточный) на том же ноутбуке. Но стоимость верификации должна быть, как уже упоминалось, "разумной и не тривиальной".
Стадия скорости 2
Доказательство однопоточности должно быть медленнее, чем локальное выполнение как минимум в десять тысяч раз.
Или, возможно, из-за того, что некоторые перспективные методы SNARK (особенно те, основанные на бинарных полях) в настоящее время затруднены процессором и видеокартой, вы можете достичь этой стадии, сравнивая использование FPGA (или даже ASIC):
FPGA может имитировать количество ядер RISC-V с местной скоростью;
Моделирование и демонстрация (почти) в реальном времени требуемого количества FPGA для выполнения RISC-V.
Если последнее не более чем в 10 000 раз больше, чем первое, вы имеете право перейти ко второму этапу. На стандартном процессоре размер доказательства должен быть не более 256 КБ, а время проверки - не более 16 мс.
Стадия скорости 3
Помимо достижения скорости уровня 2, можно использовать предварительную компиляцию с автоматическим синтезом и формальной верификацией для снижения затрат на доказательства на порядок менее 1000 (применимо к широкому спектру приложений). В сущности, можно настраивать наборы инструкций для ускорения доказательств для каждой программы, но это должно происходить способом, удобным для использования и формальной верификации.
Этап памяти 1
Скорость на этапе 1 достигается при условии, что для доказательства требуется менее 2 ГБ оперативной памяти (при этом также достигается нулевое знание).
Для многих мобильных устройств или браузеров это критически важно, поэтому открывается бесчисленное количество применений zkVM для клиентов. Важность клиентского подтверждения заключается в том, что наши мобильные телефоны являются нашей постоянной связью с реальным миром: они отслеживают наше местоположение, удостоверения и т. д. Если для генерации подтверждений требуется более 1-2 ГБ памяти, то для большинства современных мобильных устройств это слишком много. Необходимо уточнить два момента:
· 2 ГБ предела пространства применимы для крупных выражений (выражений, требующих выполнения десятков триллионов циклов ЦП на локальном уровне). Системы доказательства предела пространства для малых выражений имеют ограниченную применимость.
· Если проверяющий работает очень медленно, то легко держать потребление памяти проверяющего ниже 2 ГБ. Поэтому, чтобы сделать этап памяти 1 не настолько простым, я требую, чтобы этап 1 выполнялся в пределах 2 ГБ.
Этап 2 памяти
Скорость этапа 1 достигается при использовании менее 200 МБ оперативной памяти (в 10 раз лучше, чем этап 1 по памяти).
Зачем снижать объем до 2 ГБ? Рассмотрим пример не блокчейн-приложения: каждый раз при доступе к веб-сайту через HTTPS вы загружаете сертификаты для аутентификации и шифрования. Вместо этого сайт может отправлять zk-доказательства, имеющие эти сертификаты. Большие веб-сайты могут генерировать сотни тысяч таких доказательств в секунду. Если каждое доказательство требует 2 ГБ памяти для создания, то в общей сложности потребуется оперативная память уровня PB. Дальнейшее снижение использования памяти критически важно для не блокчейн-решений.
Предварительная компиляция: последняя миля или трость?
В конструкции zkVM предварительная компиляция означает специализированные SNARK (или системы ограничений), настроенные на конкретные функции, такие как хеш-функции Keccak/SHA для цифровой подписи или операции над группами эллиптических кривых. В Ethereum (где большая часть тяжелой работы связана с Merkle-хешами и проверкой подписей), некоторые ручные предварительные компиляции могут сократить расходы на верификатор. Однако полагаться на них как на костыль не позволит SNARK достичь свой цели. Причины следующие:
· Для большинства приложений (внутри и снаружи блокчейна) все еще слишком медленно: даже с использованием предварительной компиляции хэшей и подписей, текущая zkVM все еще слишком медленна (как внутри, так и вне блокчейна), потому что основная система доказательств неэффективна.
· Проблемы безопасности: Неофициальная ручная предварительная компиляция практически наверняка содержит ошибки, что может привести к катастрофическим сбоям безопасности.
· Опыт разработчика неудовлетворителен: В большинстве существующих zkVM добавление новых прекомпиляций означает ручное написание систем ограничений для каждой функции — это суть возвращения к рабочему процессу стиля 1960-х годов. Даже при использовании существующих прекомпиляций разработчики должны переписывать код для вызова каждой прекомпиляции. Мы должны оптимизировать безопасность и опыт разработчика, а не жертвовать ими в погоне за приростом производительности. Такой подход лишь доказывает, что производительность не соответствует ожидаемому уровню.
· I/O расходы и отсутствие ОЗУ: Хотя предварительная компиляция может повысить производительность тяжелых задач по шифрованию, она может быть неспособной обеспечить смысловое ускорение для более разнообразных рабочих нагрузок из-за больших расходов на ввод/вывод при их передаче и невозможности использования ОЗУ. Даже в среде блокчейна, при преодолении ограничений одноплатформенных L1, таких как Ethereum (например, если вы хотите построить серию межцепных мостов), вам придется столкнуться с другими хэш-функциями и схемами подписи. Многократное использование предварительной компиляции для решения проблем неспособно масштабироваться и несет значительные риски безопасности.
По всем этим причинам наш главный приоритет - повысить эффективность базовой zkVM. Лучшая технология zkVM приведет к лучшим предварительным компиляциям. Я действительно верю, что предварительные компиляции останутся важными в долгосрочной перспективе, но только если они будут автоматически синтезированы и официально проверены. Таким образом, можно сохранить преимущества разработчиков zkVM и избежать катастрофических безопасностей. Это отражено в этапе 3 скорости.
План времени
Я ожидаю, что некоторые zkVM будут реализованы позднее в этом году, включая этап 1 скорости и этап 1 памяти. Я думаю, что мы также достигнем этапа 2 скорости в течение следующих двух лет, но пока неясно, сможем ли мы достичь этой цели без новых идей, которые еще не появились. Я предполагаю, что для завершения оставшихся этапов (этап 3 скорости и этап 2 памяти) потребуется несколько лет.
Обзор
Хотя я разделил этапы безопасности и производительности zkVM в этой статье, эти аспекты zkVM не являются полностью независимыми. По мере обнаружения большего количества уязвимостей в zkVM ожидается, что некоторые из них можно будет исправить только при значительном снижении производительности. До достижения zkVM уровня безопасности 2 производительность должна быть отложена.
zkVM имеет потенциал сделать доказательства с нулевым разглашением действительно широко распространенными, но они все еще находятся на начальном этапе, полном вызовов безопасности и огромных затрат на производительность. Рекламная деятельность и маркетинг делают оценку реальных успехов затруднительной. Путем уточнения конкретных безопасных и производительностных вех мы надеемся предоставить карту пути, свободную от помех. Мы достигнем поставленных целей, но это потребует времени и упорного труда.
Ссылка на оригинал
：