Was ist ein Zcash Viewing Key?

Ein Zcash Viewing Key ist ein Schlüssel, mit dem sein Inhaber private Informationen über ein geschütztes Zcash-Konto sehen kann – eingehende Zahlungen, Beträge und Memos –, ohne die Gelder in irgendeiner Weise ausgeben zu können. Zcash kennt mehrere Arten von Viewing Keys, und jede verrät unterschiedlich viel: Ein Incoming Viewing Key zeigt nur, was eingeht, während ein Full Viewing Key zusätzlich Ausgaben zeigt.

Genau diesen zweiten Satz übergehen die meisten Erklärungen. „Viewing Key“ ist eine Familie von Schlüsseln, nicht ein einzelnes Ding, und der Unterschied zwischen ihnen ist der Unterschied zwischen „jemand darf deine Eingänge beobachten“ und „jemand darf dein ganzes Konto lesen“.

Ein einfaches Beispiel

Alice bewahrt ihre ZEC in einem geschützten Zcash-Konto auf. Ihr Steuerberater muss sehen können, was darauf passiert ist. Alice möchte weder ihre Seed-Phrase noch ihren Spending Key herausgeben, denn mit beidem könnte der Steuerberater ihr Geld bewegen.

Stattdessen exportiert Alice einen Viewing Key aus ihrer Wallet und schickt ihn dem Steuerberater über einen privaten Kanal. Der Steuerberater importiert ihn in eine eigene Wallet, die die Blockchain scannt und die Aktivität auf Alices Konto anzeigt. Er kann hinschauen, aber nichts ausgeben.

Was der Steuerberater genau sieht, hängt davon ab, welchen Schlüssel Alice gewählt hat:

• Mit einem Incoming Viewing Key sieht der Steuerberater jede Zahlung, die Alices Konto erhalten hat, inklusive Betrag und Memo, aber nichts darüber, was Alice an andere gezahlt hat.
• Mit einem Full Viewing Key sieht der Steuerberater zusätzlich, wann Alices Gelder ausgegeben wurden, und – wenn Alices Wallet diese Transaktionen auf die Standardweise erstellt hat – wohin sie gingen, wie viel und welches Memo Alice angehängt hat.

Bei der heute üblichen kontobasierten Nutzung gelten beide Schlüssel für das Konto als Ganzes statt für eine einzelne Adresse, und beide funktionieren so lange weiter, wie das Konto genutzt wird. Aus diesen beiden Tatsachen ergibt sich der Großteil der Ratschläge weiter unten in diesem Guide.

Viewing Keys vs. Spending Keys

Es hilft, sich ein Zcash-Konto mit drei getrennten Berechtigungsstufen vorzustellen. Das ist eine Analogie und keine Beschreibung der Kryptografie, passt aber gut dazu, wie sich die Schlüssel tatsächlich verhalten:

• Eine Empfangsadresse ist wie eine Postanschrift. Jeder, der sie hat, kann dir ZEC schicken. Sie verrät nichts darüber, was du empfangen oder ausgegeben hast.
• Ein Incoming Viewing Key ist wie ein Fenster in deinen Briefkasten. Wer ihn hat, sieht, was an einer deiner Adressen ankommt, aber nicht, was du verschickst.
• Ein Full Viewing Key ist wie ein Lesezugriff auf das Kontobuch. Wer ihn hat, sieht, was hereinkommt, sieht, wann Geld abfließt, und sieht im Standardfall, wohin es ging.
• Ein Spending Key (oder die Seed-Phrase, aus der er erzeugt wird) ist die Befugnis, das Geld zu bewegen. Er ist der einzige der vier, mit dem man ausgeben kann.

Daraus folgen zwei Dinge. Erstens lässt sich ein Viewing Key niemals zu einem Spending Key „aufwerten“; die Mathematik funktioniert nur in eine Richtung. Zweitens macht das Fehlen einer Ausgabeberechtigung einen Viewing Key nicht harmlos. Behandle ihn als sensiblen, dauerhaften Lesezugang: Einmal geteilt, gewährt er diesen Zugang immer weiter.

Incoming Viewing Keys vs. Full Viewing Keys

Jedes geschützte Zcash-Konto hat beide Arten von Schlüsseln eingebaut; deine Wallet nutzt sie ständig, um deine Zahlungen zu finden und deinen Kontostand korrekt zu halten. Wenn du „einen Viewing Key teilst“, entscheidest du, welchen davon du herausgibst.

