Das Netzwerk ist in „Auditor-Zugriff“ eingetaucht, weil das in jedem Privacy-Coin-Pitch meistens der vage Teil ist. Ich wollte den eigentlichen Mechanismus, nicht die Formulierung.
Dusk betreibt zwei Transaktionsmodelle parallel: Moonlight (vollständig öffentlich, wie ein normales Kontomodell) und Phoenix (geschützt, vertrauliche Salden/Überweisungen). Pro Transaktion wählt man eines davon. Das ist unkompliziert.
Der Teil, mit dem ich nicht gerechnet hatte: Die Offenlegung gegenüber einem Auditor ist nicht „der Auditor bekommt einen Master Key für alles“. Laut Dusk's eigenem Write-up verschlüsselt ein Nutzer zuerst die Transaktionsdaten (Payload) mit einem Nutzer-Key und verschlüsselt dann diesen Nutzer-Key mit dem Key des Auditors – sodass nur der konkrete Auditor ihn entschlüsseln kann. Ein Zero-Knowledge-Proof bestätigt anschließend, dass der Auditor-Key tatsächlich korrekt verwendet wurde, ohne dass der Payload für irgendwen sichtbar wird, der die Kette verifiziert.
Das ist also eine transaktionsweise, schlüssel-spezifische Offenlegung – kein Hintertürchen, das im ganzen System steckt. Kein Auditor-Key = kein Zugriff, Ende der Geschichte, sogar für die eigenen Validatoren des Netzwerks.
Die Lücke, die ich nicht vollständig schließen konnte: Die Doku beschreibt das auf der Citadel-Identitätsebene, aber ich habe keinen öffentlichen Fall gefunden, in dem ein Regulierer tatsächlich Daten über diesen Ablauf auf dem Mainnet abgeholt hat. Auf dem Papier wirkt das solide, aber „Auditor entschlüsselt eine Transaktion mittels nachweisbarer Verschlüsselung“ und „tatsächlicher Workflow eines Regulierers während eines Live-Audits“ sind zwei verschiedene Tests.
Hat das schon jemand in einem realen Compliance-Szenario gesehen – nicht nur als Fähigkeit dokumentiert?
#dusk $DUSK #dusk $DUSK
Dusk betreibt zwei Transaktionsmodelle parallel: Moonlight (vollständig öffentlich, wie ein normales Kontomodell) und Phoenix (geschützt, vertrauliche Salden/Überweisungen). Pro Transaktion wählt man eines davon. Das ist unkompliziert.
Der Teil, mit dem ich nicht gerechnet hatte: Die Offenlegung gegenüber einem Auditor ist nicht „der Auditor bekommt einen Master Key für alles“. Laut Dusk's eigenem Write-up verschlüsselt ein Nutzer zuerst die Transaktionsdaten (Payload) mit einem Nutzer-Key und verschlüsselt dann diesen Nutzer-Key mit dem Key des Auditors – sodass nur der konkrete Auditor ihn entschlüsseln kann. Ein Zero-Knowledge-Proof bestätigt anschließend, dass der Auditor-Key tatsächlich korrekt verwendet wurde, ohne dass der Payload für irgendwen sichtbar wird, der die Kette verifiziert.
Das ist also eine transaktionsweise, schlüssel-spezifische Offenlegung – kein Hintertürchen, das im ganzen System steckt. Kein Auditor-Key = kein Zugriff, Ende der Geschichte, sogar für die eigenen Validatoren des Netzwerks.
Die Lücke, die ich nicht vollständig schließen konnte: Die Doku beschreibt das auf der Citadel-Identitätsebene, aber ich habe keinen öffentlichen Fall gefunden, in dem ein Regulierer tatsächlich Daten über diesen Ablauf auf dem Mainnet abgeholt hat. Auf dem Papier wirkt das solide, aber „Auditor entschlüsselt eine Transaktion mittels nachweisbarer Verschlüsselung“ und „tatsächlicher Workflow eines Regulierers während eines Live-Audits“ sind zwei verschiedene Tests.
Hat das schon jemand in einem realen Compliance-Szenario gesehen – nicht nur als Fähigkeit dokumentiert?
#dusk $DUSK #dusk $DUSK