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

Доказательства с нулевым разглашением (ZKP) стали одной из самых преобразующих криптографических примитив в современных блокчейн-системах. В отличие от общих статей, которые разбавляют техническую суть, этот текст раскрывает реальные механизмы, настоящую математику и реальные ограничения ZK-приватных систем, используемых в альткоинах, таких как Zcash, Aleo и Firo — без абстракций и маркетинговой воды.

1. Что такое доказательство с нулевым разглашением (математически)

ZKP — это интерактивный или неинтерактивный протокол, позволяющий доказывающему P убедить проверяющего V, что утверждение верно, не раскрывая никакой информации, кроме истинности утверждения.

Формально ZKP должен удовлетворять:

1. Полнота: если утверждение верно, честный проверяющий примет доказательство.
2. Корректность: злонамеренный доказывающий не может убедить проверяющего в ложности утверждения.
3. Нулевое разглашение: проверяющий не узнает ничего, кроме того, что утверждение верно.
   Нулевое разглашение определяется через симулятор S:
   если S может сгенерировать неотличимый протокол без знания свидетельства, протокол является нулевым разглашением.

В блокчейн-применении утверждение обычно выглядит так:

«Я знаю секрет (свидетельство), который хэшируется в это публичное значение».
или
«Я владею монетами, принадлежащими к коммитментам, не раскрывая, какие именно».

2. Схемы коммитментов — основа ZK-приватных монет

Большинство приватных монет используют коммитменты для скрытия значений транзакций и владения.

Коммитмент определяется как:
C = Commit(value, randomness)

Свойства:

• Скрытие: значение нельзя извлечь из C.
• Связь: доказывающий не может изменить значение позже.

Распространённые схемы:

• Pedersen-коммитменты:
  C = v·G + r·H в эллиптических группах (используется в Firo Lelantus / MimbleWimble).
• Коммитменты на основе SHA-256: используются в некоторых zk-SNARK схемах для эффективности.

Pedersen-коммитменты позволяют:

• Аддитивная гомоморфность: C1 + C2 = Commit(v1 + v2, r1 + r2).
  → Это позволяет конфиденциальным транзакциям сохранять общую сумму.

3. zk-SNARK и zk-STARK — почему приватные монеты используют одно из них

3.1 zk-SNARK (Succinct Non-Interactive Argument of Knowledge)

Используется в:

• Zcash (Sapling)
• Horizen
• Firo Lelantus Spark

Свойства:

• Очень маленькие доказательства (~192 байт в Sapling).
• Очень быстрая проверка (~10 мс).
• Требует доверенной настройки (проблема токсичных отходов).
• Использует парные операции на эллиптических кривых (BLS12-381 в основном).

Техническая деталь, часто опускаемая:
Zcash изначально использовал BN254 (Jubjub), но перешёл на BLS12-381 из-за слабостей подгрупп и опасений по поводу 128-битного уровня безопасности.

3.2 zk-STARK (Scalable Transparent ARguments of Knowledge)

Используется в:

• Aleo
• StarkNet (не монета, но релевантно)

Свойства:

• Не требует доверенной настройки.
• Постквантовая безопасность (основана на хэш-функциях, а не на парных операциях).
• Доказательства большие (~100–500 КБ).
• Проверка быстрая и масштабируемая.

Малоизвестный факт:
На раннем тестнете Aleo доказательства были настолько большими, что пропускная способность сети стала узким местом; оптимизация уменьшила размер доказательства примерно на 80% до выхода mainnet.

4. Где встречается нулевое разглашение внутри приватной транзакции

Приватный альткоин обычно использует ZKP для одного или нескольких из следующих случаев:

4.1 Скрытие отправителя

Механизмы:

• Кольцевые подписи (Monero — не ZK, но связано).
• Доказательства членства с нулевым разглашением (Zcash, Lelantus).

Пример (упрощённо):
Доказывающий показывает, что знает секретный ключ для одного элемента в наборе коммитментов не раскрывая, какой именно.

