Während ich das Whitepaper gelesen habe, ist mir diese Frage die ganze Zeit im Kopf herumgegangen. Dusk hat die größte Erzählung von Datenschutz und Compliance – beides will ich haben, aber meine bisherigen Erfahrungen zeigen: So etwas kommt meist bei beiden Seiten nicht gut an. #dusk
Schauen wir uns das Gegenbeispiel an. Zcash und Monero haben beim Datenschutz das Extrem erreicht, aber die Aufsichtsbehörden akzeptieren es nicht; Börsen haben sie aus dem Handel genommen, die Liquidität ist geschrumpft. Ethereum und Bitcoin haben bei der Compliance keine Probleme, aber die Transaktionen sind komplett transparent. Wenn eine Institution eine große Transaktion macht, kann der Counterparties alles auf einen Blick sehen. Dusk behauptet, es habe den dritten Weg gefunden – anfangs war ich skeptisch. @Dusk
Der im Whitepaper beschriebene Ansatz ist ein Zwei-Transaktionsmodell plus das Zedger-Protokoll. Moonlight ist für Compliance-Szenarien gedacht, Phoenix für Datenschutz-Szenarien, und Zedger sorgt dafür, dass Smart Contracts im verschlüsselten/konfidentiellen Zustand ausgeführt werden, während gleichzeitig die Nachprüfbarkeit erhalten bleibt. Theoretisch könnte diese Architektur tatsächlich funktionieren.
Aber nachdem ich es zu Ende gelesen hatte, habe ich eine entscheidende Lücke entdeckt. Das Whitepaper sagt, dass Aufsichtsbehörden auf die notwendigen Daten zugreifen können – aber es bleibt offen, wie genau sie darauf zugreifen, über welche Mechanismen die Autorisierung erfolgt, wer die Schlüssel verwaltet und wie die Zugriffsrechte wieder entzogen werden. Bei einem auditierbaren Datenschutzharness ist das Schwierigste nicht, den Aufsichtsbehörden Daten zugänglich zu machen, sondern sicherzustellen, dass die Daten nur von denjenigen gesehen werden, die sie sehen sollen – und nur für den autorisierten Zeitraum.
Ich habe das gedanklich weitergesponnen. Wenn Dusk ein Beweissystem ähnlich wie zk-SNARK verwendet, bei dem die Aufsichtsbehörden einen bestimmten Audit-Schlüssel besitzen, $DUSK die Compliance einer Transaktion verifizieren kann, ohne die Privatsphäre der Nutzer offenzulegen, dann wäre dieses Konzept grundsätzlich tragfähig. Aber wenn Aufsichtsrechte missbraucht werden oder der Schlüssel kompromittiert wird, bricht das Gebäude des Datenschutzes zusammen.
Daher ist mein Fazit: Dass Datenschutz und Compliance gleichzeitig existieren können, klingt im Prinzip plausibel und ist im Engineering womöglich umsetzbar – aber die tatsächliche Wirkung hängt vollständig von den Details der Mechanismen zur Kontrolle von Berechtigungen ab. Und da das Whitepaper diese Details derzeit nicht liefert, muss ich auf weitere technische Dokumentation warten, bevor ich urteilen kann. Die Antwort auf diese Frage liegt nicht im Whitepaper, sondern im Code des Mainnets.
Schauen wir uns das Gegenbeispiel an. Zcash und Monero haben beim Datenschutz das Extrem erreicht, aber die Aufsichtsbehörden akzeptieren es nicht; Börsen haben sie aus dem Handel genommen, die Liquidität ist geschrumpft. Ethereum und Bitcoin haben bei der Compliance keine Probleme, aber die Transaktionen sind komplett transparent. Wenn eine Institution eine große Transaktion macht, kann der Counterparties alles auf einen Blick sehen. Dusk behauptet, es habe den dritten Weg gefunden – anfangs war ich skeptisch. @Dusk
Der im Whitepaper beschriebene Ansatz ist ein Zwei-Transaktionsmodell plus das Zedger-Protokoll. Moonlight ist für Compliance-Szenarien gedacht, Phoenix für Datenschutz-Szenarien, und Zedger sorgt dafür, dass Smart Contracts im verschlüsselten/konfidentiellen Zustand ausgeführt werden, während gleichzeitig die Nachprüfbarkeit erhalten bleibt. Theoretisch könnte diese Architektur tatsächlich funktionieren.
Aber nachdem ich es zu Ende gelesen hatte, habe ich eine entscheidende Lücke entdeckt. Das Whitepaper sagt, dass Aufsichtsbehörden auf die notwendigen Daten zugreifen können – aber es bleibt offen, wie genau sie darauf zugreifen, über welche Mechanismen die Autorisierung erfolgt, wer die Schlüssel verwaltet und wie die Zugriffsrechte wieder entzogen werden. Bei einem auditierbaren Datenschutzharness ist das Schwierigste nicht, den Aufsichtsbehörden Daten zugänglich zu machen, sondern sicherzustellen, dass die Daten nur von denjenigen gesehen werden, die sie sehen sollen – und nur für den autorisierten Zeitraum.
Ich habe das gedanklich weitergesponnen. Wenn Dusk ein Beweissystem ähnlich wie zk-SNARK verwendet, bei dem die Aufsichtsbehörden einen bestimmten Audit-Schlüssel besitzen, $DUSK die Compliance einer Transaktion verifizieren kann, ohne die Privatsphäre der Nutzer offenzulegen, dann wäre dieses Konzept grundsätzlich tragfähig. Aber wenn Aufsichtsrechte missbraucht werden oder der Schlüssel kompromittiert wird, bricht das Gebäude des Datenschutzes zusammen.
Daher ist mein Fazit: Dass Datenschutz und Compliance gleichzeitig existieren können, klingt im Prinzip plausibel und ist im Engineering womöglich umsetzbar – aber die tatsächliche Wirkung hängt vollständig von den Details der Mechanismen zur Kontrolle von Berechtigungen ab. Und da das Whitepaper diese Details derzeit nicht liefert, muss ich auf weitere technische Dokumentation warten, bevor ich urteilen kann. Die Antwort auf diese Frage liegt nicht im Whitepaper, sondern im Code des Mainnets.