a16z: Поэтапный подход к безопасной и эффективной реализации zkVM (обязательно к прочтению разработчикам)

Оригинальное название: Путь к безопасным и эффективным zkVM: как отслеживать прогресс

Автор оригинала: a16z crypto

Перевод: Golem, 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, соответствует семантике виртуальной машины;

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

Важно при рекурсии: если 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. Это вызывает серьезную обеспокоенность и требует дальнейших исследований. Возможно, нам придется изменить само преобразование, чтобы лучше снизить такие риски.

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

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

О постквантовой безопасности

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

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

Сейчас накладные расходы прувера zkVM почти в 1,000,000 раз превышают стоимость нативного исполнения. Если программа выполняется за X циклов, доказательство корректности ее исполнения обходится примерно в X, умноженное на 1,000,000 циклов CPU. Так было год назад, и ситуация не изменилась.

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

· «Генерация доказательств для всех транзакций основной сети Эфириума за год стоит меньше миллиона долларов».

· «Мы почти можем генерировать доказательства блоков Эфириума в реальном времени с помощью кластера из нескольких десятков GPU».

· «Наша новейшая zkVM в 1,000 раз быстрее предыдущей версии».

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

· Новая версия в 1,000 раз быстрее старой zkVM, но абсолютная скорость все еще очень низкая. Это скорее говорит о том, насколько плохой была прежняя ситуация, а не о том, насколько хороша нынешняя.

· Предлагалось увеличить вычислительную нагрузку на основную сеть Эфириума в 10 раз. Это еще сильнее замедлило бы работу нынешней zkVM.

· То, что называют «почти генерацией доказательств блоков Эфириума в реальном времени», все еще намного медленнее, чем требуется многим блокчейн-приложениям (например, время блока в Optmism составляет 2 секунды — значительно меньше, чем 12 секунд в Эфириуме).

· «Кластер из нескольких десятков GPU, который постоянно работает безупречно», не может обеспечить приемлемую гарантию доступности.

· Расходы менее миллиона долларов в год на доказательство всей активности основной сети Эфириума объясняются тем, что полному узлу Эфириума требуется потратить всего около 25 $ в год на вычисления.

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

Измерение производительности

У производительности SNARK есть три основных составляющих:

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

· Оптимизация под конкретное приложение (например, предварительная компиляция).

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

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

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

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

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

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

Эти показатели относятся к затратам прувера. Однако при отсутствии ограничений на затраты валидатора (то есть на размер доказательства и время проверки) можно легко добиться любого показателя для прувера. Поэтому для соответствия описанным этапам необходимо установить максимальные значения размера доказательства и времени проверки.

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

Требование этапа 1: «Разумные и ненулевые затраты на проверку»:

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

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

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

Требования для этапа 2 и последующих этапов:

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

· Максимальное время проверки: 16 миллисекунд.

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

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

Доказательство в одном потоке должно быть медленнее нативного исполнения в не более 100 000 раз. Показатель следует измерять на различных приложениях (а не только при доказательстве блоков Эфириума) и без использования прекомпиляций.

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

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

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

В качестве альтернативы можно сравнивать производительность с FPGA (или даже ASIC), поскольку некоторые перспективные методы SNARK, особенно основанные на двоичных полях, ограничены возможностями современных CPU и GPU:

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

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

Если второй показатель превышает первый в не более 10 000 раз, система соответствует этапу 2. На стандартном CPU размер доказательства должен составлять не более 256 KB, а время работы валидатора — не более 16 миллисекунд.

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

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

Этап 1 по объему памяти

Этап 1 по скорости достигается, если для работы прувера требуется менее 2 GB памяти (при этом также обеспечивается нулевое разглашение).

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

· Ограничение в 2 GB относится к объемным утверждениям (для локального выполнения которых требуется триллионы циклов CPU). Системы доказательств, ограничивающие потребление памяти только для небольших утверждений, имеют ограниченную сферу применения.

· Если прувер работает очень медленно, легко удержать его потребление памяти ниже 2 GB. Поэтому, чтобы этап 1 по объему памяти был содержательным, необходимо достичь этапа 1 по скорости в пределах этого лимита памяти в 2 GB.

Этап 2 по объему памяти

Этап 1 по скорости достигается при потреблении менее 200 MB памяти (в 10 раз лучше, чем на этапе 1 по объему памяти).

Зачем снижать показатель ниже 2 GB? Рассмотрим пример за пределами блокчейна: каждый раз, когда вы посещаете сайт по HTTPS, вы скачиваете сертификат для идентификации и шифрования. Вместо этого сайт мог бы отправлять вместе с сертификатами доказательства zk. Крупный сайт может генерировать миллионы таких доказательств в секунду. Если для создания каждого из них требуется 2 GB памяти, суммарно понадобится RAM объемом в несколько PB. Поэтому дальнейшее сокращение потребления памяти критически важно для использования технологии вне блокчейна.

Прекомпиляции: последний шаг или костыль?

В архитектуре zkVM прекомпиляции — это специализированные SNARK (или системы ограничений), адаптированные для конкретных функций, например хеширования Keccak/SHA для цифровых подписей или операций с группами эллиптических кривых. В Эфириуме, где большая часть сложных вычислений связана с хешированием в деревьях Меркла и проверкой подписей, некоторые написанные вручную прекомпиляции могут снизить нагрузку на валидатор. Однако использование их в качестве костыля мешает SNARK достичь своей цели. Вот почему:

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

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

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

· Накладные расходы на ввод-вывод и нехватка RAM: Прекомпиляции могут ускорять ресурсоемкие криптографические задачи, но для более разнообразных нагрузок они могут не дать существенного ускорения: обработка ввода-вывода требует значительных ресурсов, а RAM использовать нельзя. Даже в блокчейне, как только вы выходите за пределы одной сети L1, например Эфириума (скажем, хотите построить сеть кроссчейн-мостов), приходится иметь дело с разными хеш-функциями и схемами подписей. Постоянное создание новых прекомпиляций для одной и той же задачи не масштабируется и несет серьезные риски для безопасности.

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

Ожидаемые сроки

Я ожидаю, что несколько zkVM достигнут этапа 1 по скорости и этапа 1 по объему памяти позднее в этом году. Также предполагаю, что этап 2 по скорости будет достигнут в течение следующих двух лет, хотя пока неясно, удастся ли нам добиться этой цели без новых идей, которые еще только предстоит найти. По моим прогнозам, на оставшиеся этапы — этап 3 по скорости и этап 2 по объему памяти — потребуется еще несколько лет.

Заключение

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

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

Ссылка на оригинальную статью