Zcash shielded pools, Unified Addresses en viewing keys uitgelegd

Een pool in Zcash is geen beurs of bedrijf dat stortingen bewaart, maar een toestand van waarde die onder bepaalde consensusregels valt. De transparante pool gebruikt openbare UTXO’s. Iedereen kan op de chain zien welke output is gemaakt, welke latere transactie die uitgeeft en welk bedrag zichtbaar is. Een adres onthult niet vanzelf een wettelijke identiteit, maar het openbare spoor kan adresgebruik en geldstromen koppelen.

Shielded pools geven waarde weer met notes in plaats van zichtbare UTXO’s. De chain slaat versleutelde notegegevens en commitmentbomen op en controleert de poolbalansen. Bewijzen stellen consensus in staat geldigheid, waardebehoud en bescherming tegen dubbele uitgaven te controleren zonder dat een gewone waarnemer de ontvanger en het bedrag ziet zoals bij een transparante output. De Zcash Protocol Specification beschrijft beide modellen.

Sapling en Orchard zijn afzonderlijke shielded pools met eigen protocollen en commitmentbomen; het zijn geen onderling verwisselbare balansen. Sprout was het eerste shielded protocol van Zcash. Sinds ZIP 211 is geactiveerd, kan er geen nieuwe waarde meer aan de Sprout-pool worden toegevoegd, al staan oudere Sprout-transacties nog wel in de geschiedenis.

De netwerkstatus moet een datum hebben. De officiële ZIP-index noemt NU6.2 de meest recente afgeronde Mainnet-upgrade, geactiveerd op blok 3.364.600 op 3 juni 2026. NU6.2 schakelde Orchard weer in na een tijdelijke kwetsbaarheidsmaatregel en met gecorrigeerde circuitregels. NU6.3 en de Ironwood-pool zijn nog voorstellen in conceptvorm, geen huidige Mainnet-regels. Zie ZIP 257, de ZIP-index en het concept ZIP 258.

Een shielded note koppelt waarde binnen een pool aan de bestedingsbevoegdheid van de ontvanger. De waarde, ontvangergegevens en memo worden versleuteld, zodat een wallet met de juiste ontvangstinformatie ze kan lezen. De chain bevat versleutelde gegevens en een commitment aan de note, niet de leesbare note zelf. Het commitment maakt controles mogelijk zonder de inhoud openbaar te maken.

Wanneer een note wordt uitgegeven, maakt de transactie een nullifier bekend. De uitgever bewijst de note te kennen en publiceert die nullifier; het netwerk controleert dat deze niet eerder is gebruikt. Waarnemers zien de nullifier en de commitmentboom, maar horen de nullifier niet aan een eerdere commitment te kunnen koppelen. Zo wordt dubbel uitgeven tegengegaan zonder alle consensusgegevens geheim te maken. Sapling en Orchard volgen dit algemene patroon met andere cryptografie en bewijzen; uitgeven vereist de bijbehorende privésleutelbevoegdheid.

Een Unified Address (UA) is één gecodeerde string die Orchard-, Sapling-, transparante P2SH- en transparante P2PKH-receivers kan bevatten. Een actieve Revision 0-UA moet minstens één shielded receiver hebben. De string is bewust ondoorzichtig: aan de buitenkant kun je niet zien welke receivers erin zitten. ZIP 316 maakt onderscheid tussen Revision 0 en de voorgestelde Revision 2.

De wallet van de verzender betaalt niet naar elke receiver. In Revision 0 is de voorkeur Orchard, Sapling, transparante P2SH en daarna transparante P2PKH. De verzender moet de hoogst geprioriteerde receiver gebruiken die de wallet ondersteunt. Ondersteunt de wallet Orchard, dan kiest zij die; ondersteunt zij Orchard niet maar Sapling wel, dan kan Sapling worden gekozen. De daadwerkelijke pool hangt dus af van de mogelijkheden van de verzendende wallet, niet alleen van de getoonde adresstring.

Het concept Revision 2 stelt zu voor shielded-only adressen en tu voor formaten die transparante receivers kunnen bevatten. De officiële ZIP-index markeert dit nog als concept; behandel die voorvoegsels niet als de gewone live Mainnet-UA. Controleer voor het verzenden in de wallet het adrestype, het netwerk en de gekozen receiver.

Een overdracht van transparant naar shielded (t→z) kan openbare UTXO’s uitgeven en Sapling- of Orchard-notes aanmaken. Een waarnemer ziet de transparante inputs, de verandering in de transparante pool en de nettowaarde die een shielded pool binnenkomt. De waarnemer ziet niet het gewone shielded ontvangstadres en elk note-bedrag alsof het een transparante UTXO is. Shielding laat dus wel informatie over de poolgrens achter.

Bij de omgekeerde overdracht (z→t) zijn transparante outputadressen en bedragen openbaar en is de bijbehorende verandering in de shielded-poolwaarde waarneembaar. Een shielded betaling binnen één pool kan ontvanger en bedrag verbergen; een overdracht tussen Sapling en Orchard kan veranderingen per pool zichtbaar maken. Een openbare grenswaarde identificeert op zichzelf geen persoon of oude note, maar kan naast bedragen, tijden en externe administratie worden gelegd.

Vraag daarom niet alleen of een adres shielded is, maar ook waar de waarde vandaan komt en welke pools zij passeert. Een beursopname, betaling aan een winkelier of persoonlijke overschrijving met bekende tijd of bedrag kan met openbare grensgegevens worden vergeleken. Dat onthult niet automatisch iedere eigenaar of interne route, maar kan de mogelijkheden beperken.

