DuskEVM ist gerade live gegangen, und der Teil, den ich mir ansehe, ist nicht der eigentliche Launch.
Es geht darum, wie schnell die ersten Entwickler tatsächlich von „Ich kann hier deployen“ zu „Ich möchte hier weiterbauen“ wechseln.
Ich habe mir das DuskEVM-Setup angesehen, und die offensichtliche Reibung ist viel geringer als bei Dusk’ nativer Entwickler-Route. Solidity und Vyper werden unterstützt, und vorhandenes EVM-Tooling soll einfach übernommen werden können. Das ist wichtig, weil es das eine ist, Entwickler dazu zu bringen, einen neuen Stack zu lernen. Sie dazu zu bringen, ihren gesamten Workflow zu ändern, ist etwas ganz anderes.
Doch Kompatibilität bringt dich nur bis zur Startlinie.
Dusk hat bereits zwei Vertragspfade: DuskEVM und DuskVM. Damit stellt sich nun eine praktischere Frage. Wenn ich als Entwickler bereits eine bestehende Solidity-Anwendung habe – was bringt mich dazu, mich für DuskEVM zu entscheiden, statt für die Dutzenden anderer Orte, an denen genau dieser Code schon laufen kann?
Die Antwort wird wahrscheinlich nicht aus einer weiteren Feature-Ankündigung kommen.
Sie wird sich in echten Deployments zeigen, in Wallet-Aktivität, Contract-Interaktionen und darin, ob Entwickler nach dem ersten Experiment wiederkommen.
Auch die GitHub-Seite lohnt sich zu beobachten. Das öffentliche DuskEVM-Genesis-Repo wurde am 28. Juli aktualisiert, was zeigt, dass die Teile sich schon zusammensetzen, aber die Aktivitäten am Launch-Tag sind ein anderer Test.
Jetzt bin ich vor allem am ersten Monat interessiert, denn dort zeigt sich, ob „EVM-kompatibel“ wirklich nützlich wird oder anfängt, sich anzuhören wie...
@Dusk_Foundation #dusk $DUSK $DEXE
Es geht darum, wie schnell die ersten Entwickler tatsächlich von „Ich kann hier deployen“ zu „Ich möchte hier weiterbauen“ wechseln.
Ich habe mir das DuskEVM-Setup angesehen, und die offensichtliche Reibung ist viel geringer als bei Dusk’ nativer Entwickler-Route. Solidity und Vyper werden unterstützt, und vorhandenes EVM-Tooling soll einfach übernommen werden können. Das ist wichtig, weil es das eine ist, Entwickler dazu zu bringen, einen neuen Stack zu lernen. Sie dazu zu bringen, ihren gesamten Workflow zu ändern, ist etwas ganz anderes.
Doch Kompatibilität bringt dich nur bis zur Startlinie.
Dusk hat bereits zwei Vertragspfade: DuskEVM und DuskVM. Damit stellt sich nun eine praktischere Frage. Wenn ich als Entwickler bereits eine bestehende Solidity-Anwendung habe – was bringt mich dazu, mich für DuskEVM zu entscheiden, statt für die Dutzenden anderer Orte, an denen genau dieser Code schon laufen kann?
Die Antwort wird wahrscheinlich nicht aus einer weiteren Feature-Ankündigung kommen.
Sie wird sich in echten Deployments zeigen, in Wallet-Aktivität, Contract-Interaktionen und darin, ob Entwickler nach dem ersten Experiment wiederkommen.
Auch die GitHub-Seite lohnt sich zu beobachten. Das öffentliche DuskEVM-Genesis-Repo wurde am 28. Juli aktualisiert, was zeigt, dass die Teile sich schon zusammensetzen, aber die Aktivitäten am Launch-Tag sind ein anderer Test.
Jetzt bin ich vor allem am ersten Monat interessiert, denn dort zeigt sich, ob „EVM-kompatibel“ wirklich nützlich wird oder anfängt, sich anzuhören wie...
@Dusk_Foundation #dusk $DUSK $DEXE