Шифрование данных: тест zk-SNARKs, zk-STARKs и Bulletproofs

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

На практике это различие критично. AES защищает содержимое файла. Мультиподпись подтверждает право группы подписантов на действие. А zero-knowledge proof подтверждает, что вычисление выполнено корректно, хотя сам вход вычисления может оставаться скрытым. Смешивать эти классы криптографии в одну категорию — архитектурная ошибка, которая потом дорого проявляется в протоколе.

В сравнении zk-SNARKs, zk-STARKs и Bulletproofs нет универсального победителя. Groth16 выигрывает по размеру доказательства и времени проверки. STARKs снимают trusted setup и используют постквантово-стойкую криптографическую основу, но платят за это десятками килобайт. Bulletproofs удобны для confidential transactions и диапазонных доказательств, однако плохо масштабируются по времени проверки.

ZK-протокол выбирают не по названию, а по узкому месту системы: размер calldata, стоимость proving, latency verifier или модель доверия.

Сначала исправим терминологию: это не алгоритмы шифрования

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

Zero-knowledge-протокол устроен иначе. У него есть:

• публичное утверждение или statement;
• приватные входы, называемые witness;
• prover, который строит доказательство;
• verifier, который проверяет доказательство;
• криптографическая схема, связывающая корректность statement и witness.

Упрощённо prover доказывает: существует секретный набор данных, при котором заданное вычисление имеет корректный результат. Verifier получает только доказательство и публичные параметры. Сам witness ему не передаётся.

Например, в конфиденциальной транзакции можно скрыть сумму перевода, но доказать, что:

• входные значения принадлежат допустимому диапазону;
• сумма входов равна сумме выходов с учётом комиссии;
• один и тот же commitment не был потрачен повторно;
• отправитель обладает необходимым секретом;
• состояние контракта изменено по правилам протокола.

Это не шифрование баланса. Баланс не обязательно можно расшифровать из proof. Система доказывает свойства скрытого состояния, а не передаёт его в зашифрованном виде.

Поэтому выражение «сравнение протоколов шифрования» в этой теме допустимо только как поисковая формулировка. Технически корректнее говорить о сравнении криптографических протоколов доказательств с нулевым разглашением.

Есть и второй нюанс. Zero-knowledge не означает автоматически полную приватность. Протокол может скрывать witness, но раскрывать метаданные: время операции, размер proof, адрес verifier-контракта, частоту транзакций, структуру вызовов или корреляцию между несколькими действиями. Приватность — это свойство всей архитектуры, а не магический флаг в названии схемы.

Архитектура: эллиптические кривые против хэшей и FRI

Главное различие между рассматриваемыми системами проходит по криптографической основе.

Groth16, наиболее известная архитектура zk-SNARKs, опирается на pairing-friendly elliptic curves и полиномиальные обязательства. Такие схемы дают крайне компактные proof и быстрый verifier. Цена — сложная процедура trusted setup. Для конкретной схемы вычисления формируется набор публичных параметров, и безопасность зависит от того, что секретный toxic waste действительно уничтожен.

Если секрет trusted setup будет сохранён или скомпрометирован, злоумышленник потенциально сможет создавать ложные доказательства. Это не обычная утечка ключа пользователя. Уязвимость системная: она затрагивает саму soundness-модель протокола. В некоторых архитектурах проблему смягчают многосторонней церемонией, где достаточно, чтобы хотя бы один участник корректно уничтожил свою часть секрета. Но это всё равно дополнительный процесс доверия, логирования и аудита.

zk-STARKs идут по другой ветке. Вместо эллиптических кривых они используют хэш-функции, полиномиальные проверки и протокол FRI. Trusted setup не требуется. Система строит доказательство того, что полином имеет нужную структуру и согласуется с вычислением, после чего verifier проверяет это через последовательность хэш-коммитментов и запросов.

