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

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

Для приватных транзакций обычно сравнивают три семейства: zk-SNARKs, zk-STARKs и Bulletproofs. Универсального победителя у них нет. Groth16 компактен и удобен для передачи, STARK обходится без доверенной настройки и опирается на хеш-функции, Bulletproofs подходят для доказательств диапазона, но их верификация растёт с размером задачи. Выбор зависит от архитектуры протокола, а не от аббревиатуры в презентации.

Анатомия доверия: что означает Trusted Setup

ZK-доказательство должно удовлетворять трём свойствам. Полнота означает, что корректное утверждение можно доказать. Надёжность означает, что ложное утверждение нельзя убедительно выдать за истинное, кроме как с пренебрежимо малой вероятностью. Нулевое разглашение означает, что проверяющий не получает секрет, лежащий за доказательством.

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

Различие между SNARK и STARK начинается с того, как система получает параметры для генерации и проверки доказательств. Groth16, одна из схем zk-SNARK, требует доверенной настройки. В ходе этой процедуры создают общедоступные параметры, используемые схемой. Для неё применяются секретные случайные данные, которые часто называют toxic waste. Если секретная часть окажется скомпрометирована или не будет уничтожена, появляется возможность подделывать доказательства.

Это существенная модель угроз, но сам факт trusted setup не делает протокол автоматически ненадёжным. MPC-церемония распределяет процедуру между участниками: безопасность сохраняется, если хотя бы один из них честно сгенерировал свою долю секрета и уничтожил её. Вопрос для аудитора здесь конкретный: как проходила церемония, кто участвовал, какие артефакты сохранились и можно ли независимо проверить её ход. Ответ «настройка была» недостаточен.

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

Доверенная настройка — отдельный риск в модели безопасности. Её наличие требует аудита церемонии; её отсутствие не отменяет аудит кода и параметров.

zk-SNARK против zk-STARK: компактность против прозрачности

Для приватного платежа размер доказательства влияет на объём данных, которые нужно передать или сохранить. У Groth16 типичный размер доказательства составляет около 128–288 байт, а проверка имеет константную сложность относительно размера вычисления. Это делает схему привлекательной там, где критичны компактность транзакции и стоимость верификации.

У STARK доказательства существенно крупнее: обычно речь идёт о десятках или сотнях килобайт, то есть примерно в 10–100 раз больше, чем у компактных SNARK в сопоставляемых сценариях. За это система получает прозрачную настройку и другую криптографическую основу. Оверхед проявляется в передаче доказательства и требованиях к пропускной способности. Для блокчейна с ограниченным пространством блока это не абстрактный минус: больше данных означает больше нагрузки на сеть и хранение.

Сравнивать следует конкретные реализации и одинаковые задачи. Размер доказательства зависит от схемы, параметров и вычисления, которое доказывается. Фраза «STARK в сто раз больше» без указания сценария превращает ориентир в рекламный слоган. Аналогично, константная верификация Groth16 не означает, что вся операция в системе бесплатна: остаются генерация доказательства, исполнение контракта, передача данных и стоимость криптографических операций в конкретной виртуальной машине.

У классических SNARK на спариваниях эллиптических кривых нет постквантовой устойчивости. Поэтому сравнение zk-SNARK vs zk-STARK не сводится к размеру транзакции. Если долгосрочная устойчивость к квантовым компьютерам входит в требования, типичная схема Groth16 получает принципиальное ограничение. Если же системе важны компактные доказательства и проверка с малым оверхедом, STARK могут оказаться неоправданно тяжёлыми.

Что именно означает масштабируемость

Слово «масштабируемость» часто используют без метрики. Для ZKP следует разделять как минимум три величины: стоимость генерации доказательства, стоимость его проверки и объём доказательных данных. Протокол может сокращать нагрузку на проверяющий узел, но увеличивать размер транзакции. Или давать компактное доказательство, но требовать сложной настройки параметров.

