Pool schermati, Unified Address e viewing key di Zcash: guida
Scopri le differenze tra pool trasparente, Sapling e Orchard, come il wallet sceglie un receiver in una Unified Address e quali dati può rivelare una viewing key.
In questa guidaUn pool è uno stato del registro, non un custode
Breve sintesi
Zcash non nasconde automaticamente ogni trasferimento. Nel pool trasparente indirizzi e flussi di valore sono pubblici, mentre i pool schermati Sapling e Orchard cifrano i dati delle note e usano commitment e nullifier pubblici per le verifiche di consenso. Una Unified Address può riunire più tipi di receiver: la privacy del pagamento dipende dal receiver scelto dal wallet mittente e dai pool attraversati dal valore.
Un pool è uno stato del registro, non un custode
In Zcash un pool non è un exchange o un’azienda che custodisce depositi: è uno stato del valore soggetto a regole di consenso. Il pool trasparente usa UTXO pubblici. Chi legge la blockchain può vedere gli output creati, quali transazioni li spendono e gli importi. Un indirizzo non rivela da solo un’identità legale, ma la cronologia pubblica può collegare indirizzi e movimenti.
I pool schermati rappresentano il valore con note invece che con UTXO visibili. La rete registra dati delle note cifrati, alberi di commitment e controlli sul saldo dei pool. Le prove consentono al consenso di verificare validità, conservazione del valore e prevenzione della doppia spesa senza mostrare a un osservatore comune il destinatario e l’importo come accade per un output trasparente. La specifica del protocollo Zcash descrive entrambe le rappresentazioni.
Distingui Sapling e Orchard da Sprout, non più alimentabile
Sapling e Orchard sono pool schermati separati, con protocolli e alberi di commitment distinti; i loro saldi non sono un unico stato intercambiabile. Sprout è stato il protocollo schermato iniziale di Zcash. Dopo l’attivazione dello ZIP 211, non è più possibile aggiungere nuovo valore al suo pool, anche se nel registro storico esistono ancora transazioni Sprout.
Le informazioni di rete vanno datate: l’indice ufficiale degli ZIP indica NU6.2 come ultimo upgrade Mainnet completato, attivato al blocco 3.364.600 il 3 giugno 2026. NU6.2 ha riabilitato le azioni Orchard dopo una mitigazione temporanea della vulnerabilità, con regole corrette. NU6.3 e il pool Ironwood restano proposte in bozza, quindi non vanno descritti come regole Mainnet attive. Vedi ZIP 257, l’indice degli ZIP e la bozza ZIP 258.
I dati cifrati della nota e il commitment pubblico hanno funzioni diverse
Una nota shielded associa valore e autorità di spesa del destinatario all’interno di un pool. Il valore, i dettagli del destinatario e il memo sono cifrati perché un wallet con le informazioni di ricezione corrette possa leggerli. La blockchain conserva dati cifrati e un commitment alla nota, non il testo in chiaro: il commitment permette le verifiche senza pubblicarne il contenuto.
Quando la nota viene spesa, la transazione rivela un nullifier. Chi spende dimostra di conoscere la nota e pubblica il nullifier; la rete verifica che non sia già stato usato. Gli osservatori vedono nullifier e albero dei commitment, ma non dovrebbero poter associare il nullifier a uno specifico commitment precedente. Questo impedisce la doppia spesa senza rendere segreti tutti i dati di consenso. Sapling e Orchard seguono questo schema generale con crittografia e prove diverse; per spendere una nota serve l’autorità privata corrispondente.
Una Unified Address riunisce diversi tipi di receiver
Una Unified Address (UA) è una stringa codificata che può includere receiver Orchard, Sapling, P2SH trasparenti e P2PKH trasparenti. La Revision 0 attiva deve contenere almeno un receiver schermato. La stringa è intenzionalmente opaca: a occhio non si capisce quali receiver contenga. ZIP 316 distingue Revision 0 dal formato Revision 2 proposto.
Il wallet mittente non paga tutti i receiver. Nella Revision 0 la priorità è Orchard, Sapling, P2SH trasparente, poi P2PKH trasparente; il mittente deve usare il receiver supportato con priorità più alta. Se supporta Orchard, sceglie Orchard; se non lo supporta ma supporta Sapling, può scegliere Sapling. La scelta concreta dipende quindi dalle capacità del wallet che invia, non solo dall’indirizzo mostrato.
La bozza Revision 2 propone i prefissi zu per indirizzi solo schermati e tu per formati che possono contenere receiver trasparenti. L’indice ufficiale li segnala ancora come bozza: non trattarli come il formato UA Mainnet ordinario. Prima di inviare controlla nella schermata del wallet il tipo di indirizzo, la rete e il receiver scelto.
Attraversare il confine di un pool può rendere visibili i flussi
Un trasferimento da trasparente a schermato (t→z) può spendere UTXO pubblici e creare note Sapling o Orchard. Un osservatore vede gli input trasparenti, i cambiamenti nel pool trasparente e il valore netto che entra nel pool schermato. Non vede però l’indirizzo di ricezione schermato ordinario e ogni importo delle note come vedrebbe output UTXO trasparenti. La schermatura lascia quindi dati sul passaggio tra pool.
Nel trasferimento inverso (z→t), gli indirizzi e gli importi degli output trasparenti diventano pubblici e si osserva la variazione del saldo del pool schermato. Un pagamento che crea note nello stesso pool può nascondere destinatario e importo, mentre il passaggio tra Sapling e Orchard può mostrare variazioni per pool. Un valore di confine da solo non identifica una persona o una vecchia nota, ma può essere confrontato con importi, orari e registri esterni.
Non chiederti soltanto se l’indirizzo è schermato: considera da dove arriva il valore e quali pool attraversa. Un prelievo da exchange, un pagamento a un esercente o un trasferimento con importo e orario noti possono essere confrontati con i dati pubblici del confine. Questo non svela automaticamente ogni proprietario o percorso interno, ma può restringere le possibilità.
Le viewing key danno accesso in lettura, non il potere di spendere
ZIP 316 definisce una viewing key come le informazioni necessarie per vedere i pagamenti verso un indirizzo. Una Full Viewing Key (FVK) può mostrare anche informazioni sui pagamenti provenienti da quell’indirizzo. Da una FVK si può derivare una Incoming Viewing Key (IVK), e da una IVK si può ricavare un indirizzo. Le Unified Viewing Key combinano elementi di visualizzazione per più protocolli.
La sola viewing key non può firmare una spesa: serve una chiave di spesa separata o un sistema di firma. Tuttavia non è un dato pubblico innocuo. Il tipo di chiave e il wallet determinano quali transazioni può vedere; una chiave a livello di account può rivelare più di un singolo indirizzo. Prima di condividerla con un commercialista o un servizio, verifica ambito, conservazione, cancellazione e combinazione con altri indirizzi.
La chiave non rimuove indizi già pubblici: input e output trasparenti, importi e tempi possono essere analizzati senza di essa. Al contrario, un explorer o wallet senza il supporto necessario potrebbe non mostrare una transazione schermata che la blockchain ha comunque registrato. “Non appare nell’app” non significa “non esiste sulla catena”.
Le transazioni schermate non nascondono ogni collegamento
La visibilità dipende dal pool e dal tipo di receiver. Un flusso solo trasparente rivela indirizzi, importi e collegamenti UTXO. Un pagamento schermato cifra destinatari e valori delle note, ma commitment, nullifier, tempi e dati di protocollo restano registrati. I passaggi di confine, i pool supportati, un orario noto, i dati di un exchange e le viewing key condivise possono fornire indizi distinti.
Una Unified Address non forza ogni pagamento su Orchard: il receiver scelto può dipendere da versione, impostazioni, implementazione e percorso della transazione nel wallet. Controlla l’anteprima o il risultato finale invece di dedurre la privacy dal semplice incollare un indirizzo. La [guida alla privacy di Monero](/it/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) descrive un’altra architettura; la [guida al riuso degli indirizzi Bitcoin](/it/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained) confronta un registro trasparente.
Esiste anche la privacy di rete: un provider RPC, un server light-wallet, un exchange o un servizio di pagamento può osservare richieste di creazione o inoltro e conservare IP, account o orari fuori dalla blockchain. Le prove crittografiche non cancellano i log dei servizi. È più preciso chiedersi chi ha ricevuto metadati e come li conserva che attribuire un livello assoluto di anonimato.
Controlla insieme indirizzo e risultato della transazione
Prima invio, verifica che il wallet sia sulla Mainnet o Testnet prevista. Nell’anteprima controlla che il destinatario abbia fornito una Unified Address e osserva quale receiver verrà usato. La stringa UA non mostra visivamente i receiver inclusi: leggi nel wallet pool, importo, memo e commissione. Se il destinatario richiede un pagamento schermato ma l’anteprima mostra un output trasparente, controlla il supporto dei protocolli in entrambi i wallet prima di inviare.
Per controllare una transazione esistente, abbina identificativo e rete, poi verifica quali pool compaiono negli input e negli output. Gli indirizzi e gli importi trasparenti sono visibili negli explorer pubblici; i dettagli delle note potrebbero non apparire in uno strumento che non le supporta. Se serve una viewing key, chiarisci perché e quali dati rivela; non inserire mai chiavi di spesa o viewing key in un sito sconosciuto. Anche la guida ai wallet custodial e non-custodial spiega chi controlla la firma.
Non concludere “ho usato un indirizzo schermato, quindi il pagamento è completamente privato” o “l’explorer non mostra l’importo, quindi non è avvenuto”. Cronologia del wallet, rete, ID transazione, stato della catena, conferme e autorizzazioni di visualizzazione sono fatti distinti. Per confermare la ricezione, controlla anche che il wallet destinatario supporti e abbia sincronizzato il pool corretto.
Segui receiver e informazioni visibili in un esempio ipotetico
Immagina che Lee invii 1,25 ZEC da un UTXO trasparente a una Unified Address Revision 0 che include receiver Orchard, Sapling e trasparenti. L’importo è solo un esempio: non rappresenta una commissione o l’impostazione predefinita di un wallet. Se il wallet di Lee supporta Orchard, la regola di preferenza ZIP 316 seleziona Orchard. La catena mostra l’input trasparente e informazioni sul confine, come il valore netto entrato nel pool schermato, ma non l’indirizzo shielded del destinatario e il valore della nota come output pubblici ordinari.
Se il wallet di Lee non supporta Orchard ma supporta Sapling, può selezionare Sapling. Un wallet che non supporta alcun pool schermato può usare il receiver trasparente se receiver e formato di pagamento sono disponibili. Una UA Revision 0 deve contenere almeno un receiver schermato, ma il mittente ne seleziona uno solo che supporta. La stessa stringa può quindi produrre pool e dati di confine differenti con wallet diversi.
Infine, se il destinatario condivide separatamente una viewing key con un servizio contabile, quel servizio potrebbe vedere le attività shielded comprese nel suo ambito. La ricevuta nel wallet, l’assenza dei dettagli delle note nell’explorer e la registrazione della transazione secondo consenso sono tre fatti diversi. Le Unified Address semplificano la compatibilità con più generazioni di protocollo, ma non garantiscono privacy totale e non sostituiscono selezione del receiver, gestione delle chiavi o precauzioni di rete.
Riferimenti primari del protocollo
Domande frequenti
Q1Indirizzo e importo sono nascosti in ogni transazione Zcash?
No. Le transazioni nel pool trasparente rivelano UTXO, indirizzi e importi. Una Unified Address può avere più receiver: controlla quale ha scelto il wallet mittente.
Q2Se una Unified Address include Orchard, riceverà sempre tramite Orchard?
Se il wallet mittente supporta Orchard e usa una UA Revision 0 che lo include, ZIP 316 impone di scegliere Orchard. Altri wallet possono avere supporto diverso; controlla l’anteprima del pagamento.
Q3Posso spostare fondi con una Viewing Key?
No. Serve a leggere informazioni di transazione nel suo ambito. Per spendere occorre una chiave di spesa o un’autorità di firma separata; proteggi comunque la viewing key perché può rivelare dati privati.
Fonti e approfondimenti
Segnala un problema
Prepareremo un’e-mail con il link a questo articolo. Mark riceverà la segnalazione solo dopo l’invio
Controllo rapido
Hai finito la guida? Verifica ciò che hai capito con 3 domande
Domanda 01
Che cosa vede un osservatore comune quando una nota schermata viene registrata sulla catena?
Scegli una risposta per vedere la spiegazione
Glossario delle opzioni
The process that requires an option writer to fulfill the contract after an exercise notice is allocated; it can create or remove an underlying position.
Leggi la guida completaBid-ask spreadThe gap between the best displayed bid and ask, which is a practical trading cost and a signal of how uncertain an immediate fill may be.
Leggi la guida completa0DTEAn option that expires on the current trading day; little time remains for the thesis to work, while gamma and execution risk can change quickly.
Leggi la guida completa