Die EU DAC8 ist bereits am 1. Januar dieses Jahres in Kraft getreten: Kryptodienstleister, die Berichtspflichten unterliegen, müssen ab 2026 meldepflichtige Transaktionsdaten von EU-Nutzern sammeln; der erste Informationsaustausch soll spätestens am 30. September 2027 abgeschlossen sein. Wenn ich mir diesen Zeitplan anschaue, denke ich eher, dass bei dem Thema Datenschutz nicht darüber diskutiert werden sollte, „kann man etwas verstecken“, sondern „wer kann es sehen und kann man danach damit Geld bewegen“.
Als ich mir das Whitepaper von @Dusk und die aktuellen Dokumente anschaute, fiel mir auf, dass das Design von Phoenix nicht darauf setzt, Transaktionsdetails an irgendeinen zentralisierten Backoffice-Server zu übermitteln. Die Vermögenswerte existieren in Form von kryptografischen notes; in der note sind eine Kryptoöffnung mit Betrag-Verpflichtung, ein einmaliger öffentlicher Schlüssel sowie die verschlüsselte Absenderinformation enthalten. Das Netzwerk kann verifizieren, dass es keine Doppelbuchung gibt und dass der Kontostand ausreicht, aber es muss nicht wissen, welcher konkrete Betrag übertragen wurde oder wie die Transaktion zugeordnet ist.
Noch entscheidender ist der view key. Er ist wie eine Zugangskarte, die man nur durch Glas lesen kann: Verwahrstellen oder Audit-Dienstleister können ihn verwenden, um im Ledger zu scannen und zu erkennen, welche notes zu einem Nutzer gehören, aber weil sie keinen vollständigen privaten Schlüssel erhalten, können sie diese notes nicht direkt ausgeben. Beobachtungsrecht und Verfügungsrecht werden getrennt.
Auch die Berechnung des Beweises lässt sich aufteilen. Das Dusk-Whitepaper sagt, dass Nutzer die Erstellung von ZK-Beweisen an Dritte delegieren können, während sie mit einer Signatur die Integrität der Transaktion wahren. Dieses Bedürfnis ist nicht abwegig: Die minimale Konfiguration, die offizielle Prover-Nodes vorgeben, beträgt mindestens 4 Kerne, einen CPU mit über 2 GHz, 8 GB Speicher, 20 GB Speicherplatz und ein 20-Mbps-Netzwerk; für jeden zusätzlichen worker muss man jeweils weitere 1 Kern, 1 GB, 2 GB und 5 Mbps hinzurechnen. Die Beweisgenerierung frisst viel Rechenleistung, aber der Compute-Provider sollte nicht „nebenbei“ auch die Kontrolle über das Vermögen bekommen.
$DUSK #dusk
Deshalb würde ich die Berechtigungen in vier Teile aufteilen: Der Investor behält das Ausgaberecht; die Verwahrstelle oder der Prüfer erhält das Beobachtungsrecht; der Prover stellt das Rechenrecht bereit; und das Compliance-System prüft nur, ob „die Bedingungen erfüllt sind“. In den Citadel-Dokumenten von Dusk wird das Letztere so beschrieben: Nachweisbarer Wohnort, Altersgruppe oder Qualifikation als zugelassener Investor – ohne zusätzliche Offenlegung von Identitätsdetails.
Das ist keine Magie, um eine KYC-Datenbank zu ersetzen, und auch kein Investitionsgrund. Es schlägt lediglich einen feineren Ansatz vor: Wenn die Regulierung Informationen benötigt, soll man weniger irrelevante Daten liefern und weniger Rechte gewähren, als man eigentlich nicht geben sollte. Was es wirklich weiter zu beobachten gilt, ist, ob diese Grenzen der Rechte in einem echten Verwahr- und Transaktionsprozess sauber funktionieren.
Als ich mir das Whitepaper von @Dusk und die aktuellen Dokumente anschaute, fiel mir auf, dass das Design von Phoenix nicht darauf setzt, Transaktionsdetails an irgendeinen zentralisierten Backoffice-Server zu übermitteln. Die Vermögenswerte existieren in Form von kryptografischen notes; in der note sind eine Kryptoöffnung mit Betrag-Verpflichtung, ein einmaliger öffentlicher Schlüssel sowie die verschlüsselte Absenderinformation enthalten. Das Netzwerk kann verifizieren, dass es keine Doppelbuchung gibt und dass der Kontostand ausreicht, aber es muss nicht wissen, welcher konkrete Betrag übertragen wurde oder wie die Transaktion zugeordnet ist.
Noch entscheidender ist der view key. Er ist wie eine Zugangskarte, die man nur durch Glas lesen kann: Verwahrstellen oder Audit-Dienstleister können ihn verwenden, um im Ledger zu scannen und zu erkennen, welche notes zu einem Nutzer gehören, aber weil sie keinen vollständigen privaten Schlüssel erhalten, können sie diese notes nicht direkt ausgeben. Beobachtungsrecht und Verfügungsrecht werden getrennt.
Auch die Berechnung des Beweises lässt sich aufteilen. Das Dusk-Whitepaper sagt, dass Nutzer die Erstellung von ZK-Beweisen an Dritte delegieren können, während sie mit einer Signatur die Integrität der Transaktion wahren. Dieses Bedürfnis ist nicht abwegig: Die minimale Konfiguration, die offizielle Prover-Nodes vorgeben, beträgt mindestens 4 Kerne, einen CPU mit über 2 GHz, 8 GB Speicher, 20 GB Speicherplatz und ein 20-Mbps-Netzwerk; für jeden zusätzlichen worker muss man jeweils weitere 1 Kern, 1 GB, 2 GB und 5 Mbps hinzurechnen. Die Beweisgenerierung frisst viel Rechenleistung, aber der Compute-Provider sollte nicht „nebenbei“ auch die Kontrolle über das Vermögen bekommen.
$DUSK #dusk
Deshalb würde ich die Berechtigungen in vier Teile aufteilen: Der Investor behält das Ausgaberecht; die Verwahrstelle oder der Prüfer erhält das Beobachtungsrecht; der Prover stellt das Rechenrecht bereit; und das Compliance-System prüft nur, ob „die Bedingungen erfüllt sind“. In den Citadel-Dokumenten von Dusk wird das Letztere so beschrieben: Nachweisbarer Wohnort, Altersgruppe oder Qualifikation als zugelassener Investor – ohne zusätzliche Offenlegung von Identitätsdetails.
Das ist keine Magie, um eine KYC-Datenbank zu ersetzen, und auch kein Investitionsgrund. Es schlägt lediglich einen feineren Ansatz vor: Wenn die Regulierung Informationen benötigt, soll man weniger irrelevante Daten liefern und weniger Rechte gewähren, als man eigentlich nicht geben sollte. Was es wirklich weiter zu beobachten gilt, ist, ob diese Grenzen der Rechte in einem echten Verwahr- und Transaktionsprozess sauber funktionieren.