#dusk $DUSK @Dusk Zuerst behandelte ich die EVM-Kompatibilität wie eine Checkbox.
Wenn eine Kette Solidity unterstützt, können Entwickler herüberkommen. Ganz einfach, oder?
Dann sah ich mir DuskEVM genauer an, und diese Annahme fühlte sich auf einmal ein wenig zu oberflächlich an.
Wirklich entscheidend ist, was Entwickler mitbringen können und behalten, wenn sie umsteigen.
Mit DuskEVM können Entwickler in einer EVM-äquivalenten Umgebung arbeiten – mit Solidity und vertrautem EVM-Tooling. Das bedeutet: Es geht nicht nur darum, eine weitere Ausführungsumgebung hinzuzufügen. Es geht darum, die Distanz zwischen dem, was Entwickler bereits kennen, und dem, was Dusk baut, zu verkleinern.
Daran blieb ich hängen.
Denn einen Entwickler zu bitten, einen völlig neuen Stack zu lernen, ist das eine. Ihn aber seine vertrauten Smart-Contract-Workflows in eine andere Blockchain-Architektur mitbringen zu lassen, ist etwas anderes.
Und dann gibt es noch DuskDS.
DuskEVM übernimmt die Ausführung, während DuskDS die Settlement- und Data-Availability-Basis darunter liefert. DuskVM ist ein weiterer Ausführungspfad, der Rust/WASM-Contracts direkt auf dem Dusk L1 ausführt.
Also fragte ich mich:
Wenn unterschiedliche Ausführungsumgebungen auf derselben Settlement-Basis aufbauen können, macht das dann die gesamte Architektur flexibler?
Vielleicht.
Aber ich glaube nicht, dass EVM-Kompatibilität allein etwas beweist.
Der eigentliche Test ist, was passiert, nachdem Entwickler angekommen sind: Bauen sie tatsächlich? Ist das Tooling bequem genug? Profitieren Anwendungen davon, dass Ausführung und Settlement getrennt sind?
Darauf bin ich nun am meisten gespannt und möchte es beobachten.
Für eine aufstrebende Layer-1: Reicht es aus, Solidity zu unterstützen, um Entwickler anzuziehen – oder beginnt der eigentliche Test erst, wenn die Leute wirklich anfangen zu bauen?
@Dusk $DUSK
#Dusk #DuskEVM
Wenn eine Kette Solidity unterstützt, können Entwickler herüberkommen. Ganz einfach, oder?
Dann sah ich mir DuskEVM genauer an, und diese Annahme fühlte sich auf einmal ein wenig zu oberflächlich an.
Wirklich entscheidend ist, was Entwickler mitbringen können und behalten, wenn sie umsteigen.
Mit DuskEVM können Entwickler in einer EVM-äquivalenten Umgebung arbeiten – mit Solidity und vertrautem EVM-Tooling. Das bedeutet: Es geht nicht nur darum, eine weitere Ausführungsumgebung hinzuzufügen. Es geht darum, die Distanz zwischen dem, was Entwickler bereits kennen, und dem, was Dusk baut, zu verkleinern.
Daran blieb ich hängen.
Denn einen Entwickler zu bitten, einen völlig neuen Stack zu lernen, ist das eine. Ihn aber seine vertrauten Smart-Contract-Workflows in eine andere Blockchain-Architektur mitbringen zu lassen, ist etwas anderes.
Und dann gibt es noch DuskDS.
DuskEVM übernimmt die Ausführung, während DuskDS die Settlement- und Data-Availability-Basis darunter liefert. DuskVM ist ein weiterer Ausführungspfad, der Rust/WASM-Contracts direkt auf dem Dusk L1 ausführt.
Also fragte ich mich:
Wenn unterschiedliche Ausführungsumgebungen auf derselben Settlement-Basis aufbauen können, macht das dann die gesamte Architektur flexibler?
Vielleicht.
Aber ich glaube nicht, dass EVM-Kompatibilität allein etwas beweist.
Der eigentliche Test ist, was passiert, nachdem Entwickler angekommen sind: Bauen sie tatsächlich? Ist das Tooling bequem genug? Profitieren Anwendungen davon, dass Ausführung und Settlement getrennt sind?
Darauf bin ich nun am meisten gespannt und möchte es beobachten.
Für eine aufstrebende Layer-1: Reicht es aus, Solidity zu unterstützen, um Entwickler anzuziehen – oder beginnt der eigentliche Test erst, wenn die Leute wirklich anfangen zu bauen?
@Dusk $DUSK
#Dusk #DuskEVM
