#dusk $DUSK Jemand vergleicht das Privacy-Modell von DUSK mit Tumbler-/Mischer-Tools, und ich finde, dass diese Analogie an sich schon falsch liegt – weil sie das trifft, worauf die Regulierung in Wahrheit nicht achtet. Das Problem, das Mischer lösen, besteht darin, die nachvollziehbare Kette zwischen Geldquelle und -ziel zu unterbrechen. Im Kern geht es darum, dass die Teilnehmerinformationen im System eingeebnet und verschleiert werden, sodass Regulierungs- und Strafverfolgungsbehörden ohne zusätzliche Befugnisse nicht in der Lage sind, einen konkreten Geldpfad zu rekonstruieren. Deshalb werden die meisten Jurisdiktionen Mischer als Hochrisiko einstufen und teils sogar direkt auf Sanktionslisten setzen: $SPCXB
Das Design von Phoenix ist grundsätzlich anders. Die Kombination aus Einwegadressen und Zero-Knowledge-Beweisen macht Transaktionsbeträge und -pfade für externe Beobachter unsichtbar. Jede einzelne Transaktion trägt jedoch weiterhin verifizierbare Legitimitätsnachweise in sich: Der Beleg zeigt, dass es keinen unautorisierten Emissionsüberschuss gibt, keine doppelte Ausgabe erfolgt und die Transaktion den Protokollregeln entspricht. Noch entscheidender: Das Protokoll hält einen Offenlegungs- bzw. Entschlüsselungs-Schlüsselmechanismus vor. Wer den dazugehörigen Schlüssel besitzt, kann im Rahmen eines ordnungsgemäßen Compliance-Verfahrens spezifische Transaktionen entschlüsseln und prüfen lassen – ohne die gesamte Transaktionshistorie öffnen zu müssen. Diese Struktur „standardmäßig verborgen, bei Bedarf beweisbar“ steht in ihren Designzielen im Gegensatz zur Mischer-Struktur „standardmäßig eingeebnet, nicht rekonstruierbar“ und sollte nicht miteinander vermischt werden. $SNDKB
Die eigentliche Bewährungsprobe dieser Mechanik liegt jedoch nicht in der Kryptografie an sich. Die Zero-Knowledge-Proof-Technologie in PlonK ist inzwischen ziemlich ausgereift. Die Herausforderung liegt vielmehr im Governance-Prozess rund um den Offenlegungsschlüssel: Wer verwahrt ihn, welche Art von rechtlichem Verfahren löst eine Entschlüsselung aus, und führt eine einmalige Entschlüsselung dazu, dass auch historische Transaktionen verbundener Adressen offengelegt werden? Diese Details, die derzeit genannt werden, liefern bislang eher nur allgemeine Rahmenbedingungen und es fehlen konkrete Praxisbeispiele. Eine Aussage, ein Protokoll könne bei Regulierungsprüfungen „mitwirken“, und ein echter, einmal durchgeführter End-to-End-Ablauf einer vollständigen Offenlegung im konkreten Rechtsraum können zwischen ihnen einen großen Unterschied haben – das darf man nicht einfach gleichsetzen.
Ich glaube, um zu beurteilen, ob Phoenix wirklich „compliant“ Privacy bietet oder nur eine verdeckte Tool-Nutzung hinter einer Compliance-Fassade versteckt, darf man sich nicht nur am Designwillen orientieren. Entscheidend ist, ob es in einem realen Regulierungsszenario jemals eine verifizierbare Minimal-Offenlegungsoperation tatsächlich erfolgreich umgesetzt hat – das ist das praktische Kriterium, nicht eine Einschätzung auf rein technischer Ebene.
#dusk @Dusk