4.2 Скрытие получателя

Используются скрытые адреса или диверсифицированные адреса.
Zcash использует адреса платежей и ключи просмотра входящих транзакций для избирательной прозрачности.

4.3 Скрытие суммы

Pedersen-коммитменты + ZKP, который:

• суммы коммитментов корректны,
• суммы неотрицательные (range proofs),
• не возникает инфляции.

Старые range proofs (Confidential Transactions, предложения Bitcoin):
~2–3 КБ на выход.

Bulletproofs:
~700 байт на выход (использует Monero).

zk-SNARK:
Zcash скрывает суммы с доказательствами размером всего 192 байта.

5. Конкретный пример транзакции: Zcash Sapling

Защищённая транзакция Zcash Sapling доказывает:

1. У плательщика есть note (скрытая монета).
2. Note ранее не была потрачена (nullifier ZKP).
3. Сумма выхода равна сумме входа (balance ZKP).
4. Выходные notes являются корректными коммитментами.

Что реально доказывается?

Доказывающий строит схему, покрывающую:

• Хэши (BLAKE2s) коммитментов notes
• Pedersen-хэши
• Аутентификацию пути дерева Меркла
• Вычисление nullifier
• Уравнения сохранения значения

Полная сложность схемы — ~2 миллиона ограничений.
Генерация доказательства использует Groth16, требуя:

• FFT-вычислений
• Многомасштабных умножений
• EC pairings

На ноутбуке генерация одного доказательства занимает ~1–2 секунды (оптимизировано с использованием кривых Pallas/Vesta в Orchard).

Редко упоминаемый факт:
Схема Sapling использует битовое разложение для range constraints, что сильно увеличивает число ограничений; Orchard заменил это на арифметизацию PLONKish из Halo 2, что значительно снизило сложность.

6. Lelantus Spark (Firo) — недооценённая ZK-система

Система «Spark» от Firo — одна из самых технически продвинутых, но малоизвестных широкой публике.

Ключевые инновации:

• Полностью ZK (без кольцевых подписей).
• Использует One-of-Many Proofs:
  Доказывающий показывает, что владеет одной note из N, размер доказательства растёт логарифмически от N.
• Не требует доверенной настройки.
• Суммы скрыты через Pedersen-коммитменты.
• Адреса Spark не связываются даже для нод, выполняющих анализ цепочки.

Spark также включает:

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

Малоизвестный факт:
Дизайн Spark уменьшает поверхность атаки, создаваемую «partial spend proofs», которые ранее делали некоторые приватные протоколы связываемыми при определённых эвристиках.

7. Aleo — ZK-выполнение, а не только ZK-транзакции

Aleo — это не просто приватная монета, это блокчейн L1 с полностью приватными смарт-контрактами.

Как это работает:

• Программы пишутся на Leo, DSL наподобие Rust, компилируемый в R1CS.
• Исполнение происходит вне цепочки (off-chain).
• Генерируется zk-STARK доказательство, представляющее весь след выполнения.
• Майнеры/валидаторы проверяют доказательство и обновляют состояние.

Фактически это:

Глобальная, проверяемая, зашифрованная виртуальная машина.

Малоизвестный факт:
Aleo использует гибридную систему доказательств:

• STARK для прозрачности
• Рекурсия SNARK (стиль Kimchi/Halo) для уменьшения размера доказательства

Такой гибридный подход редок и технически сложен.

8. Почему ZKP сложно реализовать на уровне альткоинов

8.1 Стоимость доказательства

Генерация zk-SNARK доказательства требует:

• Миллионы арифметических ограничений
• FFT по большим конечным полям
• Многомасштабные умножения на эллиптических кривых

Даже с оптимизациями:

• Генерация доказательства может быть узким местом для CPU.
• Высокое потребление памяти (несколько сотен МБ на старых системах).

8.2 Проблемы с доверенной настройкой

Монеты, использующие Groth16, нуждаются в доверенной настройке.
Если токсичные отходы не уничтожены, атакующий может:
→ создать неограниченное количество фальшивых монет
без обнаружения.