Важный результат — постквантовая устойчивость в принятой модели. STARKs не используют те же pairing-based конструкции, которые потенциально уязвимы для алгоритма Шора на достаточно мощном квантовом компьютере. Это не означает абсолютную защиту от любой квантовой атаки: остаются требования к хэш-функциям, длине дайджеста и параметрам безопасности. Но криптографическая база у STARKs существенно лучше согласуется с post-quantum threat model.

Bulletproofs также обходятся без trusted setup. Их основа — inner-product arguments и криптография на эллиптических кривых. Это делает протокол удобным для диапазонных доказательств: например, можно доказать, что скрытая сумма неотрицательна и не выходит за пределы допустимого диапазона, не раскрывая саму сумму.

Но отсутствие trusted setup не превращает Bulletproofs в постквантовую схему. Эллиптические кривые остаются частью модели безопасности. В случае появления практического квантового компьютера с нужными характеристиками это будет принципиальным ограничением.

Таблица не заменяет спецификацию конкретной реализации. Halo2, Plonky2, Plonky3, рекурсивные схемы и гибридные конструкции могут демонстрировать совершенно другие показатели. Сравнивать только названия протоколов — всё равно что оценивать базы данных исключительно по слову SQL.

zk-SNARKs: минимальный proof, максимальная дисциплина setup

Главное преимущество zk-SNARKs — компактность. В конфигурациях на базе Groth16 доказательство занимает около 288 байт; в отдельных реализациях встречается размер до 384 байт. Для блокчейна это не косметика. Каждый байт calldata влияет на стоимость публикации, нагрузку на RPC, размер блока и пропускную способность verifier-контракта.

Проверка proof занимает порядка 10 мс в рассматриваемой конфигурации. Это позволяет выносить тяжёлое вычисление за пределы блокчейна, а в сеть отправлять только короткое доказательство и публичные входы. Verifier выполняет небольшое количество операций над эллиптическими кривыми и pairing. Для EVM подобная модель особенно привлекательна: on-chain проверка становится предсказуемой, а размер транзакции остаётся небольшим.

Но компактность имеет источник. Groth16 строится под конкретную arithmetic circuit. Если логика вычисления меняется, часто требуется новый setup и новый набор proving/verifying keys. В протоколе с частыми обновлениями это уже не инженерная мелочь, а операционный риск.

Где находится уязвимость trusted setup

Trusted setup — не обязательно слабость в практическом смысле. Это дополнительная поверхность атаки и дополнительная предпосылка безопасности. Она требует:

1. Формально определить circuit, для которой строятся параметры.

2. Провести многостороннюю церемонию генерации.

3. Зафиксировать участников, артефакты и процедуру удаления промежуточных секретов.

4. Проверить, что proving key и verifying key соответствуют одной версии схемы.

5. Исключить возможность подмены параметров на этапе сборки или деплоя.

Если хотя бы один этап организован плохо, аудит исходного кода не спасает систему. Контракт может быть безупречным, а cryptographic ceremony — скомпрометированной.

Нужно также различать proving key и verifying key. Первый может быть огромным и требовать значительной памяти, потому что prover обязан работать со структурой circuit. Второй компактнее и используется verifier. В блокчейн попадает именно логика проверки, но инфраструктурная стоимость генерации proof остаётся вне цепочки. В некоторых системах именно prover становится узким местом: GPU, RAM, latency и очередь задач оказываются важнее размера proof.

Ассимптотика тоже не даёт полного ответа. Для SNARKs и Bulletproofs в фактуре рассматриваемого сравнения приводится сложность порядка O(N * log(N)), но константы, структура circuit и реализация кривой определяют фактический benchmark. Один протокол может иметь более красивую асимптотику и проиграть на небольших схемах из-за дорогих операций над полем.

У Groth16 нет бесплатной компактности. За 288 байт proof система платит setup-процедурой, жёсткой привязкой к circuit и зависимостью от elliptic-curve security.

zk-STARKs: отказ от trusted setup за счёт размера

