Ich habe Phoenix zunächst ins Visier genommen, weil es die deutlichste Datenschutzrichtung von Dusk verkörpert. Doch nach tiefergehender Recherche zu DuskDS, Zedger und der gesamten Entwurfslogik habe ich erkannt, dass es vor allem diskussionswürdig ist, wie es den langfristig bestehenden Widerspruch im On-Chain-Finanzwesen handhabt: Vermögenswerte müssen verifiziert werden, aber das bedeutet nicht, dass alle Informationen offengelegt werden müssen.
Wenn der Status von Vermögenswerten und Transaktionsinformationen vollständig transparent wären, könnten sensible Informationen innerhalb finanzieller Assets möglicherweise nicht geschützt werden; wenn Informationen vollständig verborgen wären, wäre es wiederum schwer, die Anforderungen an Compliance und Verifizierbarkeit in realen Finanzprozessen zu erfüllen. Dusk verfolgt daher den Ansatz, unterschiedliche Bedürfnisse zu trennen und verschiedene Module unterschiedliche Aufgaben übernehmen zu lassen.
Moonlight nutzt ein öffentliches account-basiertes Modell, sodass Kontostatus, Guthaben und Überweisungsinformationen öffentlich verifizierbar sind; Phoenix hingegen nutzt ein shielded note Modell: Durch Zero-Knowledge-Beweise wird die Gültigkeit der Transaktion, die ausreichende Deckung sowie das Fehlen von Double-Spends verifiziert – und gleichzeitig bleiben sensible Transaktionsinformationen geschützt.
Das wirklich Spannende an Dusk ist, dass es nicht versucht, mit einem einzigen Transaktionsmuster alle Probleme zu lösen. Phoenix konzentriert sich hauptsächlich auf private Transaktionen, Zedger eher auf Szenarien der Emission und Verwaltung von Vermögenswerten unter Regeln, und XSC liefert standardisierte Designs für Smart Contracts, die sowohl Datenschutz als auch Compliance-Bedingungen erfüllen müssen. Die drei stehen nicht einfach in einem Austauschverhältnis, sondern übernehmen in verschiedenen Finanzbedarfsfällen eine Arbeitsteilung.
Wenn man die gesamte Architektur zusammenspannt, übernimmt DuskDS Konsens, Abwicklung, Datenverfügbarkeit und das Transaktionsmodell; DuskEVM stellt eine EVM-kompatible Ausführungsumgebung bereit und liefert damit die Grundlage für Anwendungen. Das lässt mich Dusk eher wie den Aufbau einer Infrastruktur für Finanzanwendungen sehen – und nicht nur wie das Hinzufügen einer einzelnen Datenschutzfunktion.
Bis hierhin verändert sich auch mein Verständnis des Begriffs „Datenschutz“. Finanzdatenschutz bedeutet nicht, dass alle Informationen verschwinden, sondern dass Informationen nach Regeln fließen: Welche Inhalte müssen öffentlich verifiziert werden, welche müssen geschützt bleiben und welche unter bestimmten Bedingungen offengelegt werden können.
Wenn ich mir das jetzt also erneut anschaue bei $DUSK , geht es für mich nicht mehr nur darum, dass es über Datenschutzntechnologien verfügt, sondern darum, wie es Datenschutztransaktionen, öffentliche Verifizierbarkeit und die Anforderungen an Finanzassets in derselben Architektur zusammenbringt und löst.
#dusk $DUSK @Dusk
Wenn der Status von Vermögenswerten und Transaktionsinformationen vollständig transparent wären, könnten sensible Informationen innerhalb finanzieller Assets möglicherweise nicht geschützt werden; wenn Informationen vollständig verborgen wären, wäre es wiederum schwer, die Anforderungen an Compliance und Verifizierbarkeit in realen Finanzprozessen zu erfüllen. Dusk verfolgt daher den Ansatz, unterschiedliche Bedürfnisse zu trennen und verschiedene Module unterschiedliche Aufgaben übernehmen zu lassen.
Moonlight nutzt ein öffentliches account-basiertes Modell, sodass Kontostatus, Guthaben und Überweisungsinformationen öffentlich verifizierbar sind; Phoenix hingegen nutzt ein shielded note Modell: Durch Zero-Knowledge-Beweise wird die Gültigkeit der Transaktion, die ausreichende Deckung sowie das Fehlen von Double-Spends verifiziert – und gleichzeitig bleiben sensible Transaktionsinformationen geschützt.
Das wirklich Spannende an Dusk ist, dass es nicht versucht, mit einem einzigen Transaktionsmuster alle Probleme zu lösen. Phoenix konzentriert sich hauptsächlich auf private Transaktionen, Zedger eher auf Szenarien der Emission und Verwaltung von Vermögenswerten unter Regeln, und XSC liefert standardisierte Designs für Smart Contracts, die sowohl Datenschutz als auch Compliance-Bedingungen erfüllen müssen. Die drei stehen nicht einfach in einem Austauschverhältnis, sondern übernehmen in verschiedenen Finanzbedarfsfällen eine Arbeitsteilung.
Wenn man die gesamte Architektur zusammenspannt, übernimmt DuskDS Konsens, Abwicklung, Datenverfügbarkeit und das Transaktionsmodell; DuskEVM stellt eine EVM-kompatible Ausführungsumgebung bereit und liefert damit die Grundlage für Anwendungen. Das lässt mich Dusk eher wie den Aufbau einer Infrastruktur für Finanzanwendungen sehen – und nicht nur wie das Hinzufügen einer einzelnen Datenschutzfunktion.
Bis hierhin verändert sich auch mein Verständnis des Begriffs „Datenschutz“. Finanzdatenschutz bedeutet nicht, dass alle Informationen verschwinden, sondern dass Informationen nach Regeln fließen: Welche Inhalte müssen öffentlich verifiziert werden, welche müssen geschützt bleiben und welche unter bestimmten Bedingungen offengelegt werden können.
Wenn ich mir das jetzt also erneut anschaue bei $DUSK , geht es für mich nicht mehr nur darum, dass es über Datenschutzntechnologien verfügt, sondern darum, wie es Datenschutztransaktionen, öffentliche Verifizierbarkeit und die Anforderungen an Finanzassets in derselben Architektur zusammenbringt und löst.
#dusk $DUSK @Dusk