Ich habe mir heute Dusk’ Architektur angesehen, und eine Sache ergab nach tieferem Nachforschen plötzlich mehr Sinn:
Dusk zwingt nicht jeden Entwickler in dieselbe Ausführungsumgebung.
Stattdessen trennt es Settlement von der Ausführung.
Unten liegt DuskDS, das Konsens, Finalität und Datenverfügbarkeit übernimmt.
Darauf folgen zwei unterschiedliche Pfade.
DuskVM führt Rust/WASM-Contracts direkt auf dem Dusk L1 aus.
DuskEVM bietet Entwicklern eine EVM-kompatible Umgebung für Solidity und Vyper, wobei das Settlement weiterhin über DuskDS erfolgt.
Anfangs wirkte es auf mich wie unnötige Komplexität, zwei Umgebungen zu haben.
Aber der Grund wurde klarer.
Eine Anwendung, die direkten Zugriff auf Dusk’ native Transaktionsmodelle, Datenschutz oder Zero-Knowledge-Fähigkeiten braucht, kann DuskVM nutzen.
Ein Team, das bereits im Ethereum-Entwickler-Ökosystem zuhause ist, kann DuskEVM verwenden – vertraute Tools und Solidity – anstatt seine gesamte Entwicklungs-Workflow-Grundlage neu aufzubauen.
Das ist ein interessanter Trade-off.
Dusk verlangt von Entwicklern nicht wirklich, zwischen nativer Infrastruktur und EVM-Kompatibilität zu wählen.
Es versucht, beides beizubehalten und das Settlement darunter zu platzieren.
Die Frage, die ich jedoch noch habe, ist die entscheidende:
Wird es mit beiden Ausführungspfaden tatsächlich genug unterschiedliche Builder anziehen, um die zusätzliche architektonische Komplexität zu rechtfertigen?
Für mich ist das eine viel spannendere Beobachtung als nur „Dusk als EVM-kompatibel“ zu bezeichnen.
#dusk $DUSK @Dusk
Dusk zwingt nicht jeden Entwickler in dieselbe Ausführungsumgebung.
Stattdessen trennt es Settlement von der Ausführung.
Unten liegt DuskDS, das Konsens, Finalität und Datenverfügbarkeit übernimmt.
Darauf folgen zwei unterschiedliche Pfade.
DuskVM führt Rust/WASM-Contracts direkt auf dem Dusk L1 aus.
DuskEVM bietet Entwicklern eine EVM-kompatible Umgebung für Solidity und Vyper, wobei das Settlement weiterhin über DuskDS erfolgt.
Anfangs wirkte es auf mich wie unnötige Komplexität, zwei Umgebungen zu haben.
Aber der Grund wurde klarer.
Eine Anwendung, die direkten Zugriff auf Dusk’ native Transaktionsmodelle, Datenschutz oder Zero-Knowledge-Fähigkeiten braucht, kann DuskVM nutzen.
Ein Team, das bereits im Ethereum-Entwickler-Ökosystem zuhause ist, kann DuskEVM verwenden – vertraute Tools und Solidity – anstatt seine gesamte Entwicklungs-Workflow-Grundlage neu aufzubauen.
Das ist ein interessanter Trade-off.
Dusk verlangt von Entwicklern nicht wirklich, zwischen nativer Infrastruktur und EVM-Kompatibilität zu wählen.
Es versucht, beides beizubehalten und das Settlement darunter zu platzieren.
Die Frage, die ich jedoch noch habe, ist die entscheidende:
Wird es mit beiden Ausführungspfaden tatsächlich genug unterschiedliche Builder anziehen, um die zusätzliche architektonische Komplexität zu rechtfertigen?
Für mich ist das eine viel spannendere Beobachtung als nur „Dusk als EVM-kompatibel“ zu bezeichnen.
#dusk $DUSK @Dusk