Es gibt eine Einzelheit, die mich veranlasst hat, die Architektur von Dusk noch einmal ganz genau zu lesen. Zunächst dachte ich, dass DuskDS einfach nur der Blockchain-Teil ist, der unterhalb von DuskEVM liegt, aber die technische Dokumentation beschreibt es als etwas Breiteres.
DuskDS wird als Settlement- und Data-Availability-Schicht von Dusk L1 definiert und ist für Consensus, Finality und native Transaction-Modelle zuständig. DuskEVM ist die Execution-Layer, die DuskDS für Settlement und Data Availability nutzt. DuskVM wiederum führt Smart Contracts direkt auf Dusk L1 aus.
Ich bin dann genauer darauf eingegangen, wie Settlement tatsächlich verifiziert wird. DuskDS verwendet Succinct Attestation, ein Proof-of-Stake-basiertes Verfahren, das auf einem Committee beruht. Der Ablauf umfasst Proposal, Validation und anschließend Ratification; wenn ein Block ratifiziert ist, ist Finality deterministisch.
Danach habe ich mir das Transaction-Model angesehen. Moonlight verarbeitet öffentliches Account-Handling, während Phoenix geschützte Notes (shielded notes) und Zero-Knowledge-Proofs nutzt. Zwei unterschiedliche Modelle, aber am Ende werden beide auf derselben Kette gesettelt.
Moment — das bedeutet noch nicht, dass DuskDS die gesamte Anwendungslogik selbst übernimmt. Die Execution liegt weiterhin bei DuskVM oder DuskEVM, doch genau an dieser Stelle hat sich meine Perspektive verändert: Dusk trennt Execution ziemlich klar von Settlement.
Wenn dem so ist, lautet die wirklich spannende Frage nicht mehr, ob DuskDS eine Settlement-Layer ist, sondern: Welche konkreten praktischen Unterschiede wird diese Trennung von Settlement schaffen, wenn Finanzanwendungen in großem Maßstab zu laufen beginnen?
#dusk $DUSK @Dusk
DuskDS wird als Settlement- und Data-Availability-Schicht von Dusk L1 definiert und ist für Consensus, Finality und native Transaction-Modelle zuständig. DuskEVM ist die Execution-Layer, die DuskDS für Settlement und Data Availability nutzt. DuskVM wiederum führt Smart Contracts direkt auf Dusk L1 aus.
Ich bin dann genauer darauf eingegangen, wie Settlement tatsächlich verifiziert wird. DuskDS verwendet Succinct Attestation, ein Proof-of-Stake-basiertes Verfahren, das auf einem Committee beruht. Der Ablauf umfasst Proposal, Validation und anschließend Ratification; wenn ein Block ratifiziert ist, ist Finality deterministisch.
Danach habe ich mir das Transaction-Model angesehen. Moonlight verarbeitet öffentliches Account-Handling, während Phoenix geschützte Notes (shielded notes) und Zero-Knowledge-Proofs nutzt. Zwei unterschiedliche Modelle, aber am Ende werden beide auf derselben Kette gesettelt.
Moment — das bedeutet noch nicht, dass DuskDS die gesamte Anwendungslogik selbst übernimmt. Die Execution liegt weiterhin bei DuskVM oder DuskEVM, doch genau an dieser Stelle hat sich meine Perspektive verändert: Dusk trennt Execution ziemlich klar von Settlement.
Wenn dem so ist, lautet die wirklich spannende Frage nicht mehr, ob DuskDS eine Settlement-Layer ist, sondern: Welche konkreten praktischen Unterschiede wird diese Trennung von Settlement schaffen, wenn Finanzanwendungen in großem Maßstab zu laufen beginnen?
#dusk $DUSK @Dusk
