Księga Solany może teraz ukryć, ile środków przepłynęło między dwiema stronami — ale nie to, kim są te strony. To podstawowy kompromis systemu Privacy Rings, rozwiązania poufnych transferów, które dostawca infrastruktury Solany, Helius, ogłosił 10 listopada w poście premierowym.

Domyślny Ring, dostępny bez uprawnień, działa jako chroniona pula: zaszyfrowane salda istnieją na własnej księdze Solany, transfery rozliczane są w zwykłych transakcjach Solany, a każdy ruch weryfikują dowody zero-knowledge. Trzy produkty już go przyjęły — Decrypt, który wykorzystuje poufne transfery w swoim koncie pieniężnym; aplikacja do miningu i stakingu Ore; oraz Aurora Intents, która dostarcza aktywa z innych łańcuchów bezpośrednio do poufnego salda.

Dla portfeli, które nigdy nie zdecydują się na włączenie, nic się nie zmienia. Istniejący adres Solany zachowuje swoją publiczną historię, a prywatność zaczyna się dopiero wtedy, gdy środki zostaną przeniesione do poufnego salda — i nawet wtedy tylko dla pól, które Ring ma szyfrować. To, które pola są szyfrowane i kto nadal może je odczytać, decyduje o tym, jaką faktyczną ochronę zapewnia system.

Płatności do nieprzygotowanych odbiorców trafiają na publiczną ścieżkę

Szczegół, który najbardziej może zaskoczyć dział kadr lub skarbca, pojawia się w FAQ produktu Heliusa: gdy odbiorca płatności nie ma prywatnego portfela (Private Wallet), Privacy API zamienia płatność w wypłatę na publiczny adres odbiorcy. Pieniądze docierają, ale drogą publiczną, gdzie aktywo i kwota są widoczne dla każdego.

Przewodnik po transferach Heliusa wyjaśnia, dlaczego ten mechanizm zastępczy istnieje. Prywatny transfer jest adresowany do chronionego adresu — zestawu kluczy podpisywania, nullifiera i podglądu, który odbiorca publikuje w rejestrze — a zaszyfrowany wynik jest zablokowany do klucza podglądu tego odbiorcy. Kto nigdy takiego adresu nie zarejestrował, nie ma poufnego salda, na którym środki mogłyby wylądować. Strona startowa Heliusa mówi prawdę, gdy informuje, że odbiorcy nie potrzebują specjalnego portfela, aby otrzymać środki; od konfiguracji zależy poufność otrzymania, a nie sam fakt otrzymania.

Dla aplikacji oznacza to, że status odbiorcy staje się częścią ekranu płatności. Nadawca, który widzi znajomy adres Solany i zakłada, że kwota zostanie zaszyfrowana, może zatwierdzać transfer publiczny. Rozsądne jest pokazanie, która ścieżka zostanie wykonana, zanim zostanie poproszony o podpis, i uczynienie ścieżki publicznej jawnym wyborem, a nie cichym domyślnym ustawieniem. Helius właśnie z tego powodu buduje wbudowany prywatny portfel obsługujący oba typy sald i podaje, że Backpack, Squads, Jupiter, DFlow i Titan to zespoły pracujące nad integracjami. Dopóki portfel odbiorcy nie obsługuje prywatnego otrzymywania środków, ścieżką zastępczą będzie trasa ich płatności — co czyni wdrożenie tych integracji praktyczną bramą dla tego, jak duża część przepływu płatności może pozostać na zaszyfrowanej trasie.

Co łańcuch nadal pokazuje na prywatnej trasie

Nawet gdy obie strony są w pełni skonfigurowane, domyślny Ring jest poufny, a nie anonimowy. Przewodniki Heliusa opisują widoczność każdego kroku, a wzór jest taki, jakiego oczekiwałby analityk łańcucha: końce podróży są publiczne, środek zaszyfrowany.

