Hängt den Kontoauszug in der Filiale an die Wand—niemand würde das „vertrauenswürdiges Finanzwesen“ nennen. Doch bei einer Public Chain bleiben Guthaben, Überweisungen und Gegenparteien langfristig unverschleiert, werden aber oft als „transparent“ verpackt. Als ich gestern weiter die Dusk-Dokumente zerlegte, stellte ich fest, dass es dabei nicht darum geht, dass alle Informationen verschwinden, sondern darum, „wer welche Informationen sehen darf“ in das Protokoll zu schreiben.
Das Phoenix-Modell mit <b>@Dusk </b> macht das Geld zu verschlüsselten Notes: Ein normaler Beobachter kann Überweisungsbeträge, die Sende-Beziehung und die konkreten Notes nicht sehen, aber die Transaktion muss weiterhin mittels Zero-Knowledge beweisen, dass das Guthaben ausreicht und keine Doppelbuchung (Double Spend) vorliegt. Am leichtesten wird das missverstanden, wenn man „selektive Offenlegung“ so versteht, als würde man Aufsehern ein Allzweck-Schlüsselchen einbauen, mit dem man auf das gesamte Kontenbuch im Netz zugreifen kann. In Wahrheit ermöglicht es relevanten Nutzern, durch das Überprüfen von Schlüsseln gezielt einen bestimmten Informationsbereich an ausstellende Stellen, Orte oder Auditoren zu übergeben, die eine Verifikation benötigen. Öffentliche Verifikation sorgt dafür, dass die Regeln nicht gebrochen werden; kontrollierte Offenlegung beantwortet die Frage nach Verantwortung in der realen Welt.
Die Identitätsschicht Citadel von Dusk treibt das Ganze noch einen Schritt weiter. Nutzer müssen nicht bei jeder Einreichung vollständige Ausweisdokumente vorlegen, sondern können nachweisen, dass „der Wohnsitz den Anforderungen entspricht“, „das Alter passt“ oder „es liegt die Qualifikation eines zugelassenen Anlegers vor“—also bestimmte Attribute. Die Service-Seite erhält dann die Antwort auf die Frage, ob Zugang gewährt wird, und muss nicht unbedingt die gesamte Identitätsakte abgreifen. Anders gesagt: Das System versucht, die in klassischem KYC übertriebene Gewohnheit des Sammelns personenbezogener Daten zu verkleinern und auf eine einzige, minimal notwendige Bestätigung zu komprimieren.
Doch selektive Offenlegung ist nicht von Natur aus gleichbedeutend mit Sicherheit. Das eigentliche Problem ist: Wer verwahrt die Schlüssel, wie lange darf man sie einsehen, wie wird mit einer etwaigen Leckage umgegangen, und können unterschiedliche Institutionen nur die Daten erhalten, die in ihren Aufgabenbereich fallen? Wenn eine Anwendung aus Bequemlichkeit die Schlüssel dauerhaft zentral speichert, kann selbst ein noch so hübscher kryptografischer Schutz am Ende erneut ein äußerst wertvolles Daten-Repository entstehen lassen.
Darum ist mein Urteil über Dusk heute konkreter: Seine Schutzmauer ist nicht nur „Verbergen zu können“, sondern sicherzustellen, dass Offenlegungsrechte fein genug, ausreichend auditierbar und zugleich auch noch gut nutzbar ausgestaltet sind. Zukünftig sollte nicht die Anzahl privater Transaktionen an sich im Mittelpunkt stehen, sondern wie viele echte Finanzprozesse sich erfolgreich verifizieren lassen, ohne dass dabei alle Daten offengelegt werden müssen.
<b>$DUSK </b> <b>#dusk </b>
Das Phoenix-Modell mit <b>@Dusk </b> macht das Geld zu verschlüsselten Notes: Ein normaler Beobachter kann Überweisungsbeträge, die Sende-Beziehung und die konkreten Notes nicht sehen, aber die Transaktion muss weiterhin mittels Zero-Knowledge beweisen, dass das Guthaben ausreicht und keine Doppelbuchung (Double Spend) vorliegt. Am leichtesten wird das missverstanden, wenn man „selektive Offenlegung“ so versteht, als würde man Aufsehern ein Allzweck-Schlüsselchen einbauen, mit dem man auf das gesamte Kontenbuch im Netz zugreifen kann. In Wahrheit ermöglicht es relevanten Nutzern, durch das Überprüfen von Schlüsseln gezielt einen bestimmten Informationsbereich an ausstellende Stellen, Orte oder Auditoren zu übergeben, die eine Verifikation benötigen. Öffentliche Verifikation sorgt dafür, dass die Regeln nicht gebrochen werden; kontrollierte Offenlegung beantwortet die Frage nach Verantwortung in der realen Welt.
Die Identitätsschicht Citadel von Dusk treibt das Ganze noch einen Schritt weiter. Nutzer müssen nicht bei jeder Einreichung vollständige Ausweisdokumente vorlegen, sondern können nachweisen, dass „der Wohnsitz den Anforderungen entspricht“, „das Alter passt“ oder „es liegt die Qualifikation eines zugelassenen Anlegers vor“—also bestimmte Attribute. Die Service-Seite erhält dann die Antwort auf die Frage, ob Zugang gewährt wird, und muss nicht unbedingt die gesamte Identitätsakte abgreifen. Anders gesagt: Das System versucht, die in klassischem KYC übertriebene Gewohnheit des Sammelns personenbezogener Daten zu verkleinern und auf eine einzige, minimal notwendige Bestätigung zu komprimieren.
Doch selektive Offenlegung ist nicht von Natur aus gleichbedeutend mit Sicherheit. Das eigentliche Problem ist: Wer verwahrt die Schlüssel, wie lange darf man sie einsehen, wie wird mit einer etwaigen Leckage umgegangen, und können unterschiedliche Institutionen nur die Daten erhalten, die in ihren Aufgabenbereich fallen? Wenn eine Anwendung aus Bequemlichkeit die Schlüssel dauerhaft zentral speichert, kann selbst ein noch so hübscher kryptografischer Schutz am Ende erneut ein äußerst wertvolles Daten-Repository entstehen lassen.
Darum ist mein Urteil über Dusk heute konkreter: Seine Schutzmauer ist nicht nur „Verbergen zu können“, sondern sicherzustellen, dass Offenlegungsrechte fein genug, ausreichend auditierbar und zugleich auch noch gut nutzbar ausgestaltet sind. Zukünftig sollte nicht die Anzahl privater Transaktionen an sich im Mittelpunkt stehen, sondern wie viele echte Finanzprozesse sich erfolgreich verifizieren lassen, ohne dass dabei alle Daten offengelegt werden müssen.
<b>$DUSK </b> <b>#dusk </b>
