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

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

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

Что можно доказать, не раскрывая секрет

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

В формальной модели есть утверждение, которое видно обеим сторонам, и скрытое свидетельство — witness, с помощью которого доказывающий может показать, что утверждение верно. Например, утверждение может говорить, что существует секретный ключ, соответствующий открытому ключу. Доказывающий не обязан раскрывать сам секретный ключ; он показывает доказательство знания, которое проверяющая сторона может проверить.

Это не магия и не обещание «полной анонимности». Система должна удовлетворять нескольким требованиям. Если утверждение действительно верно и участники действуют по протоколу, доказательство принимается. Если оно ложно, нечестный участник не должен иметь возможность убедить проверяющего в обратном. А проверяющий не должен извлечь из доказательства секретную информацию, кроме самого факта, который оно подтверждает. В реальных схемах эти понятия оформляются математически и опираются на вычислительные предположения.

1985 год: «сложность знания»

Один из ключевых ранних текстов — статья Шафи Голдвассер, Сильвио Микали и Чарльза Рэккоффа «The Knowledge Complexity of Interactive Proof-Systems», представленная на конференции STOC в 1985 году и опубликованная в материалах конференции. Авторы предложили думать не только о том, можно ли проверить доказательство, но и о том, сколько дополнительной информации узнаёт проверяющий в ходе проверки.

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

Теоретическая важность идеи быстро стала шире одной математической задачи. В 1986 году Одед Голдрайх, Микали и Ави Вигдерсон показали широкую применимость zero-knowledge proofs для NP-языков при стандартных криптографических предположениях; они также рассматривали примеры, где можно подтвердить графовое свойство, не раскрывая структуру, которая его доказывает. Исследовательская идея перестала выглядеть узким трюком: она стала общим инструментом проектирования криптографических протоколов.

Смысл термина «нулевое разглашение» не в том, что проверяющий вообще ничего не узнаёт. Он узнаёт, что конкретное утверждение принято протоколом. Ноль относится к дополнительному знанию о секрете, а не к самому результату проверки. Если публичная часть приложения сообщает адрес, сумму или принадлежность к группе, эти данные не исчезают от того, что внутренняя проверка выполнена приватным proof.

Интерактивный разговор и хеширование вызова

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

Для цифровых систем бесконечный разговор неудобен. В 1986 году Амос Фиат и Ади Шамир описали практические схемы идентификации и подписи, в которых проверяемый обмен играл центральную роль. Позднее криптографы стали применять преобразование, известное как эвристика Fiat–Shamir: непредсказуемый вызов вычисляется хеш-функцией от предыдущих сообщений, так что интерактивный протокол можно представить как неинтерактивный пакет данных. Важно помнить, что безопасность такой замены доказывается в конкретной модели и не означает, что любой разговор безопасно «просто захешировать».

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

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

Короткие доказательства для сложных вычислений

Следующий шаг — доказательства, которые коротко сообщают результат проверки большого вычисления. В 2013 году исследователи Bryan Parno, Jon Howell, Craig Gentry и Mariana Raykova представили систему Pinocchio для проверяемых вычислений. В абстракте авторы описали proof размером 288 байт для общей схемы и время проверки около 10 миллисекунд в их тестах. Это были результаты конкретной системы и экспериментального набора задач, а не универсальные показатели всех SNARK.

В 2016 году Йеспер Грот опубликовал работу о pairing-based non-interactive arguments, известную как Groth16. В описанном им варианте доказательство состояло из трёх элементов группы и проверялось через одну pairing-product equation. Компактность была привлекательна для систем, где сеть должна быстро проверить доказательство на цепи. Но такие конструкции опирались на setup: параметры должны быть сгенерированы корректно, а секретная часть, если она существовала, не должна оставаться доступной.

Слово SNARK расшифровывается как succinct non-interactive argument of knowledge. «Краткое» обычно относится к размеру доказательства и стоимости его проверки относительно исходного вычисления; «неинтерактивное» — к тому, что проверка не требует диалога; «аргумент знания» — к вычислительному характеру гарантии в заданной модели. Это не означает, что доказательство доказывает произвольное утверждение: сначала программист должен корректно выразить проверяемую логику как circuit или вычислительную схему.

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

От приватных платежей к масштабированию

В блокчейне proof может решать две очень разные задачи. Первая — приватность: показать, что перевод удовлетворяет правилам баланса и авторизации, не раскрывая сумму или адреса в публичном реестре. Вторая — масштабирование: выполнить большой пакет транзакций вне основной цепи, а затем опубликовать компактное доказательство корректности результата. Во втором случае доказательство отвечает прежде всего на вопрос «правильно ли оператор применил правила?», а не на вопрос «скрыто ли от всех, кто и когда что делал?».

