Разбираем разницу между агрегацией и рекурсивной проверкой ZK-доказательств, их роль в rollup и компромиссы по стоимости, размеру и доверию.
Почему проверка доказательств становится узким местом
ZK-системы позволяют доказывающей стороне подтвердить утверждение о вычислении, не заставляя проверяющего повторять всю работу. Но доказательство не всегда бесплатно: его создание может занимать значительные ресурсы, а публикация нескольких отдельных proof и их проверка в базовой сети требуют места и вычислений. Если rollup создаёт отдельное доказательство для каждой партии операций, накладные расходы быстро растут. Отсюда возникает задача объединить результат без ослабления требуемой корректности.
Слова «агрегация» и «рекурсия» часто употребляют рядом, хотя они описывают не совсем одно и то же. Агрегация обычно означает получение компактного доказательства или общего результата, который покрывает набор исходных доказательств. Рекурсивное доказательство устроено так, что одно proof подтверждает корректность проверки других proof. Агрегация может использовать рекурсию, а рекурсивная схема может быть способом собрать последовательность вычислений. Это родственные инструменты, а не два взаимоисключающих вида блокчейна.
Представим несколько независимых чеков, подтверждающих отдельные этапы. Агрегатор собирает их в один отчёт, который проще предъявить. Рекурсивная проверка добавляет доказательство того, что сам процесс проверки чеков выполнен правильно. В криптографическом протоколе роли исполняют схемы, verifier-код, хеши, commitments и правила публичных входов. Простая аналогия не говорит о доверии к агрегатору: оно зависит от того, может ли любой участник проверить итог и что именно включено в публичные данные.
Базовый терминологический контекст даёт разбор zero-knowledge доказательств. Для блокчейнов отдельно важны устройство ZK-rollup и различия SNARK и STARK: тип доказательной системы влияет на размер proof, стоимость prover, требования к настройке и доступность verifier. Общие слова о компактности не заменяют измерение полной стоимости конкретной архитектуры.
Как работает агрегация
В наиболее понятной модели каждый prover формирует proof для своей задачи, а агрегатор получает несколько таких proof и строит новое доказательство, проверяемое дешевле, чем исходный набор. Контракт в базовой сети может проверить один агрегированный результат вместо большого числа отдельных. Но система должна связать все proof с правильными программами, публичными входами и порядком состояния. Если в объединении отсутствует партия или перепутана последовательность, конечный результат нельзя считать доказательством ожидаемого состояния.
Агрегация не обязательно означает, что итоговый объект краток во всех смыслах. Сама процедура может потребовать отдельного сервера, дополнительной памяти и времени. Некоторым архитектурам нужно ждать, пока несколько доказательств будут готовы, а значит размер партии влияет на задержку. Если prover недоступен или не принимает конкретную задачу, пользователь может столкнуться с очередью. Протоколы применяют разные схемы: агрегирование по слоям, параллельное объединение, обёртывание одним типом proof в другой и рекурсивную свёртку.
У RISC Zero в документации описан пример, где вычисление zkVM делится на сегменты, сегменты доказываются отдельно, а затем объединяются в succinct proof. Для некоторых сценариев доказательство может быть обёрнуто в Groth16 для эффективной проверки в сети, при этом setup и фиксированная верифицирующая схема имеют собственные свойства. Это пример конкретной инженерной реализации, а не универсальный рецепт для всех ZK-систем.
Для оценки rollup важно узнать, кто запускает агрегатор и может ли пользователь проверить публикацию независимо. Возможны модели с централизованным сервисом, открытым рынком prover или несколькими конкурирующими участниками. Даже если только корректный proof принимается контрактом, доступность proof и возможность его своевременно создать остаются операционными факторами. Проверяйте, как система ведёт себя при задержке, отказе и несоответствии входов.
Что добавляет рекурсия
В рекурсивной конструкции proof одной программы содержит проверку других proof. Условно, вместо того чтобы каждый раз предъявлять все предыдущие подтверждения, новая ступень подтверждает, что предыдущая ступень прошла verifier. Так можно последовательно свернуть длинную историю вычислений в доказательство ограниченного размера. Это полезно, например, для rollup, который подтверждает переход состояния от одного блока к следующему и затем объединяет множество переходов.
Рекурсия меняет задачу, но не удаляет всю работу. Prover должен доказать работу verifier для предыдущего proof, а параметры схемы должны поддерживать такой цикл. В системе могут быть разные кривые или слои доказательств; иногда один тип proof оборачивают в другой, чтобы ускорить проверку на целевой виртуальной машине. Размер и время итогового proof зависят от реализации, входов, числа шагов, конфигурации оборудования и оптимизаций. Цифры из тестов не обязательно соответствуют production-нагрузке.
Не следует считать рекурсивное proof доказательством того, что все данные навсегда доступны. Proof может подтверждать корректность перехода состояния или исполнения программы, но пользователю всё ещё может понадобиться доступ к данным состояния для просмотра баланса и создания следующей операции. Аналогично, рекурсия не доказывает корректность внешнего оракула или исходных сведений, если они не включены в проверяемые публичные входы.
Команда должна чётко указать публичные входы: хеш предыдущего состояния, корень нового состояния, идентификаторы программ, данные транзакций или commitment к ним. Затем важно понять, какие свойства проверяет контракт, что подтверждает внешняя DA-система и как участники могут воспроизвести путь. При чтении технической схемы полезно выписать цепочку: кто формирует proof, кто его агрегирует, какой verifier запускается, куда публикуются данные и что произойдёт при сбое.
Компромиссы и критерии оценки
Главный выигрыш обеих техник – меньше повторяемой работы для проверяющего или меньший объём onchain-проверки. Но сравнивать нужно целую систему. Измеряйте время и память prover, размер доказательства, стоимость verification, latency от операции до включения proof, доступность оборудования и частоту отказов. Маленький proof может дорого обходиться в создании, а дешёвая проверка может требовать сложной доверенной настройки или специализированного hardware.
Есть и вопросы безопасности. Уточните криптографические предположения, поле и кривую, хеш-функции, доверенную настройку, правила генерации ключей и процесс обновления verifier. Если схема использует recursion, посмотрите на circuit, который проверяет предыдущий proof, и убедитесь, что он связан с правильной программой. Важно также понять, кто может изменить параметры, остановить публикацию или заменить контракт. Аудит отдельных компонентов полезен, но не подтверждает безопасность всех интеграций.
Для пользователя итоговая оценка практична: сколько ждать завершения вывода, зависит ли вывод от одного оператора, доступны ли данные, может ли независимый участник создать proof и как долго действует окно оспаривания. Публичный explorer может показывать proof, но само наличие записи не означает, что вы проверили её смысл. Сопоставьте объяснение проекта с кодом verifier и актуальными спецификациями. Если заявлено ускорение, выясните, относительно какой базовой конфигурации оно измерено.
Итак, агрегация объединяет доказательства или их результаты в более удобную проверку, а рекурсия позволяет доказать саму проверку предыдущих proof и сворачивать длинные цепочки вычислений. В реальных системах эти подходы часто сочетаются. Ни один не освобождает от анализа доступности данных, prover-экономики и управления контрактами. Полезный вопрос не «использует ли проект рекурсию», а какие именно доказательства он формирует, что они покрывают и какие предположения остаются на других слоях.