• Wpłata — publiczne: adres wpłacający, aktywo, kwota; zaszyfrowane: powstałe saldo poufne.
• Transfer prywatny — publiczne: adresy nadawcy i odbiorcy, płatnik opłat; zaszyfrowane: aktywo, kwota, opcjonalna nota.
• Wypłata — publiczne: adres wypłacający, miejsce docelowe, aktywo, kwota; zaszyfrowane: pozostałe saldo poufne.

Podział opiera się na przewodnikach Heliusa dotyczących wpłat, transferów i wypłat dla domyślnego Ringa i obejmuje wyłącznie bezpośrednią widoczność w łańcuchu; wnioskowanie z innych zapisów to osobna kwestia.

Rozważmy firmę, która finansuje wynagrodzenia z portfela skarbowego już powiązanego z jej nazwą. Przeniesienie 30 000 USDC do salda poufnego ujawnia tę kwotę przy wpłacie. Kolejne transfery wynagrodzeń ukrywają każdą kwotę, więc nikt nie może odczytać z księgi indywidualnej wypłaty. To, co mogą odczytać, to kształt: znany firmowy adres płacący tym samym kilkunastu adresom tego samego dnia każdego miesiąca. Jeśli którykolwiek z tych odbiorców był kiedykolwiek powiązany z osobą fizyczną, zaszyfrowana kwota jest jedynym, co stoi między tym wzorcem a oszacowaniem wynagrodzenia — a oszacowanie zawęża się w momencie, gdy pracownik wypłaca środki na saldo publiczne, bo kwota wypłaty jest widoczna. Powtarzający się odbiorca może być dostawcą, więc łańcuch nigdy nie dowodzi zatrudnienia, ale zawężanie możliwości to dokładnie to, co sprzedają firmy analityczne. Coindoo prześledził ten sam ślad tożsamości w swoim opracowaniu podejścia COTI do prywatnych płatności.

Dwa mniejsze szczegóły dopełniają obrazu. Płatnikiem opłat w prywatnym transferze jest publiczny adres Solany, a Helius pozwala sponsorowi pokryć te opłaty — co oznacza, że firma sponsorująca opłaty dla pracowników podpisuje każdą transakcję swoją nazwą, nawet gdy nie jest nadawcą. Pole noty, jeśli jest używane, jest szyfrowane razem z kwotą, więc referencja faktury podróżuje prywatnie, podczas gdy dwa adresy, które ją wymieniają, już nie.

Kto może odczytać kwotę oprócz łańcucha

Zaszyfrowanie pola w łańcuchu rozstrzyga, co widzi publiczność. Nie mówi nic o tym, kogo użytkownik wpuścił do środka. Dokumentacja szyfrowania Heliusa dzieli to pytanie na warstwy, a warstwą, którą firmy faktycznie negocjują, jest środkowa: dostęp delegowany.

• Kontrahent — widzi transakcję, w której brał udział; otrzymanie płatności nie otwiera niczego innego w portfelu nadawcy.
• Delegowany klucz podglądu — autoryzowany przez użytkownika dostawca może odczytywać salda i historię, ale nie może przenosić środków.
• Klucz podglądu transakcji — ujawnia wyłącznie jedną transakcję, na przykład fakturę dla audytora bez reszty księgi.
• Dostawca rampy — fiatowa brama wpłat lub wypłat utrzymuje zaszyfrowaną stronę łańcuchową, ale obsługuje stronę bankową i zna jej szczegóły.

Domyślnie klucz podglądu pozostaje na urządzeniu użytkownika, a deszyfrowanie odbywa się lokalnie; Helius generuje dowody i przekazuje transakcje, ale nigdy nie przechowuje kluczy. Delegacja to moment, w którym księgowy firmy, oprogramowanie skarbcowe lub usługa uzgadniania otrzymuje kopię tego klucza. Praktyczną konsekwencją jest czystszy podział niż ten, jaki większość działów finansowych dostaje od banku: księgowa może otrzymać pełny dostęp do odczytu poufnej księgi bez możliwości zatwierdzania płatności, a kontrahentowi można pokazać pojedynczy jej wiersz. Druga strona medalu: każda delegacja to trwałe ujawnienie informacji, więc firma, która przekazuje klucze podglądu kilku dostawcom, po cichu odtworzyła publiczność, którą próbowała zmniejszyć.