Для пользователя приватного кошелька также важна генерация доказательства на его устройстве. Достоверных универсальных значений CPU и RAM для мобильных реализаций всех вариантов PLONK и STARK нет: результат зависит от схемы, реализации и оборудования. Поэтому обещание «доказательство строится мгновенно на телефоне» без бенчмарка для конкретной схемы — не технический аргумент.

Bulletproofs: диапазон суммы и цена проверки

Конфиденциальной транзакции недостаточно скрыть сумму. Система должна проверить, что значение допустимо: например, что оно не отрицательное и не превышает диапазон, который поддерживает схема. Range proof доказывает такое ограничение, не раскрывая само значение.

Bulletproofs применяются для доказательств диапазона и не требуют trusted setup. Этот профиль сделал их уместными в конфиденциальных транзакциях, в частности в механизме Monero RingCT для сокрытия сумм переводов. Ключевая цена — рост времени верификации по мере увеличения задачи. Это нужно учитывать, когда проверка ложится на множество узлов или выполняется для большого числа доказательств.

В некоторых сценариях для Bulletproofs приводят размер около 672 байт против 192 байт у Groth16. Это пример сравнения, а не постоянная характеристика семейств. Размер меняется вместе с параметрами и тем, что именно доказывается. При подборе решения эти числа полезны лишь рядом с описанием сценария, формата транзакции и затрат на проверку.

Практический выбор для платежей выглядит так:

• Если основной предел — место в блоке и стоимость верификации, компактный SNARK может быть предпочтителен. Вместе с ним придётся принять и документировать модель trusted setup.
• Если приоритетом служит прозрачная настройка и криптографическая основа, опирающаяся на хеш-функции, STARK дают соответствующие свойства. Цена — более объёмные доказательства и дополнительная нагрузка на передачу данных.
• Если задача сосредоточена на доказательствах диапазона, Bulletproofs предлагают вариант без доверенной настройки. Линейный рост времени верификации следует сверить с ожидаемым числом транзакций и архитектурой проверки.

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

От Groth16 к PLONK: что даёт универсальная настройка

Groth16 компактен, но trusted setup традиционно привязан к конкретной схеме. При смене схемы может потребоваться новая церемония. Для проекта с быстро меняющимися контрактами это операционная нагрузка: каждое обновление цепочки доказательства повышает требования к управлению параметрами и проверяемости процесса.

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

В инженерном сравнении PLONK и Groth16 нельзя переносить характеристики одной схемы на всё семейство SNARK. Размер доказательства, стоимость генерации и проверки зависят от конкретной реализации и схемы. Факт наличия универсальной настройки не говорит сам по себе, насколько эффективно доказательство для заданной транзакции. Нужны бенчмарки на реальном вычислении, а не таблица из презентации.

Перед внедрением стоит зафиксировать метрики, которые относятся к продукту:

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

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

Как выбрать протокол для приватных транзакций

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

Для систем, где критичны малый объём транзакции и низкая стоимость верификации, Groth16 остаётся сильным кандидатом. Его ограничения прозрачны: доверенная настройка и зависимость классической схемы от криптографии на эллиптических кривых. PLONK меняет организацию настройки, предлагая универсальный вариант, но не превращает SNARK в протокол без доверительных предпосылок.

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

Bulletproofs уместны, когда основная задача — range proof, а отсутствие trusted setup важнее компактности и масштабируемости проверки. Для массовой верификации линейный рост затрат требует отдельного расчёта. Переносить их на любую задачу приватности только потому, что они применялись в конфиденциальных транзакциях, оснований нет.

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

Для реализации ZKP в блокчейн-проекте итоговый вердикт должен опираться на воспроизводимый бенчмарк: конкретная схема, конкретные параметры, целевое оборудование и стоимость проверки в целевой среде. В качестве начальной развилки можно принять компактность и верификацию у SNARK, прозрачность настройки у STARK, доказательства диапазона без trusted setup у Bulletproofs. Дальше решают детали реализации.

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