Früher dachte ich, dass man bei einer öffentlichen Chain einfach noch ein paar zusätzliche Ausführungsumgebungen einbauen kann—im Grunde nur, um Entwicklern einen weiteren Weg zu geben. Nachdem ich jedoch die Architektur von @Dusk auseinandergebaut habe, wurde mir klar: Das Verhältnis zwischen DuskVM und DuskEVM ist nicht so einfach. Sie sind eher zwei Schnittstellen für unterschiedliche Anforderungen. $DUSK
DuskVM läuft direkt auf Dusk L1 und nutzt Rust/WASM. Das ist besonders geeignet, um auf native Assets zuzugreifen, Privatsphäre- und ZK-Fähigkeiten zu verwenden. DuskEVM ist dagegen eher wie eine Migrationsbrücke: Für Solidity-Entwickler bleibt die Nutzung vertrauter Wallets, Frameworks und Test-Tools möglich. Am Ende werden die Ergebnisse auf beiden Seiten von DuskDS übernommen und abgerechnet. #dusk
Das bedeutet: Die Rolle von DuskEVM ist nicht nur, die Migrationshürde zu senken. Beispielsweise kann ein normales Finanzanwendungsprojekt zunächst bei DuskEVM starten, um eine ausgereifte EVM-Toolchain anzuschließen. Wenn es aber um Privacy Securities, die Übertragung kontrollierter Assets geht oder wenn native Dusk-Geheimfunktionen aufgerufen werden müssen, kann man nicht einfach auf der EVM-Schicht stehenbleiben—viele Logiken müssen über DuskVM laufen.
Damit stellt sich die Kernfrage: Wenn eine Anwendung sowohl Solidity-Contracts integrieren als auch Dusk-native Privacy-Assets verwalten muss—wo liegt dann der zentrale State? Wie werden die Zustände zwischen den beiden Umgebungen synchronisiert? Wer verifiziert Aufrufe über Ebenen hinweg? Und wenn etwas schiefgeht: Muss der Entwickler dann Vertragsprobleme untersuchen, Probleme in der Ausführungsumgebung, oder Probleme in der Abrechnungsschicht? $BTC
Darum sehe ich Dusk’ Multi-Execution-Umgebungen heute nicht nur als Kompatibilitätsvorteil. Einerseits ermöglicht es mehr Entwicklern den Einstieg. Andererseits überträgt es dem Entwicklungsteam die anspruchsvollen Design-Herausforderungen des Gesamtsystems. Das wirklich Beobachtenswerte ist nicht, wie viele Ausführungsarten Dusk anbietet, sondern ob diese Umgebungen klare Grenzen zueinander definieren können—damit Entwickler weniger sinnlose Abwägungen treffen müssen, statt dass die Anwendungsarchitektur immer weiter aufgeschichtet wird, nur um gleichzeitig verschiedene Fähigkeiten nutzen zu können. $ETH
DuskVM läuft direkt auf Dusk L1 und nutzt Rust/WASM. Das ist besonders geeignet, um auf native Assets zuzugreifen, Privatsphäre- und ZK-Fähigkeiten zu verwenden. DuskEVM ist dagegen eher wie eine Migrationsbrücke: Für Solidity-Entwickler bleibt die Nutzung vertrauter Wallets, Frameworks und Test-Tools möglich. Am Ende werden die Ergebnisse auf beiden Seiten von DuskDS übernommen und abgerechnet. #dusk
Das bedeutet: Die Rolle von DuskEVM ist nicht nur, die Migrationshürde zu senken. Beispielsweise kann ein normales Finanzanwendungsprojekt zunächst bei DuskEVM starten, um eine ausgereifte EVM-Toolchain anzuschließen. Wenn es aber um Privacy Securities, die Übertragung kontrollierter Assets geht oder wenn native Dusk-Geheimfunktionen aufgerufen werden müssen, kann man nicht einfach auf der EVM-Schicht stehenbleiben—viele Logiken müssen über DuskVM laufen.
Damit stellt sich die Kernfrage: Wenn eine Anwendung sowohl Solidity-Contracts integrieren als auch Dusk-native Privacy-Assets verwalten muss—wo liegt dann der zentrale State? Wie werden die Zustände zwischen den beiden Umgebungen synchronisiert? Wer verifiziert Aufrufe über Ebenen hinweg? Und wenn etwas schiefgeht: Muss der Entwickler dann Vertragsprobleme untersuchen, Probleme in der Ausführungsumgebung, oder Probleme in der Abrechnungsschicht? $BTC
Darum sehe ich Dusk’ Multi-Execution-Umgebungen heute nicht nur als Kompatibilitätsvorteil. Einerseits ermöglicht es mehr Entwicklern den Einstieg. Andererseits überträgt es dem Entwicklungsteam die anspruchsvollen Design-Herausforderungen des Gesamtsystems. Das wirklich Beobachtenswerte ist nicht, wie viele Ausführungsarten Dusk anbietet, sondern ob diese Umgebungen klare Grenzen zueinander definieren können—damit Entwickler weniger sinnlose Abwägungen treffen müssen, statt dass die Anwendungsarchitektur immer weiter aufgeschichtet wird, nur um gleichzeitig verschiedene Fähigkeiten nutzen zu können. $ETH