Ein Incoming Viewing Key (IVK) kann:

• jede Zahlung an eine beliebige Adresse des Kontos erkennen und entschlüsseln,
• den Betrag, das Memo und die Adresse anzeigen, an der sie eingegangen ist,
• die Empfangsadressen des Kontos erzeugen, was auch bedeutet, dass er erkennen kann, dass diese Adressen zusammengehören.

Er kann nicht sehen, dass eine Zahlung später ausgegeben wurde. Eine laufende Summe auf Basis eines Incoming Viewing Keys ist daher ein Wert „bisher empfangen“, kein Kontostand.

Ein Full Viewing Key (FVK) kann alles, was der Incoming Key kann, und zusätzlich:

• erkennen, wann Gelder im Konto ausgegeben werden und ob das Konto in dieser Transaktion der einzige Ausgebende war,
• die eigenen ausgehenden Zahlungen des Kontos entschlüsseln, wenn die sendende Wallet dem Standardverhalten des Protokolls gefolgt ist, und dabei Empfängeradresse, Betrag und Memo offenlegen,
• den Kontostand nachverfolgen, weil er beide Seiten sieht.

Der Incoming Viewing Key ist die engere Offenlegung. Wenn jemand nur bestätigen muss, dass Zahlungen eingegangen sind, ist er der richtige Schlüssel.

Was sind Unified Viewing Keys?

Moderne Zcash-Wallets verwalten nicht nur einen geschützten Schlüssel nach dem anderen. Ein einzelnes Konto kann über mehrere „Receiver“-Typen gleichzeitig empfangen: das geschützte Orchard-Protokoll (das auch der neuere Ironwood-Pool nutzt), das ältere geschützte Sapling-Protokoll und optional eine transparente Adresse. Deshalb beginnt eine moderne Adresse meist mit u1…: Sie ist eine Unified Address, die mehrere Receiver in einem String bündelt.

Viewing Keys wurden nach dem Standard ZIP 316 auf dieselbe Weise vereinheitlicht:

• Ein Unified Full Viewing Key (UFVK) bündelt die Full Viewing Keys für jeden Receiver-Typ des Kontos. Im Mainnet beginnt er mit uview1….
• Ein Unified Incoming Viewing Key (UIVK) bündelt stattdessen die Incoming Viewing Keys und beginnt mit uivk1…. Eine Wallet kann einen UIVK aus einem UFVK ableiten, aber nicht umgekehrt.
• Ein Sapling Extended Full Viewing Key ist das ältere Einzel-Pool-Format für reine Sapling-Konten und beginnt mit zxviews1…. Manche Wallets exportieren es noch für Konten, die angelegt wurden, bevor es Unified Addresses gab.

Die praktische Konsequenz betrifft den Umfang. Ein uview1…- oder uivk1…-Schlüssel ist nicht „der Viewing Key für eine Adresse“. Bei der heute üblichen kontobasierten Nutzung gilt die Einsichtsberechtigung in der Regel auf Kontoebene statt für eine einzelne diversifizierte Adresse, und ein Unified Key deckt jeden Pool dieses Kontos ab. Hat das Konto einen transparenten Receiver, enthält der Unified Key auch den transparenten Watching Key des Kontos, sodass der Inhaber jede transparente Adresse, die das Konto nutzt, auflisten und beobachten und mit der geschützten Aktivität verknüpfen kann. (Alle Beispiel-Präfixe in diesem Guide sind gekürzte Platzhalter; ein echter Schlüssel ist ein langer String, den du niemals in eine Webseite einfügen solltest.)

Was kann jemand mit deinem Viewing Key sehen?

Hier der Vergleich auf einen Blick, vom schwächsten zum mächtigsten. „Konto“ meint jede Adresse, die das Konto erzeugt hat oder erzeugen wird.

Ein paar Einschränkungen sind wichtig, und sie stammen aus ZIP 310, der einzigen formalen Beschreibung dessen, was ein Viewing-Key-Inhaber erfährt. ZIP 310 behandelt Sapling-Schlüssel und ist ein informatives Dokument, das noch als Draft markiert ist. Das Orchard-Protokoll hat dieselbe Struktur, daher gelten in der Praxis dieselben Kategorien, aber es gibt keine eigene veröffentlichte Analyse für Orchard, und seine Garantien sollten nicht als formal auf Orchard ausgeweitet verstanden werden.

