Коротко: рынок prover-сетей соединяет заказчиков доказательств с операторами вычислительного оборудования. Заказчик описывает программу, входные данные, срок и условия оплаты. Provers оценивают трудоёмкость, конкурируют за заказ, строят proof и получают вознаграждение после успешной проверки. Платит приложение или протокол, а экономически расход может быть включён в комиссию пользователей или покрыт субсидией.
Генерация ZK-доказательства обычно значительно тяжелее его проверки. Verifier может подтвердить компактный proof в смарт-контракте, но prover перед этим исполняет программу, строит трассу, обрабатывает ограничения и выполняет криптографические вычисления. Prover-сеть превращает эту работу в отдельный инфраструктурный рынок.
Какие участники есть на рынке
Requester формирует запрос. Им может быть rollup, мост, приложение, сопроцессор или отдельный пользователь. Запрос связывает конкретную программу с входными данными и ожидаемым публичным результатом.
Prover предоставляет вычислительные ресурсы. Он получает программу и доступные входы, оценивает время, строит доказательство и отправляет его до срока. В зависимости от системы используются CPU, GPU, большой объём памяти или специализированные ускорители.
Market или coordinator распределяет задания. Это может быть on-chain контракт с открытыми ставками, централизованный планировщик или смешанная система. Он следит за заявками, сроками, collateral и выплатами.
Aggregator объединяет несколько proof в одно рекурсивное доказательство. Это снижает стоимость публикации и on-chain проверки, но добавляет ещё один этап и собственные требования к доступности.
Verifier проверяет конечный proof и публичные входы. Он не обязан доверять личности prover: некорректное доказательство должно быть отклонено криптографической проверкой. Однако prover всё равно способен вызвать задержку, если взял заказ и не завершил его.
Жизненный цикл заказа
- Разработчик фиксирует гостевую программу или circuit и определяет публичные входы.
- Requester публикует запрос, данные или ссылку на них, срок и условия вознаграждения.
- Provers оценивают стоимость исполнения и выбирают задания.
- Один или несколько операторов принимают заказ, иногда блокируя collateral.
- Выбранный prover исполняет программу и строит доказательство.
- Proof при необходимости агрегируется и отправляется verifier.
- После успешной проверки escrow выпускает оплату, а requester использует результат.
В открытом рынке цена может задаваться диапазоном или аукционом. Например, запрос начинает с одной цены и повышает её по мере приближения срока либо provers предлагают собственные условия. В другой архитектуре планировщик заранее распределяет поток между операторами по производительности.
Что именно оплачивается
Цена proof – это не только электричество видеокарты. В неё входят исполнение гостевой программы, построение witness, память, передача данных, хранение промежуточных результатов, рекурсия, резерв мощности и риск не уложиться в deadline.
Тяжёлый circuit с большим trace стоит дороже простого вычисления. Важны тип доказательной системы, используемые кривые и хеши, объём памяти, возможность параллельного исполнения и требуемая задержка. Срочное доказательство может быть дороже того же задания, которое разрешено поставить в очередь и объединить с другими.
Отдельно оплачивается публикация результата в блокчейне. Даже компактный proof требует calldata или blob, вызова verifier contract и газа. Если несколько доказательств рекурсивно объединяются, on-chain стоимость на одно задание уменьшается, но появляется цена aggregation.
Кто платит за ZK-доказательство
Юридическим плательщиком обычно выступает requester. Rollup может финансировать prover из комиссии за транзакции, мост – из платы за сообщение, а приложение – из собственного бюджета. Пользователь не всегда видит отдельную строку за proof, но расход всё равно входит в экономику сервиса.
На раннем этапе протокол способен субсидировать вычисления токеновыми наградами или средствами фонда. Такая цена не обязательно отражает устойчивую себестоимость. После сокращения субсидий комиссия должна покрываться реальным спросом, иначе качество обслуживания зависит от постоянной эмиссии.
Некоторые рынки требуют заранее пополнить escrow на максимальную цену заказа. Другие рассчитываются после проверки или используют периодический биллинг. Пользователю важно отличать оплату вычисления от staking: collateral prover служит гарантией исполнения, а не заменяет плату за выполненную работу.
Почему некорректный prover не может подделать результат
Verifier принимает доказательство только для заданного verification key и набора публичных входов. Prover не может просто изменить результат, если криптографическая схема и контракт реализованы правильно. Именно поэтому проверка значительно легче повторного вычисления.
Но proof подтверждает только сформулированное утверждение. Если программа получила ложную цену, неверный state root или неполные данные, prover может честно доказать вычисление над неправильным входом. Разницу между универсальной машиной и EVM-контуром раскрывает материал о zkVM и zkEVM.
Обновление программы или verification key тоже критично. Если requester и verifier используют разные версии, корректный proof окажется бесполезным. Если управляющий ключ может незаметно заменить verifier, доверие смещается с математики на процедуру обновления.
Collateral, штрафы и доступность
Открытый prover может взять выгодное задание и исчезнуть. Поэтому рынок применяет collateral, блокировку заказа и штраф за пропущенный срок. Размер обеспечения должен быть достаточным, чтобы нарушение было экономически невыгодным, но не настолько большим, чтобы допускались только крупнейшие операторы.
Резервные provers повышают доступность, однако дублирование увеличивает расход. Планировщик может отправить один заказ нескольким участникам, переключиться после тайм-аута или заранее распределить мощности. Для rollup важна не только средняя скорость, но и поведение при резком росте очереди.
Если доказательство необходимо для финализации состояния, сбой prover задерживает выводы и подтверждение новых пакетов. Это проблема liveness, даже если деньги нельзя украсть. Сравнение ответственности участников полезно дополнить статьёй о том, кто упорядочивает транзакции based rollup.
Риски prover-сетей
- Концентрация оборудования. Несколько крупных операторов могут контролировать большую часть мощности.
- Цензура. Provers способны игнорировать определённые запросы, если нет резервного пути.
- Утечка witness. Заказчик должен понимать, какие входные данные увидит внешний оператор.
- Срыв срока. Некорректный proof отвергается, но задержка всё равно влияет на приложение.
- Ошибка рынка. Уязвимость escrow или механизма назначения может нарушить расчёты.
- Скрытая субсидия. Низкая текущая цена может держаться на временных наградах.
Архитектура rollup также определяет, где проверяется доказательство и кто обновляет состояние. Эти различия рассматриваются в сравнении native rollup и smart-contract rollup.
Как сравнивать prover-сети
Смотрите на поддерживаемые proof systems и версии zkVM, способ передачи входов, правила доступа к приватным данным, механизм назначения заказов, collateral и штрафы. Измеряйте не только минимальную цену, но и время на разных размерах trace, долю просроченных запросов и способность пережить отказ крупнейшего prover.
Проверьте, можно ли перенести задание другому оператору и самостоятельно проверить результат. Открытый рынок полезен только тогда, когда requester не заперт в проприетарном формате программы, данных и proof.
Итог
Prover-сеть продаёт проверяемое вычисление как услугу. Requester формирует заказ и финансирует его, provers конкурируют за работу, aggregator уменьшает итоговую нагрузку, а verifier подтверждает proof. Криптография защищает корректность результата, но доступность, приватность, цена и централизация по-прежнему зависят от устройства рынка.
