Реестр Solana теперь может скрывать, сколько денег переведено между двумя сторонами, — но не то, кто эти стороны. В этом состоит центральный компромисс Privacy Rings, системы конфиденциальных переводов, которую провайдер инфраструктуры Solana Helius представила 10 ноября в публикации о запуске.

Открывающая доступ всем Ring по умолчанию работает как экранированный пул: зашифрованные балансы хранятся в собственном реестре Solana, переводы рассчитываются обычными транзакциями Solana, и каждое движение проверяется доказательствами с нулевым разглашением. Три продукта уже используют систему — Decrypt, применяющий конфиденциальные переводы в своём денежном аккаунте; майнинговое и стейкинг-приложение Ore; и Aurora Intents, доставляющая активы из других сетей прямо в конфиденциальный баланс.

Для кошельков, которые не подключаются, ничего не меняется. Существующий адрес Solana сохраняет свою публичную историю, а приватность начинается только при перемещении средств в приватный баланс — и даже тогда лишь для полей, которые Ring предназначен шифровать. Именно то, какие это поля и кто всё ещё может их читать, определяет, сколько защиты система реально обеспечивает.

Платежи неподготовленным получателям идут по публичному маршруту

Деталь, которая вероятнее всего застанет врасплох команду по зарплате или казначейству, приведена в FAQ по продукту Helius: если получатель платежа не имеет Private Wallet, Privacy API превращает платёж в снятие средств на публичный адрес получателя. Деньги приходят, но по публичному маршруту, где актив и сумма видны любому.

Руководство по переводам Helius объясняет, почему существует этот резервный механизм. Приватный перевод адресуется на экранированный адрес — набор ключей подписи, nullifier и просмотра, который получатель публикует в реестровой записи, — а зашифрованный выход привязан к ключу просмотра этого получателя. У того, кто никогда не регистрировал такой адрес, нет приватного баланса, куда могли бы попасть средства. Лендинг Helius точен, когда говорит, что получателям не нужен специальный кошелёк для приёма средств; от настройки зависит приватность получения, а не само получение.

Для приложения это делает статус получателя частью экрана платежа. Отправитель, который видит знакомый адрес Solana и полагает, что сумма будет зашифрована, может одобрять публичный перевод. Разумный дизайн — показывать, какой маршрут будет исполнен до запроса подписи, и делать публичный маршрут явным выбором, а не молчаливым значением по умолчанию. Helius именно по этой причине строит встроенный приватный кошелёк с обоими типами балансов и сообщает, что Backpack, Squads, Jupiter, DFlow и Titan — среди команд, работающих над интеграциями. Пока кошелёк получателя не поддерживает приватное получение, резервный механизм остаётся маршрутом платежей — что делает развёртывание этих интеграций практическим ограничителем того, какая часть платёжного потока может оставаться на зашифрованном маршруте.

Что сеть всё ещё показывает на приватном маршруте

Даже когда обе стороны полностью настроены, Ring по умолчанию конфиденциален, но не анонимен. Руководства Helius описывают видимость каждого шага, и картина та же, чего ожидал бы аналитик блокчейна: концы пути публичны, середина зашифрована.

• Депозит — публично: адрес внесения, актив, сумма; зашифровано: образующийся приватный баланс.
• Приватный перевод — публично: адреса отправителя и получателя, плательщик комиссии; зашифровано: актив, сумма, опциональная memo.
• Снятие средств — публично: адрес снятия, назначение, актив, сумма; зашифровано: остаток приватного баланса.

Разбор опирается на руководства Helius по депозитам, переводам и снятию средств для Ring по умолчанию и охватывает только прямую видимость в сети; выводы из других записей — отдельный вопрос.

Возьмём компанию, которая выплачивает зарплату с казначейского кошелька, уже связанного с её именем. Перевод 30 000 USDC в приватный баланс публикует эту цифру на депозите. Последующие зарплатные переводы скрывают каждую сумму, поэтому никто не может прочитать с реестра размер отдельной выплаты. Что можно прочитать — так это форму: известный корпоративный адрес платит той же дюжине адресов в один и тот же день каждого месяца. Если любого из этих получателей когда-либо связывали с человеком, зашифрованная сумма — единственное, что стоит между этим паттерном и оценкой зарплаты, — и оценка уточняется в момент, когда сотрудник выводит средства на публичный баланс, потому что снятая сумма видна. Регулярный получатель с равным успехом может быть поставщиком, так что сеть никогда не доказывает трудоустройство, но сужение возможностей — именно то, что продают аналитические фирмы. Coindoo прослеживала ту же цепочку идентификации в своём материале о подходе COTI к приватным платежам.

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

Кто может читать сумму, кроме сети

Шифрование поля в сети решает, что видит публика. Оно ничего не говорит о том, кого допустил пользователь. Документация по шифрованию Helius разделяет вопрос на уровни, и уровень, о котором реально договаривается бизнес, — средний: делегированный доступ.

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

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

Чем это отличается от существующих конфиденциальных переводов Solana

Solana уже предлагает скрытие сумм через расширение confidential transfer в Token Extensions, поэтому вопрос о том, что добавляют Rings, справедлив. Расширение работает на уровне токена: эмитент включает его на mint, и держатели этого mint могут экранировать балансы и переводить суммы, тогда как сам токен и контрагенты остаются видимыми. Rings работают как пул, принимающий активы SOL, SPL и Token-2022 без участия эмитента, шифруют актив так же, как сумму, и открывают приватные балансы другим программам через cross-program invocations — механизм, который Helius предлагает для приватных эскроу, свопов и обеспечения. Оба подхода оставляют два адреса на виду; Rings расширяют то, что находится между ними.

Custom Rings и аудиты

Анонимность на уровне адресов есть в дорожной карте, но не в основной сети. Документация Helius по Custom Rings описывает институтские Ring, которые можно настроить как конфиденциальные, как по умолчанию, или анонимные — с шифрованием отправителя и получателя и подачей переводов через ретранслятор. Каждый добавляет ключ аудитора с доступом на чтение в рамках политики, установленной институтом, плюс ончейн-белые и чёрные списки, заморозки и дополнительные требования к подписям. Переводы между Ring следуют правилам исходного Ring и могут объединять баланс Ring по умолчанию с одним Custom Ring в одной транзакции. Helius называет целевым сроком запуска в основной сети четвёртый квартал 2026 года, аудиты ещё продолжаются.

Действующий Ring по умолчанию прошёл три независимых аудита — Certora, ZK Security и OtterSec, а доверенная настройка его схем была выполнена инженерами из Solana Foundation, Blueshift, Zcash, Certora, OtterSec и ZK Security. Многосторонние настройки такого рода — стандартная защита в системах с нулевым разглашением: параметры генерируются совместно, поэтому ни один участник в одиночку не владеет достаточным для подделки доказательств, — а присутствие Zcash в списке показательно, поскольку этот проект первым создал экранированные пулы в публичном блокчейне. Формальная верификация программ и схем идёт, и Helius ожидает её завершения к концу 2026 года. Вместе с целью Custom Rings в четвёртом квартале 2026 года это делает 2026 год годом двух оставшихся вех дорожной карты: анонимности на уровне адресов и формальной верификации.

Три вопроса перед подписанием

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

Любое приложение на Rings должно отвечать на эти три вопроса на экране подтверждения: приватный маршрут или публичное снятие, какие поля остаются видимыми и у кого уже есть ключ просмотра. Скрыть сумму полезно. Точное знание того, что остаётся видимым, — то, что делает скрытие заслуживающим доверия.