• Garantierte Informationen. Mit einem Full Viewing Key erfährt der Inhaber garantiert, wann eine Note im Konto ausgegeben wird, ob das Konto der einzige Ausgebende war und dass eine bestimmte Zahlung tatsächlich an einer der Adressen des Kontos angekommen ist. Kontostände sind nur als Untergrenze garantiert: Der exakte Wert stimmt, wenn Transaktionen dem Standardverhalten des Protokolls folgen, das normale Zcash-Wallets verwenden.
• Unbestätigte Informationen. Ein Memo, in dem „das ist von Bob“ steht, ist nur Text; nichts im Protokoll beweist, dass der Absender es geschrieben hat. Ein Viewing-Key-Inhaber sollte Memo-Inhalte als Behauptungen behandeln, nicht als Tatsachen.
• Undefinierte Informationen. Das Protokoll unterscheidet nicht zwischen einer Zahlung von jemand anderem und Alice, die Geld zwischen ihren eigenen Adressen verschiebt, daher beweist ein Viewing Key nicht, „wer Alice bezahlt hat“. Ebenso sind die Empfänger von Alices Ausgaben nur sichtbar, weil Standard-Wallets eine Kopie jeder ausgehenden Zahlung mit dem eigenen Outgoing Viewing Key des Absenders verschlüsseln. Eine Wallet, die diesen Schritt bewusst auslässt, würde den Empfänger selbst für den Inhaber eines Full Viewing Keys undefiniert lassen.
• Nicht offengelegte Informationen. Ein Viewing Key für Alices Konto verrät nichts über die Konten anderer. Er legt weder die Schlüssel ihrer Gegenparteien noch deren andere Transaktionen offen.

„Ein Full Viewing Key zeigt alles“ ist also in beide Richtungen falsch. Er zeigt über das Konto selbst mehr, als die meisten erwarten, einschließlich ausgehender Zahlungen, und er beweist weniger, als viele erwarten, darüber, wer auf der anderen Seite steht.

Was kann ein Viewing Key nicht?

• Er kann keine Gelder ausgeben, einfrieren oder umleiten. Nur ein Spending Key kann eine Transaktion autorisieren.
• Er lässt sich nicht in einen Spending Key umwandeln.
• Er kann die geschützte Aktivität anderer Leute nicht sehen. Er entschlüsselt nur, was das Konto betrifft, zu dem er gehört.
• Ein Incoming Viewing Key kann Ausgaben oder Details zu ausgehenden Zahlungen überhaupt nicht sehen.
• Keiner der beiden Schlüssel kann beweisen, wer eine Zahlung gesendet hat, oder erzwingen, dass ein Memo wahr ist.
• Keiner der beiden Schlüssel kann ändern, was auf der Blockchain steht. Ein Viewing Key ist ein Lesewerkzeug; die öffentliche Blockchain enthält weiterhin nur verschlüsselte Notes, weshalb der ZecZcash Explorer für keine Adresse geschützte Kontostände oder Verläufe anzeigen kann.

Warum Zcash Viewing Keys hat

Geschützte Transaktionen verbergen Absender, Empfänger, Betrag und Memo vor allen; darum geht es bei Zcash, und genau das misst das geschützte Angebot. Aber Privatsphäre gegenüber der Öffentlichkeit ist nicht dasselbe wie Geheimhaltung gegenüber allen. Unternehmen haben Buchhalter, Fonds haben Prüfer, und Menschen nutzen Wallets auf mehr als einem Gerät.

Mit Viewing Keys kann der Inhaber eines Kontos entscheiden, wer es sehen darf und in welchem Detailgrad, ohne etwas zu veröffentlichen und ohne die Kontrolle über das Geld abzugeben. Dieses Modell der selektiven Offenlegung ist eines der prägenden Merkmale des Privatsphäre-Designs von Zcash, und die zugrunde liegenden Standards nennen zwei Ziele: Prüfung (Auditing) und die Aufteilung von Befugnissen zwischen Personen oder Geräten, sodass das System, das das Geld beobachtet, nicht das System ist, das es bewegen kann.

View-only-Wallets und Cold Storage

