Ich habe mir Dusk angesehen und dabei mit einem ziemlich einfachen Datenschutzmodell gerechnet: Entweder zeigt eine Blockchain alles, oder sie verbirgt alles.
Doch es stellt sich heraus, dass das differenzierter ist.
Was meine Aufmerksamkeit geweckt hat, ist, wie Dusk Transaktionen behandelt. Moonlight wird für transparente, konto-basierte Aktivitäten verwendet, während Phoenix mit geschützten Notizen und Zero-Knowledge-Beweisen einen anderen Weg einschlägt. Beide werden jedoch über dieselbe DuskDS-Schicht abgewickelt.
Das hat mich innehalten lassen.
Am Anfang dachte ich, Datenschutz sei vor allem eine Wallet-Funktion. Aber die Architektur von Dusk hat mich dazu gebracht, das anders zu betrachten. Datenschutz kann tatsächlich Teil der Art sein, wie die Anwendung arbeitet.
Dann ist da noch die Ausführungskomponente. Dusk trennt Abwicklung von Ausführung: DuskVM unterstützt Rust/WASM-Verträge, und DuskEVM stellt eine EVM-Umgebung bereit.
Damit gibt es unterschiedliche Ausführungspfade, unterschiedliche Transaktionsmodelle und verschiedene Grade an Sichtbarkeit — ohne einfach für jeden Anwendungsfall separate Chains zu erstellen.
Die Idee der selektiven Offenlegung ist ein weiterer Aspekt, den ich interessant fand. Datenschutz bedeutet nicht zwangsläufig, dass niemand jemals irgendetwas verifizieren kann. Es kann auch bedeuten, dass die richtigen Informationen zur richtigen Zeit der richtigen Partei offengelegt werden.
Das wirkt wie ein viel praxisnäheres Problem, das man lösen muss.
Bei $DUSK bin ich weniger daran interessiert, es nur noch „eine Privacy-Chain“ zu nennen. Mich interessiert vielmehr, ob Entwickler diese Flexibilität wirklich nutzen werden, sobald echte Anwendungen und institutionelle Anforderungen ins Spiel kommen.
Wird sich die Architektur in der Praxis als nützlich erweisen, oder werden sich die meisten Nutzer irgendwann auf einen einzigen einfachen Pfad festlegen?
#DUSK @Dusk $DUSK
Doch es stellt sich heraus, dass das differenzierter ist.
Was meine Aufmerksamkeit geweckt hat, ist, wie Dusk Transaktionen behandelt. Moonlight wird für transparente, konto-basierte Aktivitäten verwendet, während Phoenix mit geschützten Notizen und Zero-Knowledge-Beweisen einen anderen Weg einschlägt. Beide werden jedoch über dieselbe DuskDS-Schicht abgewickelt.
Das hat mich innehalten lassen.
Am Anfang dachte ich, Datenschutz sei vor allem eine Wallet-Funktion. Aber die Architektur von Dusk hat mich dazu gebracht, das anders zu betrachten. Datenschutz kann tatsächlich Teil der Art sein, wie die Anwendung arbeitet.
Dann ist da noch die Ausführungskomponente. Dusk trennt Abwicklung von Ausführung: DuskVM unterstützt Rust/WASM-Verträge, und DuskEVM stellt eine EVM-Umgebung bereit.
Damit gibt es unterschiedliche Ausführungspfade, unterschiedliche Transaktionsmodelle und verschiedene Grade an Sichtbarkeit — ohne einfach für jeden Anwendungsfall separate Chains zu erstellen.
Die Idee der selektiven Offenlegung ist ein weiterer Aspekt, den ich interessant fand. Datenschutz bedeutet nicht zwangsläufig, dass niemand jemals irgendetwas verifizieren kann. Es kann auch bedeuten, dass die richtigen Informationen zur richtigen Zeit der richtigen Partei offengelegt werden.
Das wirkt wie ein viel praxisnäheres Problem, das man lösen muss.
Bei $DUSK bin ich weniger daran interessiert, es nur noch „eine Privacy-Chain“ zu nennen. Mich interessiert vielmehr, ob Entwickler diese Flexibilität wirklich nutzen werden, sobald echte Anwendungen und institutionelle Anforderungen ins Spiel kommen.
Wird sich die Architektur in der Praxis als nützlich erweisen, oder werden sich die meisten Nutzer irgendwann auf einen einzigen einfachen Pfad festlegen?
#DUSK @Dusk $DUSK