Zcash на самом деле использовал многостороннюю церемонию; финальные токсичные отходы (по сообщениям) были уничтожены с помощью физической энтропии и строгого OPSEC…
Но одного нечестного участника хватило бы, чтобы скомпрометировать систему.

8.3 Ошибки в схемах могут уничтожить монету

Если схема приватной системы имеет невыявленную ошибку, позволяющую инфляцию, ноды не смогут обнаружить фальшивые монеты.
Это произошло в раннем Zcash (исправлено до эксплуатации).

Тонкая арифметическая ошибка в ограничениях может обанкротить всю экосистему.

9. Будущее ZK-монет

Технически вероятные направления:

• Рекурсивные доказательства, позволяющие пакетную проверку транзакций.
• Гибридные системы STARK–SNARK, как в Aleo, для уменьшения размера доказательства.
• Аппаратное ускорение через GPU и ASIC для генерации доказательств.
• Программируемая приватность, позволяющая избирательное раскрытие.
• Мобильные ZK-схемы (текущие схемы слишком тяжёлые).

Некоторые исследовательские эксперименты:

• ZK-зашифрованные mempool
• ZK P2P matching engines
• ZK DEX без раскрытия книги ордеров

Эти решения уже прототипируются в проектах, таких как Penumbra и Mina.

10. Реальные атаки и уязвимости ZK-приватных монет

Несмотря на то, что ZK-системы призваны гарантировать приватность и корректность, история показывает, что криптографическая сложность часто создаёт новые поверхности для атак.

Ниже перечислены самые важные реальные, задокументированные и часто недооценённые проблемы.

10.1 Уязвимость Zcash для поддельных монет (2018)

В цепи Zcash Sapling была обнаружена серьёзная уязвимость:

• Параметр внутри zk-SNARK схемы был неправильно ограничен.
• Это позволяло злоумышленнику создавать фальшивые shielded-коины.
• Эти монеты были невидимы, так как все защищённые значения скрыты.

Ключевые факты:

• Обнаружено криптографом Ариэлем Габизоном.
• Исправлено в Sapling до публичного использования.
• Zcash никогда не раскрывал, сколько (если вообще были) поддельных монет создано в пуле Sprout, так как математически невозможно это проверить.

Этот инцидент — самый наглядный пример:

Ошибки ZK-систем = катастрофическая, незаметная инфляция.

Он также стимулировал изменения в протоколе:

• Новые схемы (Sapling, Orchard)
• Более модульные системы ограничений
• Усиленное рецензирование перед развертыванием

10.2 Академическая атака на MimbleWimble (2019)

MimbleWimble (используемый Grin/Beam) не применяет zk-SNARK, а использует Pedersen-коммитменты + cut-through + отсутствие адресов.

Исследователь Иван Богатый показал:

• Мониторинг сети в реальном времени с ~200 нодами
• Можно связать 96% транзакций Grin с отправителями и получателями

Это не ошибка ZK-математики, а проблема:

• Модели агрегирования транзакций
• Отсутствия «маскирующих» входов
• Утечки метаданных на уровне сети

Важный урок:

Приватность — не только в доказательствах; утечки топологии сети могут деанонимизировать даже идеальную ZK-математику.

10.3 Тайминговые утечки в реализации доказателей

Некоторые реализации ZKP (особенно старые SNARK-схемы) раскрывают паттерны времени:

Пример:

• При доказательстве транзакции с множеством входов CPU или GPU дают заметные изменения времени выполнения
• Наблюдатель с доступом к ноде может оценить количество тратимых note, уменьшая размер приватного множества

Частично наблюдалось в ранних клиентах Zcash до оптимизации.

Причина:
SNARK-доказатели часто используют FFT и многомасштабные умножения, где структура, зависящая от входов, влияет на время выполнения.

10.4 Риски многокривых в гибридных системах

Проекты вроде Aleo используют:

• STARK → затем сжимают рекурсией SNARK (Kimchi/Halo/KZG полиномиальные коммитменты)

Редко обсуждаемый риск:
Если любая кривая или схема полиномиальных коммитментов в рекурсивной цепочке сломается,
вся система становится уязвимой.

Эта «многокривая хрупкость» почти никогда не упоминается в маркетинговых материалах.

11. Проектирование ZK-схемы приватной монеты (общий план)

Реальное техническое разъяснение того, как разработчики создают ZK-протокол приватности.

Шаг 1: Выбрать арифметическую модель

• R1CS (Zcash Sapling)
• PLONKish (Halo 2, Orchard)
• AIR/FRI (STARKs)

Каждая имеет свои компромиссы:

• R1CS → легко анализировать, тяжёлые ограничения.
• PLONK → гибкая, поддержка кастомных вентилей.
• STARK → нет доверенной настройки, но большие доказательства.

Шаг 2: Выбор конечного поля

Примеры:

• Скаляное поле BLS12-381 (255 бит) для SNARKs
• Поле Goldilocks (64-битное) для STARKs (Polygon Miden, RISC Zero)

Выбор поля напрямую влияет на:

• Размер схемы
• Аппаратное ускорение
• Скорость генерации доказательства

Шаг 3: Построение криптографических коммитментов

Типичная альткоин-схема использует:

• Pedersen-коммитменты для значений
• SHA-коммитменты для Merkle-путей
• Poseidon/Rescue-хэш внутри схем (FFT-дружественные)

Малоизвестная деталь:
Zcash отказался от SHA-256 внутри схем, так как SHA-256 чрезвычайно дорог в количестве ограничений — более 25 000 ограничений на один хэш.
Poseidon снижает это примерно до 150 ограничений.

Шаг 4: Реализация доказательства владения (авторизация трат)

Обычно включает:

• Проверку производных ключей
• Проверку знания приватного ключа
• Предотвращение повторных атак

Zcash использует RedJubjub, SNARK-дружественную схему подписи (EdDSA-стиль, оптимизированный для SNARK).

Шаг 5: Реализация логики nullifier

Nullifier = детерминированный уникальный тег для потраченной note.

ZK-схема должна гарантировать:

• Каждая note создаёт ровно один nullifier
• Nullifier не раскрывает идентичность note
• Nullifier не позволяет совершать множественные траты

Эта часть крайне подвержена ошибкам — и была причиной крупнейшей ошибки Zcash.

Шаг 6: Построение балансового уравнения

Доказать:
inputs_commitments_sum = outputs_commitments_sum

Плюс range proofs:

• Значения ≥ 0
• Значения < 2⁶⁴

В современных системах ограничения диапазона используют:

• PLONK lookup arguments
• Bulletproofs внутри схем
• Кастомные вентильные схемы

Шаг 7: Финальная агрегация и генерация доказательства

Пример SNARK:

• Компиляция схемы → QAP-полином
• FFT для оценки полиномов
• Многомасштабные умножения
• Вывод доказательства
• Ноды/верификаторы проверяют на цепочке за миллисекунды

Пример STARK:

• Построение execution trace
• Применение FRI-коммитментов
• Вывод большого, но прозрачного доказательства
• Проверка через хэш-функции

12. Аппаратное ускорение ZK (игровой фактор)

Большинство пользователей не осознают, что доказательства ZKP постепенно превращаются в гонку аппаратного обеспечения:

Доказательства на GPU

• Операции FFT и MSM отлично подходят для GPU.
• В тестнете Aleo более 50% пропускной способности доказательств обеспечивалось на потребительских GPU (серия RTX).

Доказательства на ASIC

Несколько компаний (Ingonyama, Cysic) разрабатывают ASIC для ZKP:

• MSM-блоки
• Вычисления полиномов
• Вычисления Merkle-путей

Статистически значимый факт:

• Специализированный ASIC-доказатель может генерировать SNARK-доказательства в 20–50 раз быстрее CPU.