Der häufigste Anwendungsfall für einen Viewing Key bist du selbst. Angenommen, deine ZEC liegen in einer Wallet, deren Seed-Phrase du offline aufbewahrst. Du möchtest trotzdem den Kontostand prüfen und sehen, wie Zahlungen eingehen.

Exportiere den Full Viewing Key des Kontos einmalig aus dem Offline-Setup und importiere ihn in eine „View-only“- oder „Watch-only“-Wallet auf deinem Smartphone oder Laptop. Diese Wallet scannt die Blockchain, zeigt Kontostand und Verlauf an und hat schlicht keinen Senden-Button. Wird das Smartphone kompromittiert, bekommt der Angreifer einen Einblick in dein Konto, was ein echter Verlust an Privatsphäre ist, aber die Gelder kann er nicht nehmen. Treasuries funktionieren genauso: Signieren auf isolierter Hardware, Überwachung und Buchhaltung auf normalen Computern, die nur Einsichtsberechtigung haben.

Prüfung, Buchhaltung und geschäftliche Anwendungen

Dieselbe Idee lässt sich auf Dritte übertragen, und eine einzige Regel macht sie sicher anwendbar: Gib Viewing Keys für eigens dafür angelegte Konten heraus, nicht für alles, was du besitzt. Eine Zcash-Wallet kann viele Konten enthalten, jedes mit eigenen Viewing Keys. Die Offenlegung ist auf das Konto begrenzt, also leg die Aktivität, die du offenlegen willst, in ein eigenes Konto.

• Buchhaltung und Steuern. Teile den Full Viewing Key deines Geschäftskontos mit deinem Buchhalter. Er sieht jede ein- und ausgehende Zahlung mit Beträgen und Memos. Dein privates Konto, das separat in derselben Wallet liegt, bleibt privat.
• Prüfung. Ein Wirtschaftsprüfer kann die geschützten Bestände und Geldflüsse einer Organisation anhand eines Full Viewing Keys verifizieren, mit den oben beschriebenen Garantien und ohne dass irgendeine Aktivität öffentlich wird.
• Händler und Zahlungsüberwachung. Ein Shop, der ZEC akzeptiert, kann seinen Server zur Zahlungserkennung allein mit einem Incoming Viewing Key betreiben. Der Server sieht jede Kundenzahlung und jedes Memo und kann so Bestellungen zuordnen, und nichts auf diesem Server könnte jemals die Einnahmen ausgeben. Weil der Incoming Key keine Ausgaben sieht, ist er für diese Aufgabe der richtige Schlüssel und für die Ermittlung eines Kontostands der falsche.
• Gemeinnützige Organisationen und öffentliche Transparenz. Einen Viewing Key zu veröffentlichen ist möglich, aber damit wird jeder Spendenbetrag und jedes Memo veröffentlicht, und ein Full Viewing Key würde zusätzlich jede ausgehende Zahlung öffentlich machen. Ein Projekt, das das möchte, sollte ein eigens dafür angelegtes Konto nutzen und den Incoming Key bevorzugen.

Die Privatsphäre-Risiken beim Teilen eines Viewing Keys

Weil „er kann nichts ausgeben“ stimmt, unterschätzt man leicht, was ein Viewing Key preisgibt. Konkret kann jemand, der den Viewing Key deines Kontos hat, Folgendes sehen:

• jede eingehende Zahlung mit Betrag und Memo, an jede Adresse des Kontos;
• jede deiner Empfangsadressen und die Tatsache, dass sie alle zum selben Konto gehören, was den Sinn zunichtemacht, jedem Kontakt eine neue Adresse zu geben;
• mit einem Full Viewing Key jede Ausgabe: wann sie stattfand und, bei Transaktionen von einer Wallet, die dem Standardverhalten des Protokolls folgt, die Adresse des Empfängers, den Betrag und das Memo, das du geschrieben hast;
• deinen Kontostand, mit einem Full Viewing Key;
• deine transparenten Adressen, falls das Konto einen transparenten Receiver hat, verknüpft mit der oben genannten geschützten Aktivität;
• den gesamten Verlauf des Kontos, zurück bis zu dem Block, in dem es zum ersten Mal genutzt wurde, und alle künftigen Aktivitäten, solange das Konto weiter genutzt wird.

