Shielded pools, Unified Address i viewing keys w Zcash

Pool w Zcash nie jest giełdą ani firmą przechowującą depozyty, lecz stanem wartości objętym określonymi regułami konsensusu. Transparent pool używa publicznych UTXO. Każdy może sprawdzić w łańcuchu, jaki output utworzono, która późniejsza transakcja go wydała i jaka kwota jest widoczna. Sam adres nie ujawnia tożsamości prawnej, ale publiczna historia pokazuje użycie adresów i przepływy.

Shielded pools przedstawiają wartość jako notatki, a nie widoczne UTXO. Łańcuch zapisuje zaszyfrowane dane notatek, drzewa commitmentów i kontrole sald pooli. Dowody pozwalają konsensusowi sprawdzić poprawność, zachowanie wartości i ochronę przed podwójnym wydaniem, bez ujawniania zwykłemu obserwatorowi odbiorcy i kwoty tak jak przy transparent output. Specyfikacja protokołu Zcash opisuje oba modele.

Sapling i Orchard to osobne shielded pools z odrębnymi protokołami i drzewami commitmentów; ich stanów nie można traktować jak jednego zamiennego salda. Sprout był pierwszym shielded protokołem Zcash. Po aktywacji ZIP 211 nie można już dodawać nowej wartości do pool Sprout, chociaż starsze transakcje Sprout pozostają w historii łańcucha.

Status sieci należy opatrzyć datą. Oficjalny indeks ZIP wskazuje NU6.2 jako ostatnią zakończoną aktualizację Mainnet, aktywowaną na bloku 3 364 600 dnia 3 czerwca 2026 r. NU6.2 ponownie włączyło działania Orchard po tymczasowym ograniczeniu podatności i z poprawionymi regułami obwodów. NU6.3 i pool Ironwood nadal są projektami; nie opisuj ich jako obecnych reguł Mainnet. Zobacz ZIP 257, indeks ZIP i projekt ZIP 258.

Shielded note łączy wartość w danym poolu z uprawnieniem odbiorcy do jej wydania. Wartość, dane odbiorcy i memo są szyfrowane, aby portfel z odpowiednimi informacjami odbiorczymi mógł je odszyfrować. Łańcuch przechowuje zaszyfrowane dane i commitment notatki, a nie jej tekst jawny. Commitment pozwala przeprowadzać kontrole bez publikowania treści.

Przy wydawaniu notatki transakcja ujawnia powiązany nullifier. Wydający dowodzi, że zna notatkę, i publikuje nullifier; sieć sprawdza, czy nie został użyty wcześniej. Obserwatorzy widzą nullifier oraz drzewo commitmentów, lecz nie powinni móc wskazać commitmentu, do którego nullifier należy. Zapobiega to podwójnemu wydaniu, ale nie ukrywa wszystkich danych konsensusu. Sapling i Orchard stosują tę ogólną konstrukcję z innymi elementami kryptografii i dowodami; wydanie wymaga właściwego klucza prywatnego.

Unified Address (UA) to jeden zakodowany ciąg, który może zawierać receivery Orchard, Sapling, transparentne P2SH i transparentne P2PKH. Aktywny format Revision 0 musi zawierać co najmniej jeden shielded receiver. Ciąg jest celowo nieczytelny dla człowieka: nie da się wzrokowo ustalić, które receivery zawiera. ZIP 316 odróżnia Revision 0 od proponowanego formatu Revision 2.

Portfel nadawcy nie płaci do wszystkich receiverów. W Revision 0 kolejność preferencji to Orchard, Sapling, transparentne P2SH, a potem transparentne P2PKH. Nadawca musi użyć receivera o najwyższym priorytecie spośród obsługiwanych przez portfel. Gdy portfel obsługuje Orchard, wybiera Orchard; jeśli nie obsługuje Orchard, ale obsługuje Sapling, może wybrać Sapling. Faktyczny pool zależy więc od możliwości portfela nadawcy, a nie tylko od wyświetlonego adresu.

