#dusk Als ich zum ersten Mal Dusk’ Entwicklerarchitektur betrachtet habe, fragte ich mich ehrlich, warum sie zwei Smart-Contract-Umgebungen braucht. Mein erster Gedanke war ganz einfach: Wäre nicht eine ausreichend?
Nachdem ich genauer hingeschaut habe, wurde mir klar, dass sie zwei unterschiedliche Entwicklerprobleme lösen.
DuskEVM ist der vertraute Weg. Solidity- und EVM-kompatible Tools machen es für Entwickler leichter, die das Ökosystem von Ethereum bereits verstehen.
DuskVM ist der Bereich, in dem die Architektur für mich mehr Sinn ergibt. Rust/WASM-Contracts laufen direkt auf Dusk L1 und geben Entwicklern eine direktere, „natürlichere“ Art, mit Dusk-spezifischen Fähigkeiten zu arbeiten – einschließlich seines Transaktionsmodells, der Privatsphäre und der Funktionen für Zero-Knowledge.
Daher sehe ich DuskEVM und DuskVM nicht als konkurrierende Umgebungen.
Ich sehe sie als zwei unterschiedliche Einstiegspunkte.
Wenn ich Kompatibilität und vertraute Tooling-Optionen brauche, ist EVM sinnvoll. Wenn eine Anwendung tieferen Zugriff auf das benötigt, was Dusk’ eigenes L1 bieten kann, scheint DuskVM die natürlichere Wahl.
Das hat meine Sicht auf die Architektur verändert.
Dusk sagt nicht einfach: „Wir unterstützen EVM.“ Es bietet Entwicklern Flexibilität auf der Ausführungsebene, während DuskDS darunter als Grundlage für Abwicklung und Datenverfügbarkeit bleibt.
Für mich ist das der spannendere Teil des Designs: unterschiedliche Wege zum Aufbau, ohne jede Anwendung in dasselbe Ausführungsmodell zu zwingen.
$DUSK @Dusk
Nachdem ich genauer hingeschaut habe, wurde mir klar, dass sie zwei unterschiedliche Entwicklerprobleme lösen.
DuskEVM ist der vertraute Weg. Solidity- und EVM-kompatible Tools machen es für Entwickler leichter, die das Ökosystem von Ethereum bereits verstehen.
DuskVM ist der Bereich, in dem die Architektur für mich mehr Sinn ergibt. Rust/WASM-Contracts laufen direkt auf Dusk L1 und geben Entwicklern eine direktere, „natürlichere“ Art, mit Dusk-spezifischen Fähigkeiten zu arbeiten – einschließlich seines Transaktionsmodells, der Privatsphäre und der Funktionen für Zero-Knowledge.
Daher sehe ich DuskEVM und DuskVM nicht als konkurrierende Umgebungen.
Ich sehe sie als zwei unterschiedliche Einstiegspunkte.
Wenn ich Kompatibilität und vertraute Tooling-Optionen brauche, ist EVM sinnvoll. Wenn eine Anwendung tieferen Zugriff auf das benötigt, was Dusk’ eigenes L1 bieten kann, scheint DuskVM die natürlichere Wahl.
Das hat meine Sicht auf die Architektur verändert.
Dusk sagt nicht einfach: „Wir unterstützen EVM.“ Es bietet Entwicklern Flexibilität auf der Ausführungsebene, während DuskDS darunter als Grundlage für Abwicklung und Datenverfügbarkeit bleibt.
Für mich ist das der spannendere Teil des Designs: unterschiedliche Wege zum Aufbau, ohne jede Anwendung in dasselbe Ausführungsmodell zu zwingen.
$DUSK @Dusk