Wenn eine Public Chain eine EVM-Kompatibilität hinzufügt, gehe ich normalerweise davon aus, dass die native Ausführungsumgebung mit der Zeit an Priorität verliert. EVM-Tools ziehen mehr Entwickler an, Solidity wird zum Standard, und eine separate native Laufzeit wirkt wie ein Wartungsaufwand, der stillschweigend zurückgestuft wird.
Aber @Dusk s aktualisierte Architektur vermeidet dieses Muster bewusst.
Jetzt übernimmt DuskDS das Settlement und die Datenverfügbarkeit als Grundlage, DuskEVM führt EVM-kompatible Anwendungen aus, und DuskVM bleibt auf L1 speziell für Rust- und WASM-Contracts, die direkten Zugriff auf native Privacy- und ZK-Funktionalität benötigen.
Ich habe das anfangs als unnötige Duplizierung gelesen, aber ich glaube, es ist tatsächlich das Gegenteil: Es behandelt das Onboarding von Entwicklern und die Protokollfähigkeit als zwei getrennte Probleme, die nicht gezwungen werden sollten, an derselben Stelle zusammenzufallen.
DuskEVM übernimmt die Seite des Onboardings. Solidity-Contracts, bestehende Wallets und Ethereum-Tools funktionieren hier ohne Änderungen. DuskVM übernimmt etwas anderes: Wenn eine Anwendung das native Transaktionsmodell von Dusk, Vertraulichkeitsfunktionen oder ZK-Beweise benötigt, muss sie nicht alles über EVM-kompatiblen Code übersetzen.
Die offizielle Dokumentation positioniert DuskVM als eine WASM-Ausführungsumgebung, die nativ auf der Dusk-L1 läuft.
Das hat mir geholfen, darüber nachzudenken, was #dusk tatsächlich aufbaut.
Es geht nicht nur darum, die Kette in Schichten zu splitten. Es erkennt etwas noch Spezifischeres an: Die EVM ist ein effektiver Einstiegspunkt für die Übernahme durch Entwickler, aber sie ist möglicherweise nicht der richtige Ort, um Fähigkeiten zu tragen, die eigentlich dem Protokoll selbst „nativ“ sind.
Wirklich beobachtenswert ist nicht, ob $DUSK zwei Ausführungsumgebungen gleichzeitig betreiben kann, sondern ob Entwickler tatsächlich unterschiedliche Wege wählen – je nachdem, was sie brauchen.
Wenn die Entwicklung größtenteils in der EVM bleibt, wird DuskVM zwar eine Fähigkeit sein, aber kaum genutzt werden. Wenn privacy-native Anwendungen und finanzielle Protokolle anfangen, den nativen Ausführungspfad zu nutzen, weil die EVM diese Anforderungen nicht erfüllen kann, dann bekommt die Komplexität, zwei Umgebungen zu warten, durchaus einen entsprechenden Mehrwert.
Aber @Dusk s aktualisierte Architektur vermeidet dieses Muster bewusst.
Jetzt übernimmt DuskDS das Settlement und die Datenverfügbarkeit als Grundlage, DuskEVM führt EVM-kompatible Anwendungen aus, und DuskVM bleibt auf L1 speziell für Rust- und WASM-Contracts, die direkten Zugriff auf native Privacy- und ZK-Funktionalität benötigen.
Ich habe das anfangs als unnötige Duplizierung gelesen, aber ich glaube, es ist tatsächlich das Gegenteil: Es behandelt das Onboarding von Entwicklern und die Protokollfähigkeit als zwei getrennte Probleme, die nicht gezwungen werden sollten, an derselben Stelle zusammenzufallen.
DuskEVM übernimmt die Seite des Onboardings. Solidity-Contracts, bestehende Wallets und Ethereum-Tools funktionieren hier ohne Änderungen. DuskVM übernimmt etwas anderes: Wenn eine Anwendung das native Transaktionsmodell von Dusk, Vertraulichkeitsfunktionen oder ZK-Beweise benötigt, muss sie nicht alles über EVM-kompatiblen Code übersetzen.
Die offizielle Dokumentation positioniert DuskVM als eine WASM-Ausführungsumgebung, die nativ auf der Dusk-L1 läuft.
Das hat mir geholfen, darüber nachzudenken, was #dusk tatsächlich aufbaut.
Es geht nicht nur darum, die Kette in Schichten zu splitten. Es erkennt etwas noch Spezifischeres an: Die EVM ist ein effektiver Einstiegspunkt für die Übernahme durch Entwickler, aber sie ist möglicherweise nicht der richtige Ort, um Fähigkeiten zu tragen, die eigentlich dem Protokoll selbst „nativ“ sind.
Wirklich beobachtenswert ist nicht, ob $DUSK zwei Ausführungsumgebungen gleichzeitig betreiben kann, sondern ob Entwickler tatsächlich unterschiedliche Wege wählen – je nachdem, was sie brauchen.
Wenn die Entwicklung größtenteils in der EVM bleibt, wird DuskVM zwar eine Fähigkeit sein, aber kaum genutzt werden. Wenn privacy-native Anwendungen und finanzielle Protokolle anfangen, den nativen Ausführungspfad zu nutzen, weil die EVM diese Anforderungen nicht erfüllen kann, dann bekommt die Komplexität, zwei Umgebungen zu warten, durchaus einen entsprechenden Mehrwert.
