Ich habe die ganze Nacht nicht geschlafen und das $DUSK Whitepaper studiert, bis zu der Passage über Phoenix’ Note-Struktur. Eine Zeile hat mich sehr lange innehalten lassen.
Das Verschlüsselungsfeld in der Note, enc, wird mit dem View-Key des Empfängers verschlüsselt. Das Whitepaper sagt: Der View Key erlaubt es Nutzern, die Berechtigung zu delegieren, Transaktionen über ein gescanntes Netzwerk zu finden – an einen Dritten. Der Dritte erhält jedoch keinen vollständigen Secret Key, also kann er kein Geld ausgeben.
Ich habe diesen Detailpunkt anfangs nicht wirklich beachtet. Später ist mir klar geworden, dass das im Kern Kryptographie für selektive Offenlegung ist. Dieselben Transaktionsdaten werden mit unterschiedlichen Schlüsseln so kontrolliert, dass verschiedene Zugriffsrechte entstehen.
Im Whitepaper lautet die Definition des View Keys (a, B), der Secret Key ist (a, b). Wenn ein privater Schlüssel-Anteil b fehlt, gibt es eine zusätzliche Sicherheitsebene. Die verschlüsselten Daten der Note können entschlüsselt und eingesehen werden, aber es ist nicht möglich, das zugehörige Nullifier zu generieren, um es auszugeben. Das Wesen dieses Mechanismus ist: Kontrolle und Nutzungsrecht können voneinander getrennt werden.
Für die Öffentlichkeit sind Transaktionen verschlüsselt; ZK-Beweise prüfen nur die Korrektheit, ohne Daten offenzulegen. Für Regulierer kann der Autorisierende, nachdem er den View Key erhalten hat, den konkreten Inhalt der Note entschlüsseln, den Kontostand, den Handelspartner und die Compliance verifizieren – aber ohne die Mittel bewegen zu können. Die offizielle Website mit der Nummer @Dusk sagt, das heiße „controlled visibility for audit, supervision, and regulated disclosure“. Je länger ich es lese, desto treffender finde ich diese Formulierung.
Ein einziges Set kryptographischer Schlüssel löst gleichzeitig zwei scheinbar widersprüchliche Anforderungen: Privatsphäre und Compliance. Die Öffentlichkeit sieht nichts, Regulierer sehen alles, und die Nutzer entscheiden selbst.
#dusk
Aber ganz ehrlich: Ich habe noch nicht vollständig verstanden, wie man diese View-Key-Mechanik in Hedgers EVM-Umgebung ausrichtet. Der View Key im Whitepaper ist für Phoenix’ nativen UTXO-Ansatz entworfen. Hedger nutzt jedoch ein hybrides UTXO-/Kontenmodell. Ob sich die Key-Systeme nahtlos abbilden lassen, habe ich noch keine eindeutige Antwort darauf gefunden.
Das Verschlüsselungsfeld in der Note, enc, wird mit dem View-Key des Empfängers verschlüsselt. Das Whitepaper sagt: Der View Key erlaubt es Nutzern, die Berechtigung zu delegieren, Transaktionen über ein gescanntes Netzwerk zu finden – an einen Dritten. Der Dritte erhält jedoch keinen vollständigen Secret Key, also kann er kein Geld ausgeben.
Ich habe diesen Detailpunkt anfangs nicht wirklich beachtet. Später ist mir klar geworden, dass das im Kern Kryptographie für selektive Offenlegung ist. Dieselben Transaktionsdaten werden mit unterschiedlichen Schlüsseln so kontrolliert, dass verschiedene Zugriffsrechte entstehen.
Im Whitepaper lautet die Definition des View Keys (a, B), der Secret Key ist (a, b). Wenn ein privater Schlüssel-Anteil b fehlt, gibt es eine zusätzliche Sicherheitsebene. Die verschlüsselten Daten der Note können entschlüsselt und eingesehen werden, aber es ist nicht möglich, das zugehörige Nullifier zu generieren, um es auszugeben. Das Wesen dieses Mechanismus ist: Kontrolle und Nutzungsrecht können voneinander getrennt werden.
Für die Öffentlichkeit sind Transaktionen verschlüsselt; ZK-Beweise prüfen nur die Korrektheit, ohne Daten offenzulegen. Für Regulierer kann der Autorisierende, nachdem er den View Key erhalten hat, den konkreten Inhalt der Note entschlüsseln, den Kontostand, den Handelspartner und die Compliance verifizieren – aber ohne die Mittel bewegen zu können. Die offizielle Website mit der Nummer @Dusk sagt, das heiße „controlled visibility for audit, supervision, and regulated disclosure“. Je länger ich es lese, desto treffender finde ich diese Formulierung.
Ein einziges Set kryptographischer Schlüssel löst gleichzeitig zwei scheinbar widersprüchliche Anforderungen: Privatsphäre und Compliance. Die Öffentlichkeit sieht nichts, Regulierer sehen alles, und die Nutzer entscheiden selbst.
#dusk
Aber ganz ehrlich: Ich habe noch nicht vollständig verstanden, wie man diese View-Key-Mechanik in Hedgers EVM-Umgebung ausrichtet. Der View Key im Whitepaper ist für Phoenix’ nativen UTXO-Ansatz entworfen. Hedger nutzt jedoch ein hybrides UTXO-/Kontenmodell. Ob sich die Key-Systeme nahtlos abbilden lassen, habe ich noch keine eindeutige Antwort darauf gefunden.