Früher habe ich Dusk als eine einzige Blockchain mit einer einzigen Ausführungsumgebung betrachtet. Die Architektur wurde interessanter, als ich aufgehört habe, jeden Teil des Netzwerks als dasselbe zu behandeln.
Im Kern steht DuskDS. @Dusk beschreibt es als die Consensus-, Finality- und Data-Availability-Grundlage der Dusk L1, und es umfasst die Moonlight- und Phoenix-Transaktionsmodelle des Netzwerks.
Die Ausführung ist ein separater Teil des Bildes. DuskVM ist für Rust/WASM-Smart-Contracts ausgelegt, die direkt auf der Dusk L1 ausgeführt werden, während DuskEVM eine EVM-äquivalente Umgebung für Solidity-Anwendungen bereitstellt, die auf vertrautem EVM-Tooling basieren. DuskEVM nutzt DuskDS für Settlement und Data Availability.
Diese Trennung hat meine Denkweise über das Projekt verändert.
Statt zu fragen, ob Entwickler auf vertrautes Tooling verzichten müssen, um auf Dusk zu bauen, könnte die bessere Frage sein, wie unterschiedliche Ausführungsumgebungen dieselbe zugrunde liegende Settlement- und Data-Availability-Grundlage teilen können.
$DUSK hat an dieser Grundlage eine konkrete Rolle: Offizielle Dokumentation identifiziert es als den nativen Token, der für Transaktionsgebühren und Staking verwendet wird.
Die Architektur wirkt auf dem Papier stimmig. Entscheidend ist als Nächstes, ob Entwickler und echte Finanzanwendungen diese Flexibilität tatsächlich in anhaltende Netzwerkaktivität übersetzen.
Daran würde ich lieber messen als nur an Architekturdiagrammen.
#dusk $DUSK @Dusk
Im Kern steht DuskDS. @Dusk beschreibt es als die Consensus-, Finality- und Data-Availability-Grundlage der Dusk L1, und es umfasst die Moonlight- und Phoenix-Transaktionsmodelle des Netzwerks.
Die Ausführung ist ein separater Teil des Bildes. DuskVM ist für Rust/WASM-Smart-Contracts ausgelegt, die direkt auf der Dusk L1 ausgeführt werden, während DuskEVM eine EVM-äquivalente Umgebung für Solidity-Anwendungen bereitstellt, die auf vertrautem EVM-Tooling basieren. DuskEVM nutzt DuskDS für Settlement und Data Availability.
Diese Trennung hat meine Denkweise über das Projekt verändert.
Statt zu fragen, ob Entwickler auf vertrautes Tooling verzichten müssen, um auf Dusk zu bauen, könnte die bessere Frage sein, wie unterschiedliche Ausführungsumgebungen dieselbe zugrunde liegende Settlement- und Data-Availability-Grundlage teilen können.
$DUSK hat an dieser Grundlage eine konkrete Rolle: Offizielle Dokumentation identifiziert es als den nativen Token, der für Transaktionsgebühren und Staking verwendet wird.
Die Architektur wirkt auf dem Papier stimmig. Entscheidend ist als Nächstes, ob Entwickler und echte Finanzanwendungen diese Flexibilität tatsächlich in anhaltende Netzwerkaktivität übersetzen.
Daran würde ich lieber messen als nur an Architekturdiagrammen.
#dusk $DUSK @Dusk
