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

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

Экономика ZK-rollup появляется на уровне пакета. Вычисления выполняются вне Ethereum, затем контракт в сети проверяет доказательство перехода состояния. Фиксированные расходы на проверку распределяются между операциями в пакете. Чем крупнее пакет, тем меньше может оказаться доля этих расходов на одну транзакцию. Но размер пакета ограничен нагрузкой, требованиями к задержке и тем, как часто пользователям нужно подтверждение состояния.

Поэтому проверить, оправданы ли затраты на внедрение, можно только на нагрузке и архитектуре конкретного приложения. Универсального порога транзакций, после которого ZK становится выгоднее альтернативы, нет. Стоимость зависит и от того, какие данные проект обязан публиковать в L1.

Полная стоимость состоит из нескольких контуров

Удобная ошибка в оценке ZK — взять стоимость вызова верификатора и объявить её стоимостью решения. В реальной схеме есть как минимум две разные группы затрат. Первая связана с выполнением и доказательством вычислений. Вторая — с тем, чтобы сеть и пользователи могли восстановить или проверить состояние.

В ZK-rollup оператор собирает транзакции и выполняет соответствующие вычисления вне Ethereum. Затем он формирует доказательство, которое подтверждает корректность перехода состояния. L1-контракт проверяет доказательство, а данные, необходимые для восстановления состояния, публикуются отдельно. Доказательство корректности не отменяет эту публикацию.

Сумма этих статей и есть рабочая стоимость системы. Одни расходы видны непосредственно в транзакциях Ethereum. Другие оплачиваются инфраструктурой оператора или командой разработки и не исчезают оттого, что их не видно в обозревателе блоков.

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

Gas верификатора — заметная строка сметы, но не вся смета. Экономику определяет сумма вычислений, публикации данных и обслуживания сети.

Почему 500 000 gas не дают ответа об окупаемости

Ориентир около 500 000 gas относится к проверке одного доказательства в описываемом контексте ZK-rollup на Ethereum. Это не тариф для всех ZK-систем, приложений и схем. Денежная цена зависит от текущей стоимости газа, а фактическая реализация влияет на то, какой объём работы выполняет конкретный контракт.

Главное для пакетной архитектуры: доказательство может покрывать переход состояния сразу для набора транзакций. Тогда стоимость его проверки приходится на пакет, а не на каждую операцию отдельно. В упрощённой модели доля проверки на транзакцию определяется расходом gas на проверку, умноженным на цену газа и разделённым на число операций в пакете. Но на этом расчёт не заканчивается: к нему добавляются публикация данных, генерация доказательства и остальные расходы.

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

Поэтому ориентир в 500 000 gas полезен как входной параметр модели, а не как вердикт о выгоде. Для сравнения с другой архитектурой нужны сопоставимые сценарии: одинаковая нагрузка, одинаковые требования к подтверждению, учёт расходов на L1 и стоимость вычислений вне сети. Без этих условий число не доказывает окупаемость.

Calldata и blobs: стоимость публикации и доступность данных

В расходах rollup публикация данных часто требует отдельного внимания. После обновления Dencun и EIP-4844 rollups получили возможность использовать blobs с отдельным рынком комиссий. Обычно blobs дешевле calldata для публикации данных. В calldata базовая схема тарификации, приводимая для Ethereum, различает ненулевые байты, которым соответствует 16 gas, и нулевые байты, которым соответствует 4 gas. Реальный платёж зависит от объёма и состава данных, а также цены газа.

Выбор формата влияет на модель затрат, но у blobs есть существенное свойство: это не постоянное архивное хранение. Ethereum гарантирует обслуживание blob-данных в течение минимального окна примерно 18 дней. Если приложению, операторам или сторонним участникам нужны данные дольше, модель хранения и доступности должна учитывать отдельные механизмы. Перенос данных в более дешёвый формат сам по себе не решает задачу долговременного архива.

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

Для проектной сметы это означает, что способ публикации надо выбирать с учётом двух параметров: стоимости и требований к доступу. Если приложению нужна возможность восстановления состояния после выхода оператора из системы, вопрос доступности нельзя свести к цене записи в L1. Если цель — скрыть содержание транзакций, сам переход на ZK-rollup эту задачу также не закрывает.

Нагрузка меняет результат сильнее, чем паспортные цифры

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

В модели затрат нужно разделять по меньшей мере три параметра:

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

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

Работы по моделированию инфраструктуры ZK-rollup выделяют TPS, средний расход газа и время финальности как существенные входы расчёта. В одной исследовательской модели сообщается о потенциальном снижении затрат до 70% для предложенного метода и симуляции. Это результат конкретной модели, а не обещание экономии для произвольного проекта. Переносить его в коммерческую смету без повторения условий и бенчмарка нельзя.

Практический тест должен идти на вычислениях приложения, а не на абстрактном примере из документации. Для одних задач доминирует стоимость доказательства, для других — объём данных или частота публикации. Систематический обзор 25 ZK-фреймворков сравнивал удобство и производительность на экспериментах с SHA-256 и умножением матриц. Такой набор полезен для сопоставления инструментов, но не заменяет тестирование целевой схемы: хэширование, арифметика и логика конкретного смарт-контракта создают разный профиль нагрузки.

Разработка, аудит и доверенная настройка

Инструментарий тоже влияет на стоимость владения. Разные ZK-фреймворки отличаются производительностью и удобством работы, а выбор одной системы может изменить стоимость генерации, сложность реализации и объём аудита. Бенчмарк на простой операции показывает лишь часть картины. Для оценки нужны тесты на тех вычислениях, которые действительно попадут в доказательство, с теми же ограничениями по времени и оборудованию, что будут в эксплуатации.

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

Отдельный вопрос — trusted setup. Для части zk-SNARK-систем безопасность зависит от корректности церемонии генерации общих параметров и от предположения, что хотя бы один участник уничтожил свою часть случайности. Это не универсальное свойство всех ZK-протоколов, но для конкретной системы оно должно входить в модель угроз. Если команда не может обосновать, как проходила настройка и какие предположения приняты, снижение комиссии не компенсирует этот пробел.

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

Технический вердикт

ZK-доказательства оправданы там, где проекту подходит пакетная модель, а стоимость генерации и публикации укладывается в требования к задержке, доступности и безопасности. Число около 500 000 gas помогает оценить проверку доказательства в конкретном контексте Ethereum, но не устанавливает точку окупаемости. Такую точку нельзя вывести без данных о нагрузке и полной архитектуре.

Решение следует принимать по бенчмарку целевого приложения и полной стоимости жизненного цикла: генерации, проверки, публикации, инфраструктуры, разработки и аудита. Потенциальная экономия из исследовательской симуляции не заменяет измерений. А если проекту нужна конфиденциальность, это требование надо проверять отдельно: доказательство корректности само по себе не скрывает опубликованные данные.

Технический вердикт простой: без сопоставимого теста нагрузки и расчёта всех статей затрат утверждение об окупаемости ZK — не результат анализа, а предположение.