Je länger ich mir Dusk’ Architektur anschaue, desto mehr denke ich, dass die Bezeichnung „EVM-Chain“ dem Ganzen nicht gerecht wird.
Ich habe zunächst auf DuskEVM fokussiert, weil das der einfachste Teil zum Verständnis ist.
Solidity.
EVM-Tools.
Vertraute Entwicklungsumgebung.
Fertig.
Doch dann habe ich darunterliegende Schichten betrachtet.
DuskDS übernimmt die Grundlagen der Abrechnung: Konsens, Staking, Datenverfügbarkeit und Finalität.
DuskEVM übernimmt die Ausführung von EVM-kompatiblen Anwendungen.
Und DuskVM stellt eine native Umgebung für Anwendungen bereit, die tieferen Zugriff auf Dusk’ Datenschutz- und ZK-Fähigkeiten benötigen.
Diese Trennung ergibt für mich jetzt wirklich Sinn.
Denn eine regulierte Finanzanwendung hat nicht zwangsläufig dieselben Anforderungen wie eine normale DeFi-Anwendung.
Eine Anwendung stellt möglicherweise die vertraute EVM-Entwicklung in den Vordergrund.
Eine andere braucht möglicherweise vertrauliche Transaktionen.
Eine weitere benötigt tieferen Zugriff auf Protokoll-Ebene.
Warum also alle drei in genau dasselbe Ausführungsmodell zwingen?
Das Spannende ist, dass diese nicht isolierte Chains sind, die gegeneinander konkurrieren.
Es sind unterschiedliche Ausführungsumgebungen, verbunden mit derselben zugrunde liegenden Dusk-Infrastruktur.
Und genau da wird $DUSK auch noch interessanter.
Das gleiche native Asset liegt dem System für Gas und Staking zugrunde, statt dass jede Ebene ein eigenes wirtschaftliches Asset braucht.
Ich beobachte weiterhin, ob Entwickler tatsächlich von dieser Flexibilität Gebrauch machen.
Denn Architektur auf Papier ist das eine.
Die tatsächliche Entwickler-Adoption ist der echte Test.
Aber wenn das Modell wie vorgesehen funktioniert, bietet Dusk nicht einfach nur einen weiteren Ort, um Solidity-Contracts bereitzustellen.
Es bietet Entwicklern eine Wahl der Ausführungsumgebung, während es eine gemeinsame Abrechnungs- und Sicherheitsgrundlage beibehält.
Das ist eine viel interessantere Vorstellung.
#dusk @Dusk
Ich habe zunächst auf DuskEVM fokussiert, weil das der einfachste Teil zum Verständnis ist.
Solidity.
EVM-Tools.
Vertraute Entwicklungsumgebung.
Fertig.
Doch dann habe ich darunterliegende Schichten betrachtet.
DuskDS übernimmt die Grundlagen der Abrechnung: Konsens, Staking, Datenverfügbarkeit und Finalität.
DuskEVM übernimmt die Ausführung von EVM-kompatiblen Anwendungen.
Und DuskVM stellt eine native Umgebung für Anwendungen bereit, die tieferen Zugriff auf Dusk’ Datenschutz- und ZK-Fähigkeiten benötigen.
Diese Trennung ergibt für mich jetzt wirklich Sinn.
Denn eine regulierte Finanzanwendung hat nicht zwangsläufig dieselben Anforderungen wie eine normale DeFi-Anwendung.
Eine Anwendung stellt möglicherweise die vertraute EVM-Entwicklung in den Vordergrund.
Eine andere braucht möglicherweise vertrauliche Transaktionen.
Eine weitere benötigt tieferen Zugriff auf Protokoll-Ebene.
Warum also alle drei in genau dasselbe Ausführungsmodell zwingen?
Das Spannende ist, dass diese nicht isolierte Chains sind, die gegeneinander konkurrieren.
Es sind unterschiedliche Ausführungsumgebungen, verbunden mit derselben zugrunde liegenden Dusk-Infrastruktur.
Und genau da wird $DUSK auch noch interessanter.
Das gleiche native Asset liegt dem System für Gas und Staking zugrunde, statt dass jede Ebene ein eigenes wirtschaftliches Asset braucht.
Ich beobachte weiterhin, ob Entwickler tatsächlich von dieser Flexibilität Gebrauch machen.
Denn Architektur auf Papier ist das eine.
Die tatsächliche Entwickler-Adoption ist der echte Test.
Aber wenn das Modell wie vorgesehen funktioniert, bietet Dusk nicht einfach nur einen weiteren Ort, um Solidity-Contracts bereitzustellen.
Es bietet Entwicklern eine Wahl der Ausführungsumgebung, während es eine gemeinsame Abrechnungs- und Sicherheitsgrundlage beibehält.
Das ist eine viel interessantere Vorstellung.
#dusk @Dusk