Защищённые пулы Zcash, Unified Address и ключи просмотра

Пул в Zcash — не биржа или компания, которая держит пользовательские депозиты, а состояние средств, подчинённое определённым правилам консенсуса. Прозрачный пул использует публичные UTXO. Читатель блокчейна может увидеть созданный output, последующую транзакцию, которая его потратила, и открытое значение. Адрес сам по себе не устанавливает юридическую личность, но публичная история показывает использование адресов и связи между переводами.

Защищённые пулы представляют средства в виде notes, а не открытых UTXO. Сеть записывает зашифрованные данные notes, деревья commitments и проверяет балансы пулов. Доказательства позволяют консенсусу проверять корректность, сохранение стоимости и защиту от двойной траты, не показывая обычному наблюдателю получателя и сумму так, как в прозрачном output. Спецификация протокола Zcash описывает обе модели.

Sapling и Orchard — отдельные защищённые пулы с разными протоколами и деревьями commitments; это не одно взаимозаменяемое состояние баланса. Sprout был первым защищённым протоколом Zcash. После активации ZIP 211 добавлять новую стоимость в пул Sprout больше нельзя, хотя прежние транзакции Sprout остаются в истории блокчейна.

Статус сети следует датировать. В официальном индексе ZIP последним завершённым обновлением Mainnet указан NU6.2: оно активировалось на блоке 3 364 600 3 июня 2026 года. NU6.2 вновь разрешило действия Orchard после временной меры по снижению риска уязвимости и с исправленными правилами circuit. NU6.3 и пул Ironwood пока остаются проектами, а не действующими правилами Mainnet. См. ZIP 257, индекс ZIP и черновик ZIP 258.

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

При трате note транзакция раскрывает связанный nullifier. Отправитель доказывает знание note и публикует nullifier, а сеть проверяет, что он не использовался раньше. Наблюдатели видят nullifier и дерево commitments, но не должны иметь возможности определить, какому прежнему commitment он соответствует. Это предотвращает двойную трату, не скрывая все данные консенсуса. Sapling и Orchard используют общую схему, но разные криптографические компоненты и доказательства; для траты требуется соответствующий закрытый ключ.

Unified Address (UA) — одна закодированная строка, которая может содержать receiver Orchard, Sapling, прозрачный P2SH и прозрачный P2PKH. Активный формат Revision 0 должен включать хотя бы один защищённый receiver. Строка намеренно непрозрачна: по внешнему виду нельзя понять, какие receiver в ней есть. ZIP 316 отличает активный Revision 0 от предлагаемого Revision 2.

Кошелёк отправителя не переводит средства на все receiver одновременно. В Revision 0 порядок предпочтения такой: Orchard, Sapling, прозрачный P2SH, затем прозрачный P2PKH. Отправитель должен выбрать receiver с наивысшим приоритетом среди поддерживаемых кошельком. Если кошелёк поддерживает Orchard, он выбирает его; если не поддерживает Orchard, но поддерживает Sapling, может выбрать Sapling. Поэтому фактический пул зависит от возможностей кошелька отправителя, а не только от показанной строки адреса.

В черновике Revision 2 предлагаются префикс zu для адресов только с защищёнными receiver и tu для форматов, где могут быть прозрачные receiver. Официальный индекс ZIP всё ещё помечает Revision 2 как проект; эти префиксы нельзя выдавать за обычный действующий формат UA в Mainnet. До отправки проверьте тип адреса, сеть и выбранный receiver в окне подтверждения кошелька.

Перевод из прозрачного пула в защищённый (t→z) может потратить публичные UTXO и создать notes Sapling или Orchard. Наблюдатель видит прозрачные входы, изменения в прозрачном пуле и чистую сумму, поступившую в защищённый пул. При этом он не видит обычный защищённый адрес получателя и каждую сумму note как прозрачный UTXO. Ввод средств в защищённый пул всё же оставляет информацию о пересечении границы.

При обратном переводе (z→t) адреса и суммы прозрачных outputs публичны, а соответствующее изменение стоимости в защищённом пуле может быть видно. Платёж, создающий notes в одном пуле, может скрывать получателя и сумму; переход между Sapling и Orchard может показывать изменение баланса каждого пула отдельно. Публичная сумма на границе сама по себе не называет человека или старую note, но её можно сопоставлять с суммами, временем и внешними записями.

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

ZIP 316 определяет viewing key как сведения, необходимые для просмотра платежей на адрес. Full Viewing Key (FVK) также может показывать данные о платежах с этого адреса. Из FVK можно получить Incoming Viewing Key (IVK), а из IVK — адрес. Unified Viewing Keys объединяют компоненты ключей просмотра для нескольких протоколов.