STARKs устраняют наиболее спорный компонент SNARK-архитектуры — trusted setup. Prover коммитит вычисление через хэши, а затем доказывает корректность полиномиального представления. FRI используется для проверки низкой степени полинома без необходимости раскрывать всю вычислительную трассу.

Это хорошо масштабируется для больших вычислений. Если circuit или execution trace содержит большое количество шагов, STARK не требует pairing-операций и setup под каждую конкретную схему в той же форме, что Groth16. В бенчмарке с использованием MiMC zk-STARK показал наименьшее время полного цикла среди сравниваемых вариантов, хотя конкретные показатели зависят от реализации и железа.

Проблема очевидна уже по размеру. Proof обычно занимает порядка 100 КБ, а в оптимизированных системах может быть уменьшен примерно до 68 КБ. На фоне 288 байт Groth16 это не разница в процентах, а смена класса накладных расходов.

Большой proof означает:

• больше calldata или blob-данных;
• более высокую стоимость публикации;
• больший объём сетевой передачи;
• дополнительную нагрузку на архивирование и индексаторы;
• менее удобную on-chain верификацию в средах, где каждый байт дорог.

При этом нельзя делать примитивный вывод, будто STARK всегда медленнее. Проверка proof и генерация proof — разные операции. В одном benchmark STARK может выиграть по общему циклу или proving time, а SNARK — по latency verifier. Для rollup-архитектуры это принципиальное разделение: оператору важна стоимость и скорость генерации, а базовой сети — размер данных и стоимость проверки.

Что означает post-quantum secure

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

Но фраза «защищён от квантовых компьютеров» слишком груба. Квантовые алгоритмы могут ускорять перебор и влиять на эффективную длину хэша. Поэтому post-quantum security требует правильных параметров, достаточной длины дайджеста и анализа конкретной схемы. В любом случае STARKs находятся в более выгодной позиции, чем Groth16 и Bulletproofs, если threat model включает достаточно мощного квантового противника.

Есть и инженерная цена. Хэширование больших объёмов данных требует CPU-времени и памяти. Proof получается заметно крупнее. Если система работает в L2, необходимо считать не только криптографию, но и стоимость data availability. На практике дешевый verifier не компенсирует огромный объём публикуемых данных, если протокол не использует подходящий слой хранения или специальную модель компрессии.

Bulletproofs: практичный инструмент для confidential transactions

Bulletproofs занимают отдельную нишу. Их сильная сторона — отсутствие trusted setup и удобная работа с range proofs. Протокол позволяет доказать, что скрытое значение находится в заданном диапазоне, не раскрывая его.

Для confidential transactions это естественный сценарий. Сумма перевода скрыта commitment-ом, но сеть должна убедиться, что пользователь не создал отрицательное значение или не выпустил больше активов, чем разрешено протоколом. Range proof закрывает эту дыру без публикации самой суммы.

Bulletproofs особенно полезны там, где нужно доказать набор локальных свойств конфиденциального состояния:

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

Однако Bulletproofs не являются универсальной заменой SNARKs или STARKs. В доступном сравнительном benchmark именно они показали наименьшую скорость генерации и проверки. Кроме того, время проверки масштабируется линейно с ростом объёма вычислений. Для небольших confidential transactions это приемлемый компромисс. Для высоконагруженного L2 с большим количеством сложных вычислений — уже нет.

Размер proof у Bulletproofs зависит от количества переменных и структуры доказательства. Он не обладает фиксированной константой в том же смысле, в каком Groth16 даёт proof около нескольких сотен байт для конкретной схемы. Поэтому оценивать Bulletproofs одной цифрой некорректно. Нужно указывать число commitments, размер диапазона, количество constraints и способ агрегации доказательств.

Почему Bulletproofs не конкурируют со STARKs на всём поле

У Bulletproofs есть два системных ограничения.

Первое — эллиптические кривые. Trusted setup не нужен, но post-quantum security отсутствует. Это другой компромисс, а не устранение криптографических рисков.