Zwei weitere Punkte sind weniger offensichtlich. Memos enthalten oft die sensibelsten Informationen überhaupt, etwa Rechnungsnummern, Namen oder Nachrichten, und ein Viewing Key liest sie vollständig. Und wer Viewing Keys von mehreren Personen sammelt, kann die Zahlungen zwischen ihnen und ihre gemeinsamen Empfänger sehen – die Offenlegung betrifft also nicht nur dich.

Nichts davon ist ein Fehler; es ist das beabsichtigte Verhalten eines Schlüssels, der für Prüfer gedacht ist. Der Fehler besteht darin, ihn wie eine öffentliche Adresse zu behandeln. Teile ihn über einen privaten Kanal, teile den engsten Schlüssel, der die Aufgabe erfüllt, nutze eigens dafür angelegte Konten und notiere dir, wer welchen Schlüssel hat.

Kann man einen Zcash Viewing Key widerrufen?

Nein. Es gibt keinen Protokollmechanismus, der einen Viewing Key ungültig macht, nachdem er geteilt wurde. Der Schlüssel wird aus dem eigenen geheimen Material des Kontos abgeleitet, und jeder, der ihn hat, kann die Blockchain unbegrenzt weiter scannen.

Zwei Dinge helfen nicht:

• Eine neue Adresse im selben Konto erzeugen. Jede Adresse, die ein Konto erzeugt, teilt sich dieselben Viewing Keys. Eine neue diversifizierte Adresse ist für den Inhaber genauso sichtbar wie die alte.
• Deine Kopie löschen. Die Blöcke sind öffentlich; jeder mit dem Schlüssel kann die Aktivität des Kontos jederzeit daraus entschlüsseln.

Die einzige echte Abhilfe ist, das Konto nicht mehr zu nutzen. Lege ein neues Konto an, das eine völlig neue Einsichtsberechtigung hat, und verschiebe deine Gelder dorthin. Sei dir im Klaren darüber, was das bewirkt und was nicht:

• Der Umzug selbst ist eine Ausgabe vom alten Konto, daher sieht der Inhaber des alten Full Viewing Keys ihn, einschließlich des Betrags und im Standardfall der Zieladresse.
• Alles, was vor dem Umzug im alten Konto passiert ist, bleibt für den Inhaber für immer lesbar. Eine Offenlegung der Vergangenheit lässt sich nicht rückgängig machen.
• Die Aktivität im neuen Konto bleibt vor dem Inhaber des alten Schlüssels verborgen, sofern die Schlüssel des neuen Kontos nie mit ihm geteilt werden.

Wenn du befürchtest, dass deine Seed-Phrase selbst geleakt sein könnte, und nicht nur ein Viewing Key, den du herausgegeben hast, behandle das als Kompromittierung des Spending Keys: Verschiebe die Gelder in eine Wallet, die aus einer neuen Seed-Phrase erzeugt wurde, nicht nur in ein neues Konto unter der alten Seed-Phrase.

Sapling, Orchard und Ironwood

Zcash hatte mehrere geschützte Protokolle. Zwei sind heute für Viewing Keys relevant, und ein dritter Pool verwendet eines davon wieder:

• Sapling (2018) führte das oben beschriebene Viewing-Key-Design und das Full-Viewing-Key-Format zxviews1… ein.
• Orchard (2022) behielt dieselbe Idee bei, mit einer neu gestalteten internen Struktur. Seine Schlüssel sind das, was ein Unified Viewing Key für den Orchard-Receiver enthält.
• Ironwood, der mit dem NU6.3-Upgrade eingeführte Pool, basiert auf dem Orchard-Protokoll. Er bringt keine neue Kategorie von Viewing Keys mit: Dieselben Orchard-Protokoll-Viewing-Keys erkennen und entschlüsseln Notes im Ironwood-Pool, und neue Zahlungen an den Orchard-Receiver einer bestehenden Unified Address werden in den Ironwood-Pool geleitet. Dein bestehender uview1…-Schlüssel funktioniert während der Migration von Orchard zu Ironwood weiter, und sein Inhaber sieht die Migrationstransaktionen wie jede andere Aktivität. Der Pool ist seit Block 3.428.143 im Mainnet aktiv; die Wallet-seitigen Spezifikationen für die Migration, ZIP 318 und ZIP 326, sind noch als Draft markiert. Den aktuellen Stand findest du im Network Upgrade Tracker.

Für normale Nutzer übernimmt die Wallet die Unterschiede zwischen den Pools vollständig.

