Криптографические протоколы конфиденциальности: сравнительный тест четырех алгоритмов защищенных транзакций

Конфиденциальность отвечает на другой вопрос: какие сведения видны постороннему и что он может вывести из них. Смешение этих свойств особенно заметно в обсуждениях zk-rollup: validity proof может подтверждать корректность обновления состояния, оставляя сами входные данные открытыми.

Сравнивать Zcash Orchard, Monero RingCT, Grin и Aztec по единой шкале приватности поэтому бессмысленно без определения метрики. Здесь различаются и сами объекты сокрытия, и криптографические конструкции, и остаточные метаданные. Практичнее разобрать четыре оси: что скрывает каждый подход, как именно это делает, что публикуется в блокчейне и какие риски остаются за пределами криптографии.

Архитектура сокрытия данных в Zcash Orchard и система Halo 2

Orchard представляет собой shielded pool Zcash, построенный на модели записок, или notes. Транзакции, содержащие действия Orchard, используют структуру Action: действие может включать расходование существующей записки, создание новой или оба элемента. Для проверки корректности этих операций применяется система доказательств Halo 2.

Важное свойство Halo 2 состоит в том, что для неё не требуется trusted setup в том смысле, в каком он был необходим ранним конструкциям Zcash. Это устраняет зависимость от церемонии генерации параметров, компрометация которой могла бы поставить под угрозу корректность доказательств. У такого решения есть собственная цена: доказательства и их проверка имеют вычислительный и размерный оверхед. Поэтому сравнивать Halo 2 с другой системой только по факту отсутствия trusted setup недостаточно. Для практической оценки нужны замеры на сопоставимых версиях клиентов и одинаковом оборудовании.

Записка Orchard содержит данные о получателе и сумме, но её содержимое передаётся в зашифрованном виде. В публичной части цепочки остаются commitment к записке и nullifier, связанный с её расходованием. Commitment позволяет протоколу учитывать новые выходы, не раскрывая их содержимого. Nullifier предотвращает повторное расходование, не публикуя напрямую исходную записку. Эти значения нужны для работы протокола, но сами по себе не являются открытым списком получателей и сумм.

Для поля memo в Zcash задан размер 512 байт. Это ограничение важно при проектировании кошельков и приложений: протокольное поле не является каналом для произвольного объёма данных. Если сервис предлагает хранить дополнительную информацию сверх возможностей memo, нужно отдельно выяснить, где именно она размещается и кто может её прочитать.

Что видно наблюдателю? Комиссия транзакции не скрыта. При использовании прозрачной части протокола её признаки также остаются наблюдаемыми. Внутри Action могут быть представлены расходование и создание записок; сами действия и соответствующие публичные элементы не следует путать с раскрытием сумм и адресов shielded pool. Время блока связано с заголовком блока, а не является полем Action. Для анализа временных корреляций это различие не отменяет значения времени включения транзакции, но важно не приписывать его структуре самой транзакции.

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

Halo 2 помогает проверять корректность операций с shielded-записками без trusted setup. Видимость публичных элементов транзакции и сетевые метаданные остаются отдельными вопросами.

Механика кольцевых подписей RingCT в Monero и открытые параметры комиссий

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

Сумма скрывается с помощью обязательств и доказательств диапазона. Обязательство позволяет проверить согласованность сумм, не раскрывая само значение. Range proof подтверждает, что скрытая сумма попадает в допустимый диапазон. Без такой проверки можно было бы создавать выходы с недопустимыми значениями, сохраняя видимость того, что отдельные суммы зашифрованы.

Эти механизмы не превращают всю транзакцию в закрытый объект. Комиссия публикуется открыто. Наблюдатель также видит структуру кольца и другие данные транзакции, которые задаются правилами сети. Размер кольца не сообщает напрямую, кто был реальным отправителем, однако остаётся частью публичной структуры и участвует в анализе вместе с другими признаками. Дополнительные поля транзакции могут быть доступны в блокчейне; версию клиентского программного обеспечения к таким полям относить нельзя. Клиентская версия и версия транзакции являются разными вещами.

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

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

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