Projekt Revision 2 proponuje prefiksy zu dla adresów wyłącznie shielded oraz tu dla formatów mogących zawierać transparent receivery. Indeks ZIP nadal oznacza Revision 2 jako projekt, dlatego nie należy przedstawiać tych prefiksów jako zwykłego, aktywnego formatu UA Mainnet. Przed wysłaniem sprawdź typ adresu, wybraną sieć i receiver pokazany w podglądzie portfela.

Transfer z transparent do shielded (t→z) może wydać publiczne UTXO i utworzyć notatki Sapling lub Orchard. Obserwator widzi transparent inputs, zmiany w transparent pool oraz wartość netto wpływającą do shielded pool. Nie odczytuje jednak zwykłego shielded adresu odbiorczego ani kwoty każdej notatki tak jak transparent UTXO. Shielding pozostawia więc ślady na granicy pooli.

W odwrotnym transferze (z→t) adresy i kwoty transparent outputs są publiczne, a odpowiadająca im zmiana wartości w shielded pool jest widoczna. Płatność tworząca notatki w jednym poolu może ukrywać odbiorcę i kwotę, lecz transfer między Sapling a Orchard może ujawniać zmiany sald poszczególnych pooli. Sama publiczna wartość graniczna nie identyfikuje osoby ani starszej notatki, ale można ją łączyć z kwotami, czasem i danymi zewnętrznymi.

Nie pytaj tylko, czy adres jest shielded. Sprawdź także, skąd pochodzi wartość i przez które poole przechodzi. Wypłata z giełdy, płatność u sprzedawcy lub przelew o znanej kwocie i czasie mogą zostać zestawione z publicznymi informacjami o granicy poola. Nie odsłania to automatycznie wszystkich właścicieli ani wewnętrznej ścieżki notatek, lecz może zawęzić możliwe powiązania.

ZIP 316 definiuje viewing key jako informacje potrzebne do przeglądania płatności na adres. Full Viewing Key (FVK) może także pokazywać informacje o płatnościach z tego adresu. Z FVK można wyprowadzić Incoming Viewing Key (IVK), a z IVK adres. Unified Viewing Keys łączą elementy kluczy podglądu dla różnych protokołów.

Sama viewing key nie może podpisać wydania środków; do tego potrzebny jest osobny spending key lub system podpisu. Nie jest to jednak nieszkodliwa informacja publiczna. Typ klucza i implementacja portfela określają, jakie transakcje można zobaczyć; klucz na poziomie konta może ujawniać więcej niż pojedynczy adres odbiorczy. Przed udostępnieniem audytorowi lub usłudze sprawdź zakres, czas przechowywania, możliwość usunięcia i powiązanie z innymi adresami.

Viewing key nie usuwa śladów, które były publiczne wcześniej: transparent inputs, outputs, kwoty i czas można analizować bez takiego klucza. Z kolei explorer albo portfel bez wymaganej obsługi może nie pokazać shielded transakcji zapisanej w łańcuchu. Brak transakcji w aplikacji nie oznacza braku zapisu on-chain.

Widoczność zależy od poola i typu receivera. W pełni transparentny przepływ ujawnia adresy, kwoty i powiązania UTXO. Shielded payment szyfruje odbiorców i wartości notatek, ale commitments, nullifiers, czas i dane protokołu pozostają on-chain. Oddzielne wskazówki mogą wynikać z przejścia między poolami, obsługiwanych pooli, znanego czasu płatności, zapisów giełdy i udostępnionych viewing keys.

Unified Address nie wymusza użycia Orchard. Wybrany receiver może zależeć od wersji portfela, ustawień, implementacji i ścieżki transakcji. Zamiast wnioskować o prywatności po wklejeniu adresu, sprawdź podgląd lub wynik transakcji. [Przewodnik po prywatności Monero](/pl/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) omawia inny projekt; [poradnik o ponownym użyciu adresów Bitcoin](/pl/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained) pokazuje kontrast z transparentnym rejestrem.

