#dusk $DUSK @Dusk Forschung$DUSK In letzter Zeit merke ich immer mehr, dass es etwas zu eng ist, das Ganze nur mit „Privacy-Chain“ in drei Worten zu erklären.
Zuerst zur Positionierung: Am Anfang, als ich @Dusk gesehen habe, lag der Fokus tatsächlich stark auf Privatsphäre. Doch wenn man entlang der Dusk-Trade-Kette weiter gräbt, wird klar, dass es ihnen in Wahrheit darum geht, an die harte Nuss zu gehen: die Emission, den Handel und die Abwicklung regulierter Finanzanlagen.
Dann zum Kernproblem: Bei einer Wertpapier-Transaktion gibt es im Grunde zwei parallele Linien – auf der einen Seite die Asset-Übergabe, auf der anderen Seite die Geldzahlung. Die Schwierigkeit liegt nicht darin, ob es zu einem Abschluss kommt, sondern darin, ob diese beiden Dinge koordiniert nach demselben Regelwerk abgeschlossen werden können. Dusk packt den Investor-Zugang, den Handel, die Zahlung und die Abwicklung in denselben Prozess. Auf der Basisebene übernimmt DuskDS eine deterministische Abwicklung; offiziell wird auch klar gesagt, dass sie DvP und atomare Abwicklung unterstützen. Das führt zu einer ziemlich konkreten Frage: Wenn im Wertpapier-Display ein Trade als ausgeführt erscheint, die Assets und das Geld aber nicht wirklich zugestellt bzw. geliefert werden – gilt diese Transaktion dann als „fertig“? Betrachtet man die Abwicklung aus diesem Blickwinkel neu, verändert sich das Gewicht dieses Wortes.
Technisch ist die Architektur ziemlich klar: DuskDS kümmert sich um Konsens und deterministische Abwicklung; DuskVM führt native Contracts aus (Rust/WASM); DuskEVM ist Solidity-kompatibel, damit Ethereum-Entwickler problemlos migrieren können. Darüber hinaus nutzt Phoenix ZK für Transaktions-Privatsphäre, Moonlight verwaltet öffentliche Konten, und XSC sorgt für Compliance und Zugriffskontrolle bei vertraulichen Wertpapieren.
Als Nächstes die aktuelle Lage und die Bedenken: Kürzlich ist das DuskEVM-Testnetz online gegangen. Entwickler können Solidity und Hardhat direkt bereitstellen – die Wiederverwendung des Toolchains ist tatsächlich eine gute Sache. Was mich jedoch mehr interessiert, ist die Frage, wo genau die Privatsphäre-Grenze verläuft: Unter der Standard-EVM-Semantik ist der Contract-Speicher standardmäßig lesbar – liegt die Privatsphäre also auf der Abwicklungsschicht oder muss der Entwickler aktiv Module aufrufen? In Geschäftsbereichen mit Institutionen kann man das nicht verwaschen lassen. Zwei Wege parallel: DuskEVM tauscht Entwickleranzahl gegen schnelleres Onboarding, DuskVM bewahrt die native Privatsphäre – geschäftlich ergibt das Sinn. Für Nutzer bedeutet es jedoch, dass man mehr abwägen muss.
Deshalb achte ich im Moment weniger darauf, wie schnell die Abwicklung ist, sondern darauf, wie beide Seiten konsistent bleiben, wenn sich Assets und Geld gleichzeitig bewegen. Und außerdem: wie gut das echte Netzwerk tatsächlich läuft – das sind vermutlich die Fragen, die dauerhaft relevant bleiben, wenn Wertpapiere wirklich in den Finanzmarkt eintreten.
Zuerst zur Positionierung: Am Anfang, als ich @Dusk gesehen habe, lag der Fokus tatsächlich stark auf Privatsphäre. Doch wenn man entlang der Dusk-Trade-Kette weiter gräbt, wird klar, dass es ihnen in Wahrheit darum geht, an die harte Nuss zu gehen: die Emission, den Handel und die Abwicklung regulierter Finanzanlagen.
Dann zum Kernproblem: Bei einer Wertpapier-Transaktion gibt es im Grunde zwei parallele Linien – auf der einen Seite die Asset-Übergabe, auf der anderen Seite die Geldzahlung. Die Schwierigkeit liegt nicht darin, ob es zu einem Abschluss kommt, sondern darin, ob diese beiden Dinge koordiniert nach demselben Regelwerk abgeschlossen werden können. Dusk packt den Investor-Zugang, den Handel, die Zahlung und die Abwicklung in denselben Prozess. Auf der Basisebene übernimmt DuskDS eine deterministische Abwicklung; offiziell wird auch klar gesagt, dass sie DvP und atomare Abwicklung unterstützen. Das führt zu einer ziemlich konkreten Frage: Wenn im Wertpapier-Display ein Trade als ausgeführt erscheint, die Assets und das Geld aber nicht wirklich zugestellt bzw. geliefert werden – gilt diese Transaktion dann als „fertig“? Betrachtet man die Abwicklung aus diesem Blickwinkel neu, verändert sich das Gewicht dieses Wortes.
Technisch ist die Architektur ziemlich klar: DuskDS kümmert sich um Konsens und deterministische Abwicklung; DuskVM führt native Contracts aus (Rust/WASM); DuskEVM ist Solidity-kompatibel, damit Ethereum-Entwickler problemlos migrieren können. Darüber hinaus nutzt Phoenix ZK für Transaktions-Privatsphäre, Moonlight verwaltet öffentliche Konten, und XSC sorgt für Compliance und Zugriffskontrolle bei vertraulichen Wertpapieren.
Als Nächstes die aktuelle Lage und die Bedenken: Kürzlich ist das DuskEVM-Testnetz online gegangen. Entwickler können Solidity und Hardhat direkt bereitstellen – die Wiederverwendung des Toolchains ist tatsächlich eine gute Sache. Was mich jedoch mehr interessiert, ist die Frage, wo genau die Privatsphäre-Grenze verläuft: Unter der Standard-EVM-Semantik ist der Contract-Speicher standardmäßig lesbar – liegt die Privatsphäre also auf der Abwicklungsschicht oder muss der Entwickler aktiv Module aufrufen? In Geschäftsbereichen mit Institutionen kann man das nicht verwaschen lassen. Zwei Wege parallel: DuskEVM tauscht Entwickleranzahl gegen schnelleres Onboarding, DuskVM bewahrt die native Privatsphäre – geschäftlich ergibt das Sinn. Für Nutzer bedeutet es jedoch, dass man mehr abwägen muss.
Deshalb achte ich im Moment weniger darauf, wie schnell die Abwicklung ist, sondern darauf, wie beide Seiten konsistent bleiben, wenn sich Assets und Geld gleichzeitig bewegen. Und außerdem: wie gut das echte Netzwerk tatsächlich läuft – das sind vermutlich die Fragen, die dauerhaft relevant bleiben, wenn Wertpapiere wirklich in den Finanzmarkt eintreten.