Viewing Keys vs. Payment Disclosures

Manchmal wird nach einem Viewing Key gefragt, obwohl eigentlich ein Nachweis für eine einzelne Zahlung gewünscht ist. Das sind unterschiedliche Werkzeuge:

• Ein Viewing Key ist ein dauerhafter Lesezugriff auf ein Konto. Er ist das falsche Instrument, um eine einzelne Zahlung nachzuweisen, weil er auch alles andere offenlegt.
• Eine Payment Disclosure ist ein vorgeschlagener Mechanismus, um Fakten über eine bestimmte geschützte Zahlung nachzuweisen, etwa „diese Transaktion hat diesen Betrag an diese Adresse gezahlt“, ohne die anderen Adressen oder Transaktionen des Absenders offenzulegen. Sie ist in ZIP 311 spezifiziert, das weiterhin ein Draft ist, und keine allgemein verfügbare Funktion heutiger Wallets.

In der Zwischenzeit können der Wallet-Eintrag des Empfängers, eine Transaktions-ID und ein Memo je nach Kontext ein nützlicher praktischer Nachweis zwischen den beiden Parteien sein. Sie sind aber kein Ersatz für eine Payment Disclosure: Eine Transaktions-ID allein beweist einem Außenstehenden nichts über Empfänger oder Betrag einer geschützten Zahlung, und keines dieser Hilfsmittel bietet die kryptografischen Garantien, die ZIP 311 liefern soll. Exportiere keinen Viewing Key als „Verifizierungsschritt“ für eine einzelne Zahlung, und sei misstrauisch gegenüber jedem, der dich darum bittet.

Welche Zcash-Wallets unterstützen Viewing Keys?

Das Protokoll unterstützt Viewing Keys überall; die einzelnen Wallets entscheiden, ob sie Export und Import anbieten. Zuletzt geprüft: September 2026, anhand des Quellcodes der jeweiligen Projekte:

• Zkool kann ein View-only-Konto aus einem Unified Viewing Key (vollständig oder teilweise), aus einem älteren Sapling Extended Viewing Key oder aus einem transparenten Extended Public Key anlegen und den Unified Full Viewing Key eines Kontos mit wählbaren Pools exportieren. Zkool ist im ZecZcash-Wallet-Verzeichnis gelistet.
• zingo-cli (die Kommandozeilen-Wallet von zingolib) kann aus einem UFVK mit einer Birthday Height eine Watch-only-Wallet anlegen.
• Zallet, die Wallet für Node-Betreiber und Nachfolgerin der zcashd-Wallet, ist in der Beta. Sie kann den Full Viewing Key für eine Sapling- oder Unified Address exportieren oder, per Option, den Unified Incoming Viewing Key des Kontos, und sie kann Sapling Extended Full Viewing Keys als View-only-Konten importieren. Der Import von Unified Viewing Keys ist geplant, aber noch nicht verfügbar. Eine Feinheit aus ihrer eigenen Dokumentation: Der exportierte Incoming Key gilt für das gesamte Konto, er gewährt also Einblick in eingehende Zahlungen für jeden Pool des Kontos, selbst wenn du nur nach einer einzelnen Sapling-Adresse gefragt hast.

Die Unterstützung in anderen Consumer-Wallets ändert sich häufig; prüfe die aktuellen Release Notes der Wallet statt eines älteren Guides. Anleitungen, die mit zcash-cli z_exportviewingkey beginnen, beziehen sich auf zcashd, dessen Support im Juli 2026 endete; die aktuellen Entsprechungen finden sich in Zallet und in den oben genannten Wallets.

Technische Details für Fortgeschrittene

Alles oben Gesagte gilt auch ohne diesen Abschnitt. Für alle, die die zugrunde liegende Struktur kennenlernen möchten:

