Verifier получает ответ «правило выполнено», но не исходный секрет
У обычной проверки есть простой путь: показать входные данные и дать второй стороне повторить вычисление. Zero-knowledge protocol ставит более узкую задачу. Prover убеждает verifier, что знает witness, который удовлетворяет формальному relation, при этом proof не должен раскрыть сам witness сверх того, что уже следует из истинности statement.
| Часть | Что это | Пример без привязки к продукту |
|---|---|---|
| Statement | Утверждение, которое нужно проверить | Существует secret value, чей hash равен публичному H |
| Witness | Секретные данные prover | Само значение, из которого получается H |
| Circuit или relation | Формальные правила допустимого вычисления | Посчитать hash и сравнить его с H |
| Proof | Криптографический объект для verifier | Подтверждение, что witness удовлетворяет relation |
| Public inputs | Открытые значения, связанные с proof | H, версия circuit или state roots |
- Часть
- Statement
- Что это
- Утверждение, которое нужно проверить
- Пример без привязки к продукту
- Существует secret value, чей hash равен публичному H
- Часть
- Witness
- Что это
- Секретные данные prover
- Пример без привязки к продукту
- Само значение, из которого получается H
- Часть
- Circuit или relation
- Что это
- Формальные правила допустимого вычисления
- Пример без привязки к продукту
- Посчитать hash и сравнить его с H
- Часть
- Proof
- Что это
- Криптографический объект для verifier
- Пример без привязки к продукту
- Подтверждение, что witness удовлетворяет relation
- Часть
- Public inputs
- Что это
- Открытые значения, связанные с proof
- Пример без привязки к продукту
- H, версия circuit или state roots
Важная точность: proof не доказывает бытовую фразу сам по себе. Он подтверждает конкретную математическую relation. Если circuit проверяет только возраст не меньше 18 лет, корректный proof не подтверждает имя, гражданство или подлинность исходного документа — если проверка этих фактов не включена в систему отдельно.
У хорошей proof system три разных обещания
Свойства проверяются по разным сценариям
- Честный prover с правильным witness проходит проверку
Если statement истинно и protocol выполнен корректно, verifier должен принять proof.
- Ложное statement нельзя убедительно доказать
Злоумышленник без подходящего witness не должен создавать accepted proof, кроме пренебрежимо малой вероятности в заданной security model.
- Proof не раскрывает witness
Verifier узнаёт допустимый результат проверки, а не secret inputs, использованные prover.
Эти свойства нельзя заменять друг другом. System может хорошо скрывать witness, но проверять неправильный circuit. Корректный validity proof может подтверждать computation без какой-либо цели скрыть все transaction details. А приватное соединение с сервером не становится zero-knowledge proof только потому, что данные зашифрованы при передаче.
Главная вычислительная работа обычно достаётся prover
Перед доказательством обычную программу представляют в форме, подходящей выбранной proof system. Prover выполняет computation, собирает witness и создаёт proof. Verifier затем проверяет гораздо более компактный объект. Именно асимметрия между дорогим proving и сравнительно дешёвым verification делает ZK полезным для блокчейна: много вычислений можно выполнить вне L1, а on-chain contract проверит их результат.
| Стадия | Основная работа | Практическое ограничение |
|---|---|---|
| Circuit design | Формализовать допустимые inputs и computation | Ошибка или неполное правило будут доказуемо исполняться именно так |
| Witness generation | Подготовить private и public inputs | Данные должны соответствовать точной версии circuit |
| Proving | Построить cryptographic proof | Время, память, hardware и latency могут быть значительными |
| Verification | Проверить proof и public inputs | Стоимость зависит от proof system и verification environment |
| Data publication | Сделать нужные данные доступными | Proof of validity не гарантирует, что state можно восстановить без data |
- Стадия
- Circuit design
- Основная работа
- Формализовать допустимые inputs и computation
- Практическое ограничение
- Ошибка или неполное правило будут доказуемо исполняться именно так
- Стадия
- Witness generation
- Основная работа
- Подготовить private и public inputs
- Практическое ограничение
- Данные должны соответствовать точной версии circuit
- Стадия
- Proving
- Основная работа
- Построить cryptographic proof
- Практическое ограничение
- Время, память, hardware и latency могут быть значительными
- Стадия
- Verification
- Основная работа
- Проверить proof и public inputs
- Практическое ограничение
- Стоимость зависит от proof system и verification environment
- Стадия
- Data publication
- Основная работа
- Сделать нужные данные доступными
- Практическое ограничение
- Proof of validity не гарантирует, что state можно восстановить без data
SNARK и STARK — семейства с разными инженерными компромиссами
| Свойство | zk-SNARK | zk-STARK |
|---|---|---|
| Название | Succinct Non-Interactive Argument of Knowledge | Scalable Transparent Argument of Knowledge |
| Размер proof | Обычно компактный в распространённых constructions | Обычно крупнее SNARK proof |
| Setup | Часть schemes использует common reference string или trusted setup | Transparent schemes избегают trusted setup через публичную randomness |
| Криптографическая основа | Зависит от конкретной construction | Часто hash-based design |
| Выбор | Определяется circuit, verifier cost, prover stack и security assumptions | Определяется теми же системными ограничениями |
- Свойство
- Название
- zk-SNARK
- Succinct Non-Interactive Argument of Knowledge
- zk-STARK
- Scalable Transparent Argument of Knowledge
- Свойство
- Размер proof
- zk-SNARK
- Обычно компактный в распространённых constructions
- zk-STARK
- Обычно крупнее SNARK proof
- Свойство
- Setup
- zk-SNARK
- Часть schemes использует common reference string или trusted setup
- zk-STARK
- Transparent schemes избегают trusted setup через публичную randomness
- Свойство
- Криптографическая основа
- zk-SNARK
- Зависит от конкретной construction
- zk-STARK
- Часто hash-based design
- Свойство
- Выбор
- zk-SNARK
- Определяется circuit, verifier cost, prover stack и security assumptions
- zk-STARK
- Определяется теми же системными ограничениями
Аббревиатура не сообщает всю security model. Современные SNARK constructions могут отличаться setup, recursion и assumptions; слово STARK тоже не описывает конкретную реализацию prover. Сравнивать нужно точную proof system и версию, процедуру parameter generation, реализацию verifier, audit и возможность обновить circuit.
Trusted setup не означает, что один участник постоянно видит secret transactions. Речь идёт о создании public parameters: в некоторых schemes компрометация секретной randomness setup могла бы нарушить soundness. Multi-party ceremony снижает риск при условии, что хотя бы один участник честно уничтожил свою часть entropy. Другие constructions используют transparent setup и принимают иной набор trade-offs.
ZK может защищать witness и всё равно оставлять пользователя узнаваемым
Что может остаться публичным рядом с proof
- адрес account или contract, который отправил transaction;
- время, сеть, gas payer и block inclusion;
- public inputs, включая roots, commitments или nullifiers;
- размеры и частота операций, если их не скрывает protocol design;
- deposit и withdrawal paths между прозрачными и защищёнными частями системы;
- данные, добровольно раскрытые интерфейсу, issuer или prover service.
Zcash показывает применение zk-SNARK в shielded transaction: сеть может проверить соблюдение consensus rules без раскрытия защищённых деталей в обычной форме. Но это свойство всей payment construction, а не любого proof. Если dapp доказывает правильность вычисления публичного swap, сам swap не становится приватным только из-за ZK-verifier.
В ZK-rollup proof подтверждает переход state, а Ethereum хранит точку проверки
Operator собирает batch L2 transactions, применяет их к предыдущему state и получает новый state root. Proving circuit проверяет последовательность переходов: signatures, nonce, balances и другие правила конкретного rollup. Затем L1 verifier contract принимает validity proof вместе с public inputs, среди которых могут быть pre-state root, post-state root и batch commitment.
| Вопрос | Validity proof | Доступные transaction data |
|---|---|---|
| Правильно ли вычислен новый root? | Подтверждает relation между inputs и результатом | Позволяют независимо воспроизвести computation |
| Можно ли восстановить account state? | Одного proof может быть недостаточно | Нужны данные, определённые protocol |
| Скрыты ли действия пользователя? | Зависит от circuit и public inputs | Публикация может оставлять details открытыми или сжатыми |
| Кто может продолжить chain при отказе operator? | Proof подтверждает уже доказанный переход | Recovery зависит от доступности data и escape mechanics |
- Вопрос
- Правильно ли вычислен новый root?
- Validity proof
- Подтверждает relation между inputs и результатом
- Доступные transaction data
- Позволяют независимо воспроизвести computation
- Вопрос
- Можно ли восстановить account state?
- Validity proof
- Одного proof может быть недостаточно
- Доступные transaction data
- Нужны данные, определённые protocol
- Вопрос
- Скрыты ли действия пользователя?
- Validity proof
- Зависит от circuit и public inputs
- Доступные transaction data
- Публикация может оставлять details открытыми или сжатыми
- Вопрос
- Кто может продолжить chain при отказе operator?
- Validity proof
- Proof подтверждает уже доказанный переход
- Доступные transaction data
- Recovery зависит от доступности data и escape mechanics
Поэтому validity rollup и validium нельзя объединять словом ZK. Оба могут использовать validity proofs, но отличаются местом data availability. Точно так же быстрый вывод после proof verification не говорит, сколько времени заняли batch formation, proving, submission и L1 inclusion до этой стадии.
У обещания «работает на ZK» должно быть пять конкретных ответов
- Какое exact statement доказывается и какие проверки входят в circuit?
- Что является private witness, а что публикуется как public input или calldata?
- Какая proof system и версия используются, нужен ли setup и кто управлял ceremony?
- Где работает verifier, кто может обновить его code и есть ли audit этой реализации?
- Где доступны данные для восстановления state и что происходит при отказе prover или operator?
Ответ «мы не раскрываем алгоритм» противоречит самой идее проверяемой системы, если пользователю невозможно установить relation, verifier и security assumptions. При этом открытый verifier ещё не доказывает правильность данных до circuit: issuer, oracle или identity provider остаются отдельными источниками доверия.
Лучше думать не «ZK скрывает всё», а «какую часть утверждения можно проверить отдельно»
Zero-knowledge proof разделяет знание и проверку: одна сторона использует witness, другая получает математически ограниченный ответ. Эта конструкция полезна для privacy, масштабирования, identity и доказуемых вычислений, но каждый продукт выбирает свой statement и public boundary. Сила ZK начинается с точности этого выбора — и заканчивается там, где circuit больше ничего не проверяет.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Ethereum.org — zero-knowledge proofs Ethereum Foundation · Проверено 15 августа 2026 г. в 00:34 GMT+5
- Ethereum.org — zero-knowledge rollups Ethereum Foundation · Проверено 15 августа 2026 г. в 00:34 GMT+5
- Ethereum.org — scaling Ethereum Foundation · Проверено 15 августа 2026 г. в 00:34 GMT+5
- Zcash — what are zk-SNARKs Electric Coin Company / Zcash · Проверено 15 августа 2026 г. в 00:34 GMT+5