Второе — масштабирование verifier. При росте вычислительной задачи увеличивается и объём работы по проверке. В confidential transaction, где доказывается диапазон суммы, это нормально. В rollup, где нужно подтвердить длинную трассу исполнения виртуальной машины, архитектура быстро становится неэффективной.

С другой стороны, Bulletproofs проще вписываются в некоторые приватные платёжные системы. Если протоколу не нужен сложный универсальный zk-VM, а требуется несколько доказательств диапазона и согласованности commitments, применение тяжёлого STARK-стека может быть неоправданным overengineering.

Бенчмарк: размер proof не равен производительности

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

Нужно разделять как минимум четыре метрики:

1. Proving time. Сколько времени prover строит proof. Это определяет задержку финализации и требования к серверной инфраструктуре.

2. Verification time. Сколько времени verifier проверяет proof. Для on-chain систем метрика связана с gas и пропускной способностью.

3. Proof size. Сколько байт нужно передать и опубликовать. В блокчейнах это влияет на calldata и data availability.

4. Setup overhead. Есть ли trusted setup, как часто он запускается и насколько трудно доказать корректность процедуры.

В benchmark на базе MiMC zk-SNARK показал минимальный размер доказательства. Это ожидаемый результат для схемы Groth16. zk-STARK оказался наиболее быстрым в общем цикле, а Bulletproofs продемонстрировали наименьшую скорость генерации и проверки.

Но из этого нельзя вывести универсальное правило. Benchmark протокола — это не benchmark продукта. Результат меняется из-за:

• размера circuit;
• количества constraints;
• типа конечного поля;
• реализации polynomial commitment;
• CPU и GPU;
• объёма оперативной памяти;
• степени параллелизма;
• версии библиотеки;
• наличия рекурсии;
• способа агрегации proof;
• стоимости публикации данных в конкретной сети.

Например, STARK может выиграть на большой вычислительной трассе, но проиграть по размеру proof. Groth16 может дать почти идеальный latency verifier, но потребовать тяжёлой подготовки параметров. Bulletproofs могут быть разумны для range proof и неприемлемы для универсальной виртуальной машины.

Практическая матрица выбора

Это не таблица рейтинга. Это карта компромиссов. В нормальном техническом задании сначала фиксируют threat model, модель публикации данных и допустимый latency, а затем подбирают протокол. Делать наоборот — выбирать любимую схему и подгонять под неё архитектуру — плохая практика.

Что проверять в реализации, а не в презентации

Аудит zk-системы не заканчивается проверкой математической статьи. Большинство реальных уязвимостей возникает на стыке схемы, сериализации, circuit и smart contract verifier.

1. Корректность circuit

Нужно проверить, что circuit действительно доказывает требуемое свойство. Частая ошибка — доказательство более слабого утверждения, чем предполагает бизнес-логика.

Если контракт должен проверять баланс активов, circuit обязан связывать все commitments и публичные значения. Если часть входов не включена в constraint system, prover может построить валидный proof для некорректного состояния. Формально proof будет sound относительно circuit. Проблема в том, что circuit проверяет не то.

2. Обработку public inputs

Порядок публичных входов должен быть одинаковым в prover, verifier и smart contract. Ошибка индекса, неверное поле или различие в endian-представлении ломают связь между off-chain вычислением и on-chain проверкой.

Для криптографии это особенно неприятный класс дефектов. Код компилируется. Тест на одном наборе данных проходит. Но при другом порядке аргументов или граничном значении система начинает принимать не те доказательства.

3. Field arithmetic и переполнения

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

Значение, которое в прикладном коде считается отрицательным или переполненным, внутри поля может выглядеть допустимым. Поэтому range constraints — не дополнительная оптимизация, а часть модели безопасности.

4. Проверку trusted setup

Для Groth16 нужно проверять не только наличие ceremony, но и соответствие параметров конкретной версии circuit. Изменение одного constraint делает старый proving key непригодным. Если инфраструктура допускает подмену артефактов, компрометация CI/CD становится криптографической уязвимостью.