Prywatność sieciowa to kolejna warstwa. Dostawca RPC, serwer lekkiego portfela, giełda lub usługa płatnicza mogą obserwować tworzenie lub przekazywanie transakcji i przechowywać poza łańcuchem adres IP, konto lub czas. Dowody kryptograficzne nie usuwają logów usług. Lepiej ustalić, kto otrzymał metadane i jak je przechowuje, niż przypisywać absolutny poziom anonimowości.

Najpierw upewnij się, że portfel jest połączony z właściwą siecią Mainnet lub Testnet. W podglądzie płatności sprawdź, czy odbiorca podał Unified Address i który receiver wybiera portfel. Tekst UA nie pokazuje listy receiverów; sprawdź w portfelu pool, kwotę, memo i opłatę. Jeśli odbiorca prosi o shielded payment, a podgląd pokazuje transparent output, przed wysłaniem sprawdź obsługę protokołów w obu portfelach.

Przy analizie istniejącej transakcji dopasuj jej identyfikator i sieć, a następnie sprawdź poole występujące w inputs i outputs. Transparentne adresy i kwoty widać w publicznych explorerach; szczegóły notatek mogą nie być dostępne w narzędziu bez obsługi shielded. Jeśli do kontroli potrzebna jest viewing key, ustal cel i zakres danych; nie wklejaj spending key ani viewing key do nieznanej strony. Poradnik portfeli custodial i non-custodial wyjaśnia też, kto odpowiada za podpis.

Nie zakładaj: „użyłem shielded address, więc płatność jest całkowicie prywatna” ani „explorer nie pokazuje wartości, więc transfer nie zaszedł”. Historia portfela, sieć, transaction ID, stan łańcucha, potwierdzenia i uprawnienie viewing to różne informacje. Jeśli odbiorca ma potwierdzić wpływ, sprawdź również, czy jego portfel obsługuje i zsynchronizował właściwy pool.

Załóżmy, że Lee wysyła 1,25 ZEC z transparent UTXO na Unified Address Revision 0 zawierający receivery Orchard, Sapling i transparent. Kwota jest wyłącznie ilustracyjna, nie oznacza opłaty ani ustawienia portfela. Jeśli portfel Lee obsługuje Orchard, reguła preferencji ZIP 316 wskazuje Orchard. Łańcuch pokazuje transparent input i dane granicy, np. wartość netto wpływającą do shielded pool, ale nie zwykły publiczny output z adresem shielded i kwotą notatki odbiorcy.

Jeśli portfel Lee nie obsługuje Orchard, ale obsługuje Sapling, może wybrać Sapling. Portfel nieobsługujący żadnego shielded pool może użyć transparent receivera, jeśli dostępny jest odpowiedni receiver i format płatności. Revision 0 UA musi zawierać shielded receiver, lecz nadawca wybiera tylko receiver, który obsługuje. Ta sama UA może więc prowadzić do różnych pooli i innych publicznych danych granicznych zależnie od portfela.

Odbiorca może osobno udostępnić viewing key usłudze księgowej, która wtedy może zobaczyć shielded aktywność w jej zakresie. Potwierdzenie w portfelu, brak szczegółów notatek w explorerze i zapis transakcji zgodnie z konsensusem to trzy różne fakty. Unified Addresses ułatwiają zgodność między generacjami protokołu, ale nie gwarantują pełnej prywatności ani nie zastępują wyboru receivera, zarządzania kluczami i ochrony danych sieciowych.

• Specyfikacja protokołu Zcash v2026.7.0 (NU6.2)
• ZIP 316: Unified Addresses and Unified Viewing Keys
• ZIP 211: Disabling New Value to the Sprout Pool
• ZIP 257: NU6.2 i tymczasowe zabezpieczenie Orchard
• ZIP 258: projekt wdrożenia NU6.3
• Oficjalny indeks ZIP: status Mainnet i status propozycji