Mimblewimble и Bulletproofs: балансировка обязательств в Grin без адресов

Mimblewimble меняет привычное представление о транзакции как о записи с адресами отправителя и получателя. В Grin on-chain адресов нет. Стороны взаимодействуют при построении транзакции вне цепочки, а данные, необходимые для её проверки, затем включаются в блокчейн. Это сокращает объём традиционной адресной информации, но не гарантирует, что участники останутся неузнаваемыми при любом сценарии наблюдения.

Обязательство к выходу в Grin связывает скрытую сумму с blinding factor, то есть с ослепляющим множителем. Оно не кодирует псевдонимы отправителя и получателя. Его назначение состоит в том, чтобы скрыть сумму, сохраняя возможность проверить баланс транзакции. Такое уточнение принципиально: отсутствие адресов связано с архитектурой Mimblewimble, а обязательство решает задачу сокрытия значений и проверки арифметики.

Баланс нельзя описать простым равенством сумм обязательств на входах и выходах. В проверке участвуют также excess и blinding factors. Упрощённо, обязательства входов и выходов сводятся с учётом комиссии и ослепляющих множителей, а excess позволяет проверить, что у участников есть необходимые секретные значения и что баланс соблюдён. Именно эта связь делает возможной проверку без раскрытия сумм. Если убрать из описания excess и blinding factors, получится наглядная, но неполная формула, которая искажает устройство проверки.

К каждому выходу добавляется range proof. Он подтверждает, что скрытое значение находится в допустимом диапазоне от 0 до 2⁶⁴−1, не показывая само значение. В Grin для этого применяются Bulletproofs. Они не требуют trusted setup. Указанные в документации пять раундов относятся к построению доказательства, а не к интерактивному обмену сообщениями между сторонами транзакции. Поэтому их нельзя трактовать как пять раундов взаимодействия участников.

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

У Grin нет публичных адресов в обычном смысле, но остаются другие источники корреляции. Наблюдатель может анализировать структуру транзакций и обязательств, сопоставлять время их появления в сети и использовать информацию, полученную за пределами блокчейна. Сведение транзакций и компактность графа не устраняют автоматически сетевые метаданные и не дают универсальной защиты от анализа поведения участников.

В Grin обязательство скрывает сумму, а отсутствие on-chain адресов задаётся устройством Mimblewimble. Это разные свойства; ни одно из них само по себе не закрывает сетевые метаданные.

Сравнение validity proof и конфиденциальности на примере zk-rollup и Aztec

Validity proof подтверждает, что переход состояния соответствует правилам системы. Само по себе такое доказательство не шифрует данные, которые передаются для обработки. Если входы и состояние доступны наблюдателю, наличие доказательства корректности не делает их приватными. Для сокрытия информации нужны отдельные механизмы: шифрование состояния, правила доступа и архитектура, которая не публикует чувствительные данные в открытом виде.

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

Сравнение Aztec с Orchard поэтому полезно вести на уровне архитектуры, а не сводить к вопросу, какая система «приватнее». Orchard является частью протокола Zcash с заданной моделью shielded-записок. Aztec работает как L2 поверх Ethereum и связан с собственной моделью исполнения, sequencer и prover. На уровне приложения в Aztec разработчику нужно определить, какие данные относятся к приватному состоянию и как они участвуют в переходах. В Orchard разработчики кошельков используют заданную протоколом модель, не подменяя её собственной схемой.

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

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

Модели угроз и анализ сетевых метаданных при выборе систем защиты

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

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

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

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

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

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

Инженерный вердикт

Orchard строит приватность вокруг shielded-записок и проверок Halo 2. RingCT скрывает суммы и усложняет установление реального источника среди участников кольца, сохраняя публичной комиссию и часть структуры транзакции. Mimblewimble в Grin отказывается от on-chain адресов, а обязательства и Bulletproofs позволяют проверять баланс и диапазон значений без раскрытия сумм. Aztec показывает, как приватное состояние может сосуществовать с validity proof в L2, но это требует отдельной архитектуры и решений на уровне приложений.

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

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