Der Markt findet immer wieder neue Namen, um mich zu überraschen. $BOME $RE

Beide bekommen auf dem Chart jede Menge Aufmerksamkeit.

Inzwischen frage ich nicht einmal mehr, welcher von beiden als Nächstes in Bewegung kommt – ich versuche nur, ihn zu erkennen, bevor es alle anderen auch tun.

Früher dachte ich, das Hinzufügen einer EVM zu einer Blockchain hätte vor allem das Ziel, die Entwicklung einfacher zu machen.

Aber wenn ich tiefer in Dusk eintauche, habe ich das anders gesehen.

Dusk hat zwei Ausführungsumgebungen: DuskVM und DuskEVM. Und sie scheinen zwei unterschiedliche Entwicklerprobleme zu lösen.

DuskVM ist die native Umgebung. Smart Contracts können in Rust geschrieben und zu WebAssembly kompiliert werden – so erhalten Entwickler die Möglichkeit, direkt innerhalb der L1-Architektur von Dusk zu bauen.

DuskEVM geht einen anderen Weg.

Es bietet Entwicklern, die aus Ethereum kommen, eine vertrautere Umgebung – mit Unterstützung für Solidity, Vyper und bewährten EVM-Tools.

Dieser Unterschied ist wichtiger, als ich zunächst dachte.

Wer eng mit der nativen Architektur von Dusk arbeiten möchte, kann DuskVM nutzen.

Aber jemand, der Solidity bereits kennt und jahrelang Ethereum-Entwicklungstools verwendet hat, möchte nicht unbedingt erst eine komplett andere Umgebung lernen, nur um mit Dusk zu experimentieren.

Daher sehe ich DuskVM und DuskEVM nicht als Konkurrenz zueinander.

Sie sind eher wie zwei Einstiegspunkte in dasselbe Netzwerk.

Der eine ist für Dusk nativer.

Der andere macht das Ökosystem für Entwickler aus der EVM-Welt zugänglicher.

Jetzt bin ich neugieriger auf die schwierigere Frage.

Kann Dusk beide Gruppen von Entwicklern anziehen, ohne dass sich seine Ausführungsarchitektur zersplittert anfühlt?

@Dusk_Foundation $DUSK #dusk

Welche Dusk-Umgebung interessiert dich mehr?