ZIP 316 definieert een viewing key als informatie die nodig is om betalingen aan een adres te bekijken. Een Full Viewing Key (FVK) kan ook informatie over betalingen vanaf dat adres tonen. Uit een FVK kan een Incoming Viewing Key (IVK) worden afgeleid; uit een IVK kan een adres worden afgeleid. Unified Viewing Keys combineren viewing-key-items voor meerdere protocollen.

Een viewing key alleen kan geen betaling ondertekenen. Daarvoor is een aparte spending key of ondertekeningsbevoegdheid nodig. Toch is een viewing key geen onschuldig openbaar gegeven: het type sleutel en de wallet bepalen welke transacties zichtbaar zijn. Een key op accountniveau kan meer blootleggen dan één ontvangstadres. Controleer vóór delen met een accountant of dienst de reikwijdte, bewaartermijn, verwijdermogelijkheid en koppeling met andere adressen.

De key verwijdert geen aanwijzingen die al openbaar zijn: transparante inputs en outputs, bedragen en tijdstippen kunnen zonder viewing key worden geanalyseerd. Omgekeerd kan een explorer of wallet zonder de juiste ondersteuning een shielded transactie missen die de chain wel heeft vastgelegd. “De app toont het niet” betekent niet “het staat niet op de chain”.

Wat zichtbaar is, hangt af van de pool en het ontvangertype. Een volledig transparante geldstroom toont adressen, bedragen en UTXO-koppelingen. Een shielded betaling versleutelt note-ontvangers en waarden, maar commitments, nullifiers, tijdstippen en protocolgegevens blijven op de chain staan. Poolgrenzen, walletondersteuning, een bekende betalingstijd, beursgegevens en gedeelde viewing keys kunnen afzonderlijke aanwijzingen opleveren.

Een Unified Address dwingt geen betaling naar Orchard af: de gekozen receiver kan afhangen van walletversie, instellingen, implementatie en transactieroute. Leid de privacy niet af uit alleen het plakken van een adres, maar controleer de preview of het transactie-resultaat. De [Monero-privacygids](/nl/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) beschrijft een ander ontwerp; de [Bitcoin-adreshergebruikgids](/nl/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained) vergelijkt dit met een transparant grootboek.

Netwerkprivacy is een aparte laag. Een RPC-provider, light-walletserver, beurs of betaaldienst kan verzoeken om transacties te maken of door te sturen zien en IP-, account- of tijdgegevens buiten de chain bewaren. Cryptografische bewijzen wissen die dienstlogs niet. Vraag daarom wie metadata heeft ontvangen en hoe die wordt bewaard, in plaats van één absoluut anonimiteitsniveau toe te schrijven.

Controleer eerst of de wallet op de bedoelde Mainnet of Testnet staat. Bekijk tijdens de betaalcontrole of de ontvanger een Unified Address heeft opgegeven en welke receiver de wallet zal gebruiken. De UA-string toont de receivers niet visueel; controleer in de wallet pool, bedrag, memo en kosten. Vraagt de ontvanger om een shielded betaling terwijl de preview een transparante output toont, controleer dan eerst protocolondersteuning in beide wallets.

Zoek bij een bestaande transactie het transactie-ID en het netwerk op en controleer welke pools in inputs en outputs voorkomen. Transparante adressen en bedragen zijn zichtbaar in publieke explorers; notegegevens kunnen ontbreken in een hulpmiddel zonder shielded ondersteuning. Als een viewing key nodig is, bepaal dan waarom en wat deze onthult; plak spending keys of viewing keys niet in een onbekende website. De gids voor custodial en non-custodial wallets beschrijft ook wie de handtekening beheert.

Trek niet de conclusie “ik gebruikte een shielded adres, dus de betaling is volledig privé” of “de explorer toont geen bedrag, dus de betaling is niet gebeurd”. Walletgeschiedenis, netwerk, transactie-ID, chainstatus, bevestigingen en kijkbevoegdheid zijn verschillende feiten. Wil de ontvanger ontvangst bevestigen, controleer dan ook of diens wallet de relevante pool ondersteunt en heeft gesynchroniseerd.

Stel dat Lee 1,25 ZEC verstuurt vanaf een transparante UTXO naar een Unified Address Revision 0 met Orchard-, Sapling- en transparante receivers. Het bedrag is alleen een voorbeeld, geen transactiekosten of standaardinstelling. Als Lee’s wallet Orchard ondersteunt, kiest de voorkeurregel van ZIP 316 de Orchard-receiver. De chain toont de transparante input en grensinformatie zoals de nettowaarde die de shielded pool binnenkomt, maar niet het shielded ontvangstadres en note-bedrag als gewone openbare outputs.

Ondersteunt Lee’s wallet Orchard niet maar Sapling wel, dan kan de wallet Sapling kiezen. Een wallet zonder ondersteuning voor shielded pools kan een transparante receiver gebruiken als receiver en betaalformaat beschikbaar zijn. Een Revision 0-UA moet een shielded receiver bevatten, maar de verzender kiest alleen een receiver die de wallet ondersteunt. Dezelfde UA kan met verschillende wallets dus tot andere pools en openbare grensgegevens leiden.

De ontvanger kan daarnaast een viewing key met een boekhoudservice delen; die dienst kan dan shielded activiteit binnen de reikwijdte zien. De ontvangst in de wallet, het ontbreken van notegegevens in de explorer en de registratie van een transactie volgens consensus zijn drie verschillende feiten. Unified Addresses vereenvoudigen compatibiliteit tussen protocolgeneraties, maar garanderen geen volledige privacy en nemen receiverkeuze, sleutelbeheer of netwerkblootstelling niet over.

• Zcash Protocol Specification 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 and the Orchard Temporary Mitigation
• ZIP 258: Draft NU6.3 Deployment
• Officiële ZIP-index: Mainnet-status en status van voorstellen