Это значит, что будущее приватных монет может сильно зависеть от специализированного аппаратного экосистемы, аналогично майнингу Биткоина.

13. Проблема прозрачного аудита в ZK-монетах

Приватные монеты сталкиваются с парадоксом:

1. Пользователи хотят приватность.
2. Разработчики должны гарантировать отсутствие инфляции и скрытых уязвимостей.
3. ZK скрывает всё.

Существуют несколько методов решения:

13.1 Viewing Keys (Zcash, Aztec)

Позволяют аудиторам проверять конкретные аккаунты без раскрытия остальных.

13.2 Аудит эмиссии

• Zcash может аудитировать прозрачный пул.
• Shielded-пул нельзя проверить напрямую.
• Разработчики полагаются на корректность схем для гарантии отсутствия инфляции.

Поэтому ошибки ZK-протоколов являются экзистенциальной угрозой.

14. Редкие, но важные криптографические факты

14.1 Первые ZKP использовали интерактивные протоколы

Современные SNARKs неинтерактивны (через эвристику Fiat–Shamir).
Но первые ZKP требовали много раундов общения.

14.2 Fiat–Shamir не гарантированно безопасен

Если используемая хэш-функция сломана или изменяемая,
корректность доказательств может разрушиться.

Это касается всех приватных монет на SNARK.

14.3 STARK основаны исключительно на хэш-функциях

Это означает:

• Они считаются постквантово безопасными.
• Безопасность зависит только от устойчивости к коллизиям хэша (например, Rescue, Poseidon).

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

Halo 2 (используемый в Zcash Orchard) позволяет:

• Доказательства, проверяющие другие доказательства
• Бесконечную рекурсию
• Без доверенной настройки

Это устраняет многие предыдущие ограничения SNARK-систем.

15. Таблица сравнения: ZK-системы в основных приватных альткоинах

Monero включён только для сравнения — оно не использует доказательства с нулевым разглашением, что удивляет многих новичков.

16. Реальные компромиссы использования ZKP в приватных монетах

Преимущества

• Максимальная приватность с математической гарантией.
• Возможность скрывать отправителя, получателя и сумму одновременно.
• Доказательства могут проверять любые участники сети.

Недостатки

• Высокая вычислительная нагрузка.
• Риски из-за ошибок в схемах (инфляция).
• Более крупные транзакции (кроме Groth16).
• Сложнее интегрировать в лёгкие кошельки.
• Более сложная криптография → меньше экспертов понимают её → медленнее аудит.

Редко упоминаемая проблема:

ZK-системы увеличивают утечки детерминизма кошелька:
шаблоны доказательств могут раскрывать аппаратное обеспечение кошелька, тип CPU/GPU или даже ОС, предоставляя метаданные для служб слежения за цепочкой.

17. Куда будет развиваться ZK-приватность в ближайшие 5 лет

Наиболее вероятные направления:

17.1 Универсальные уровни приватности

Вместо внедрения приватности в L1:

• Сети вроде Aztec, Penumbra и RAILGUN стремятся обеспечить приватность для существующих цепочек.
• Это позволяет избежать фрагментации между альткоинами.

17.2 ZK-сопроцессоры

Вспомогательные устройства, выполняющие все вычисления SNARK/STARK для кошельков или нод.

17.3 Адаптивная приватность (выбор пользователя)

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

• Суммы
• Отправителя
• Получателя
• Поля заметок (Memo)

Только при юридической или коммерческой необходимости.

17.4 Полностью приватные экосистемы смарт-контрактов

Aleo, Aztec 3 и Penumbra активно работают в этом направлении.

17.5 Стандарты токенов, совместимые с SNARK

Например, ZK-ERC20 с:

• Зашифрованными балансами
• ZK-доказательствами перевода
• Совместимостью с инструментами Ethereum

Это, вероятно, станет первым массовым внедрением ZK.

18. Заключительные мысли

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

математически доказуемую приватность в сочетании с математически доказуемой корректностью.

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