Zcash стал заметным примером прикладного использования. Проект Sprout, запущенный в 2016 году, опирался на zk-SNARK-параметры, созданные в многосторонней церемонии. В 2018 году обновление Sapling уменьшило ресурсы, необходимые для shielded-транзакций; официальное описание сети указывало, что некоторые такие операции могли строиться за несколько секунд и с примерно 40 МБ памяти на подходящем оборудовании. Эти цифры относятся к конкретному обновлению и его тестовым условиям.

В 2022 году обновление Zcash NU5 активировало Orchard и систему Halo для shielded-пула. Официальное описание апгрейда говорит, что переход на Halo устранял необходимость в доверенной настройке для этой части протокола. Это был важный сдвиг в компромиссах системы, но он не означал, что абсолютно все транзакции Zcash стали скрыты или что все версии протокола используют одинаковый доказательный механизм.

На Ethereum и других сетях zero-knowledge proofs широко обсуждаются в контексте rollups. Оператор может доказать, что новый агрегированный state получен корректным исполнением транзакций, а сеть проверяет proof дешевле, чем повторно выполняет каждую операцию. Но данные для восстановления состояния и доступность этих данных — отдельная задача. Современная документация Ethereum подчёркивает, что для независимой проверки данных должны быть доступны. И даже если proof короткий и корректный, публичные входы, время публикации, размер пакета и адрес контракта могут раскрывать наблюдателю часть поведения.

Один из прикладных примеров — zkEVM, где доказательство связывается с выполнением логики, совместимой с виртуальной машиной Ethereum. В отдельном материале «Что такое zkEVM?» разобраны архитектурные варианты; здесь же важно различие между подтверждением корректности вычисления и конфиденциальностью его участников.

Как проверять обещание приватности

Приватность — свойство приложения в целом, а не наклейка на используемый алгоритм. Нужно определить, что именно считается секретом, кому его требуется скрыть и какие метаданные остаются публичными. Если приложение прячет содержимое сообщения, но открывает отправителя и время, этого может быть достаточно для одной задачи и недостаточно для другой. Если proof скрывает баланс, но пользователь регулярно взаимодействует с тем же публичным адресом, связь между транзакциями всё ещё может быть видна.

Корректность тоже локальна. Доказательство может подтверждать, что функция удовлетворяет заданному circuit, но не то, что функция воплощает намерение продукта. Ошибка в circuit способна формально доказать неправильное правило. Неправильная интеграция может пропустить данные мимо защищённого компонента. Приложение, которое публикует секрет до генерации proof, не становится приватным от одной только проверки результата.

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

Поэтому на вопрос «обеспечивает ли zero-knowledge privacy?» правильный ответ начинается с уточнений. Какое утверждение доказано? Какие witness и публичные входы используются? Что всё равно попадает в блокчейн или журнал приложения? Есть ли доверенная настройка и как она проводилась? Кто может восстановить данные? Каковы последствия ошибки в коде? Только после этих вопросов слово «приватность» приобретает проверяемый смысл.

Доказательства с нулевым разглашением начались как ответ на математический вопрос о том, сколько знания раскрывает процесс проверки. От интерактивного обмена 1980-х исследования пришли к компактным доказательствам вычислений и реальным блокчейн-протоколам. Они позволяют проверять сложные утверждения и иногда скрывать чувствительные данные. Но они не отменяют необходимости ясно определить утверждение, выбрать разумные публичные входы и защитить всю систему вокруг proof.

Источники

• Shafi Goldwasser, Silvio Micali, Charles Rackoff, “The Knowledge Complexity of Interactive Proof-Systems”, STOC ’85; публикация ACM датируется 1985 годом.
• Oded Goldreich, Silvio Micali, Avi Wigderson, “Proofs that Yield Nothing But their Validity”, расширенное резюме 1986 года.
• Amos Fiat, Adi Shamir, “How to Prove Yourself”, CRYPTO 1986; идентификация и подписи.
• Bryan Parno et al., “Pinocchio: Nearly Practical Verifiable Computation”, IEEE S&P 2013; описание системы и собственные показатели авторов.
• Jens Groth, “On the Size of Pairing-Based Non-interactive Arguments”, EUROCRYPT 2016; статья и открытая версия в UCL Discovery.
• Zcash trusted setup ceremony, 22–23 октября 2016; публичное описание параметров Sprout и многосторонней церемонии.
• Zcash Sapling, активировано 29 октября 2018 года; описание затрат на shielded-транзакции и ключей просмотра.
• Sean Bowe, “Explaining Halo 2”, Electric Coin Company, 1 сентября 2020; цели Halo 2 и setup.
• Zcash NU5, активировано 31 мая 2022 года; Orchard и переход на Halo.
• Ethereum.org, Privacy on Ethereum; различие масштабирования ZK-rollups и конфиденциальности приложений.
• Ethereum.org, Data Availability; почему доказательство и доступность данных решают разные задачи.