• Schlüsselkomponenten. Ein Sapling Full Viewing Key besteht aus einem Spend Validating Key, einem Nullifier Deriving Key und einem Outgoing Viewing Key; der Incoming Viewing Key wird aus den ersten beiden abgeleitet. Ein Orchard Full Viewing Key besteht aus einem Spend Validating Key, einem Nullifier Deriving Key und einem Randomiser, aus dem Incoming Viewing Key, Outgoing Viewing Key und Diversifier Key abgeleitet werden.
• ivk, ovk, fvk. Der Incoming Viewing Key (ivk) entschlüsselt testweise die Note-Ciphertexte, die an das Konto adressiert sind. Der Outgoing Viewing Key (ovk) entschlüsselt die Kopie jedes Outputs, die eine Standard-Wallet beim Ausgeben an sich selbst verschlüsselt; so erfährt ein Full Viewing Key Empfänger und Beträge ausgehender Zahlungen. Nullifier, abgeleitet mit dem Nullifier Deriving Key, ermöglichen es einem Full Viewing Key, Ausgaben zu erkennen.
• Diversifizierte Adressen. Ein Schlüsselsatz ergibt eine riesige Zahl nicht verknüpfbarer Empfangsadressen (bis zu etwa 2^87 bei Sapling, 2^88 bei Orchard). Für Außenstehende sind sie nicht verknüpfbar, für jeden mit dem Incoming Viewing Key des Kontos aber trivial verknüpfbar. Deshalb hilft Adressrotation nicht gegen den Inhaber eines Viewing Keys.
• Externer und interner Scope. Jedes Konto hat einen externen Schlüsselsatz für Adressen, die du herausgibst, und einen internen Satz für Wechselgeld und Auto-Shielding. Ein Full Viewing Key leitet beide ab. Ein externer Incoming Viewing Key kann weder den internen noch einen Outgoing Viewing Key ableiten.
• ZIP-32-Konten. Wallets leiten geschützte Schlüssel aus einem Seed entlang des Pfads m/32'/133'/account' ab, mit einem entsprechenden transparenten Pfad nach BIP 44. Das „Konto“ ist die Einheit, an die Viewing Keys und damit die Offenlegung gebunden sind.
• Kodierung von Unified Keys. Ein UFVK ist ein Bech32m-String mit einem Element pro Receiver-Typ in fester Reihenfolge und einem Jumbling-Schritt, der verhindert, dass ein Schlüssel teilweise verändert wird. Das transparente Element ist der Public Key auf Kontoebene, weshalb ein UFVK sowohl externe als auch Wechselgeld-Adressen im transparenten Bereich beobachten kann; der UIVK enthält nur den Schlüssel der externen Kette. ZIP 316 Revision 0 ist der aktive Standard; ein Entwurf für Revision 2 schlägt neue Präfixe (uvf, uvi, zu, tu), Ablauf-Metadaten und Multisig-Elemente vor, von denen zum Zeitpunkt der Erstellung nichts im Einsatz ist.
• Schlüsselableitung bei Ironwood. ZIP 2005 (Proposed) definiert eine Option use_qsk für Konten der Ironwood-Ära, die ändert, wie deren Orchard-Protokoll-Viewing-Keys und Adressen abgeleitet werden, und ZIP 326 (Draft) beschreibt, wie Wallets nach solchen Konten scannen. Das betrifft neue Konten und Wallet-Entwickler, nicht die Bedeutung von Viewing Keys für Nutzer.

Quellen und Methodik

Dieser Guide basiert auf der direkten Prüfung der primären Spezifikationen und des öffentlichen Quellcodes der Wallet-Projekte, Stand September 2026. Technische Aussagen stammen aus der Zcash Protocol Specification (Schlüsselkomponenten und Entschlüsselung von Notes), ZIP 32: Shielded Hierarchical Deterministic Wallets (Final), ZIP 310: Security Properties of Sapling Viewing Keys (Draft, Informational), ZIP 311: Zcash Payment Disclosures (Draft), ZIP 316: Unified Addresses and Unified Viewing Keys (Revision 0 Active, Revision 2 Draft), den NU6.3-Wallet-ZIPs ZIP 318 und ZIP 326 (Draft) sowie ZIP 2005 (Proposed). Die Angaben zur Wallet-Unterstützung wurden anhand des Zallet-Repositorys (Changelog, Book und RPC-Quellcode bei v0.1.0-beta.3), des Zkool-Repositorys (v6.31.0) und des zingolib-Repositorys überprüft. Wallets, deren Unterstützung sich nicht im eigenen Quellcode bestätigen ließ, sind hier nicht aufgeführt. Was die öffentliche Blockchain ohne Schlüssel zeigt und was nicht, siehst du im ZecZcash Explorer; zu den Wallets selbst siehe das Wallet-Verzeichnis und, falls bei einem View-only-Setup etwas schiefgeht, Zcash-Wallet-Probleme lösen.