5. Randomness и nonce

Некоторые схемы используют случайность при построении proof. Плохой генератор случайных чисел способен раскрыть witness или нарушить binding-свойства. Аппаратные кошельки и изолированные prover-системы здесь отличаются от обычных backend-сервисов: источник энтропии должен быть частью аудируемой архитектуры.

6. Рекурсивную агрегацию

Рекурсивные proof уменьшают объём публикации, но добавляют новые circuit, дополнительные ограничения и сложность отладки. Ошибка в recursive verifier может сделать бесполезным аудит базовой схемы. Система становится безопасной только настолько, насколько безопасен самый внешний proof path.

7. Gas и data availability

Маленький proof не гарантирует дешёвую транзакцию. Нужно учитывать публичные входы, calldata, стоимость pairing или hash-проверок, хранение состояния и публикацию данных для восстановления L2. Сравнение только verifier gas без оценки data availability даёт неполную картину.

zk-SNARKs против zk-STARKs: где проходит реальная граница

Формула «SNARK — маленький, STARK — безопасный» слишком примитивна. Оба протокола могут быть безопасными при своих предпосылках. Вопрос в том, какие предпосылки приемлемы для конкретного продукта.

SNARK предпочтителен, когда:

• каждый байт proof имеет высокую стоимость;
• verifier должен работать в EVM с минимальным gas;
• circuit стабилен;
• trusted setup можно провести прозрачно;
• постквантовая угроза не является ближайшим ограничением;
• prover-инфраструктура готова к circuit-specific ключам.

STARK предпочтителен, когда:

• вычисления большие и регулярные;
• требуется отсутствие trusted setup;
• архитектура должна опираться на hash-based assumptions;
• стоимость proof и публикации данных приемлема;
• важна долгосрочная post-quantum ориентация;
• система использует инфраструктуру, где размер proof можно эффективно компенсировать.

Bulletproofs выбирают не как «третий универсальный вариант», а для более узкого профиля:

• конфиденциальные платежи;
• range proofs;
• commitments;
• отсутствие возможности или желания проводить trusted setup;
• относительно ограниченный объём вычислений.

Bulletproofs — не младшая версия STARKs. Это другой инструмент для другой геометрии задачи.

Итоговый технический вердикт

Если критерием является минимальный размер доказательства и быстрый verifier, zk-SNARKs на базе Groth16 остаются самым эффективным вариантом из рассматриваемых. Около 288–384 байт proof и время проверки порядка 10 мс дают очевидное преимущество для on-chain verification. Но trusted setup и зависимость от эллиптических кривых нельзя прятать в сноске.

zk-STARKs рациональнее там, где размер proof не становится блокирующим фактором. Они устраняют trusted setup, используют хэш-ориентированную архитектуру и обеспечивают постквантовую стойкость в принятой модели. Цена — proof порядка десятков или сотен килобайт и соответствующий data overhead.

Bulletproofs сохраняют смысл в confidential transactions и range proofs. Их ценность не в максимальной скорости, а в отсутствии trusted setup и естественном соответствии задачам со скрытыми commitments. Для крупных вычислительных систем их линейное масштабирование проверки становится уязвимостью архитектуры.

И последнее. Называть все три решения «шифрованием данных» удобно для поискового запроса, но технически неверно. Это протоколы доказательств с нулевым разглашением, которые могут работать вместе с шифрованием, но не заменяют его. Выбор между ними определяется не маркетинговым списком преимуществ, а размером circuit, моделью угроз, стоимостью публикации, требованиями к latency и тем, готовы ли разработчики принять trusted setup.

Жёсткий вердикт простой: Groth16 — для компактности, STARKs — для независимости от setup и post-quantum профиля, Bulletproofs — для ограниченных confidential transactions. Всё остальное требует benchmark на собственной circuit. Без него сравнение остаётся презентацией, а не инженерным решением.