Czym to się różni od istniejących poufnych transferów Solany

Solana już oferuje ukrywanie kwot za pomocą rozszerzenia confidential transfer w Token Extensions, więc pytanie, co dodają Rings, jest zasadne. Rozszerzenie działa per token: emitent włącza je na mincie, a posiadacze tego minta mogą chronić salda i przenosić kwoty, podczas gdy sam token i kontrahenci pozostają widoczni. Rings działają jako pula przyjmująca aktywa SOL, SPL i Token-2022 bez udziału emitenta, szyfrują aktywo wraz z kwotą i udostępniają salda poufne innym programom poprzez wywołania międzyprogramowe — mechanizm, który Helius proponuje do prywatnych escrow, swapów i zabezpieczeń. Oba podejścia pozostawiają oba adresy na widoku; Rings poszerzają to, co znajduje się między nimi.

Custom Rings i audyty

Anonimowość na poziomie adresów jest w planach, nie w sieci głównej. Dokumentacja Custom Rings Heliusa opisuje Ringi prowadzone przez instytucje, które można skonfigurować jako poufne — jak domyślny — lub anonimowe, z zaszyfrowanym nadawcą i odbiorcą oraz transferami przesyłanymi przez relayera. Każdy z nich dodaje klucz audytora z dostępem do odczytu zgodnie z polityką ustaloną przez instytucję, a także listy dozwolonych i zablokowanych w łańcuchu, zamrożenia i dodatkowe wymagania podpisów. Transfery między Ringami podlegają zasadom Ringa źródłowego i mogą łączyć saldo domyślnego Ringa z jednym Custom Ringiem w pojedynczej transakcji. Helius wskazuje docelową premierę w sieci głównej na czwarty kwartał 2026 roku, przy trwających audytach.

Działający domyślny Ring przeszedł trzy niezależne audyty — Certora, ZK Security i OtterSec — a zaufana inicjalizacja jego obwodów została przeprowadzona przez inżynierów z Solana Foundation, Blueshift, Zcash, Certora, OtterSec i ZK Security. Konfiguracje wielostronne tego typu to standardowe zabezpieczenie w systemach zero-knowledge — parametry są generowane wspólnie, więc żaden pojedynczy uczestnik nie posiada wszystkiego, co potrzebnego do samodzielnego sfałszowania dowodów — a obecność Zcash na liście jest godna uwagi, ponieważ ten projekt był pionierem chronionych pul na publicznym łańcuchu bloków. Weryfikacja formalna programów i obwodów trwa, a Helius oczekuje jej zakończenia do końca 2026 roku. Wraz z celem Custom Rings na czwarty kwartał 2026 roku czyni to rok 2026 rokiem dwóch pozostałych kamieni milowych mapy drogowej: anonimowości na poziomie adresów i weryfikacji formalnej.

Trzy pytania przed podpisaniem

Płatność Privacy Rings jest prywatna dokładnie w trzech wymiarach, a nadawca kontroluje tylko jeden z nich. Tym, którą ścieżką podąża płatność, decyduje portfel odbiorcy. Tym, które adresy się pojawiają, decyduje łańcuch. Tym, kto jeszcze może odszyfrować kwotę, decyduje nadawca — poprzez klucze, które zdecyduje się delegować.

Każda aplikacja zbudowana na Rings powinna odpowiadać na te trzy pytania na ekranie potwierdzenia: prywatna ścieżka czy publiczna wypłata, które pola pozostają widoczne i kto już posiada klucz podglądu. Ukrycie kwoty jest użyteczne. Dokładna wiedza o tym, co pozostaje widoczne, czyni to ukrycie wartym zaufania.