Одного viewing key недостаточно, чтобы подписать трату: для этого нужен отдельный spending key или система подписи. Но viewing key нельзя считать безобидной публичной информацией. Тип ключа и реализация кошелька определяют, какие транзакции он позволяет видеть; ключ уровня аккаунта может раскрыть больше, чем один адрес для получения. Перед передачей аудитору или сервису уточните область видимости, срок хранения, возможность удаления и связь с другими адресами.

Viewing key не удаляет уже публичные подсказки: прозрачные inputs и outputs, суммы и время можно анализировать и без него. И наоборот, обозреватель или кошелёк без нужной поддержки может не показать защищённую транзакцию, которую блокчейн записал. «Приложение её не показывает» не означает «в блокчейне её нет».

Видимость зависит от пула и типа receiver. Полностью прозрачный поток показывает адреса, суммы и связи UTXO. Защищённый платёж шифрует получателей и суммы notes, но commitments, nullifiers, время и данные протокола остаются в блокчейне. Отдельные подсказки могут оставлять переходы между пулами, поддержка конкретных пулов, известное время платежа, записи биржи и общие viewing keys.

Unified Address не заставляет каждый платёж использовать Orchard. Выбранный receiver зависит от версии кошелька, настроек, реализации и пути транзакции. Проверяйте экран подтверждения или итог транзакции, а не делайте выводы о приватности лишь по вставленному адресу. [Руководство по приватности Monero](/ru/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) описывает другой подход, а [руководство по повторному использованию адресов Bitcoin](/ru/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained) сравнивает его с прозрачным реестром.

Сетевая приватность — отдельный уровень. RPC-провайдер, сервер лёгкого кошелька, биржа или платёжный сервис могут видеть запросы на создание или передачу транзакции и хранить IP-адрес, аккаунт или время вне блокчейна. Криптографические доказательства сами по себе не стирают журналы таких сервисов. Вместо абсолютных обещаний анонимности выясните, кто получил метаданные и как их хранит.

Сначала убедитесь, что кошелёк подключён к нужной сети Mainnet или Testnet. Перед отправкой проверьте, что получатель дал Unified Address, и посмотрите, какой receiver выбрал кошелёк. По строке UA нельзя определить её состав визуально, поэтому изучите в кошельке пул, сумму, memo и комиссию. Если получатель просит защищённый платёж, а окно подтверждения показывает прозрачный output, проверьте поддержку протокола в обоих кошельках до отправки.

Чтобы проверить существующую транзакцию, сопоставьте её идентификатор и сеть, затем посмотрите, какие пулы участвуют во входах и выходах. Прозрачные адреса и суммы видны в публичных обозревателях; детали notes могут не отображаться в инструменте без их поддержки. Если нужен viewing key, определите зачем и какие данные он раскрывает; не вставляйте spending key или viewing key на неизвестный сайт. В руководстве по кастодиальным и некастодиальным кошелькам также объясняется ответственность за подпись.

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

Предположим, Lee отправляет 1,25 ZEC с прозрачного UTXO на Unified Address Revision 0, содержащий receiver Orchard, Sapling и прозрачный receiver. Сумма приведена для примера и не задаёт комиссию или настройку по умолчанию. Если кошелёк Lee поддерживает Orchard, правило ZIP 316 предписывает выбрать receiver Orchard. В блокчейне видны прозрачный input и сведения о границе, например чистая стоимость, поступившая в защищённый пул, но не обычный публичный output с защищённым адресом получателя и суммой note.

Если кошелёк Lee не поддерживает Orchard, но поддерживает Sapling, он может выбрать Sapling. Кошелёк без поддержки защищённых пулов может использовать прозрачный receiver, если он доступен в адресе и формате платежа. UA Revision 0 должна содержать защищённый receiver, но отправитель выбирает только тот, который поддерживает его кошелёк. Поэтому одна и та же UA в кошельках с разными возможностями может привести к разным пулам и публичным данным на границе.

Наконец, если получатель отдельно передаёт viewing key бухгалтерскому сервису, сервис может увидеть защищённую активность в пределах ключа. Получение в кошельке, отсутствие данных note в обозревателе и запись транзакции согласно консенсусу — три разных факта. Unified Address упрощает совместимость между поколениями протоколов, но не гарантирует полную приватность и не отменяет выбор receiver, управление ключами или защиту сетевых метаданных.

• Спецификация протокола Zcash v2026.7.0 (NU6.2)
• ZIP 316: Unified Addresses и Unified Viewing Keys
• ZIP 211: запрет добавления новой стоимости в пул Sprout
• ZIP 257: NU6.2 и временная мера для Orchard
• ZIP 258: проект обновления NU6.3
• Официальный индекс ZIP: статус Mainnet и предложений