Was mich nicht überrascht hat, war die Tatsache, dass Dusk zwei Ausführungsumgebungen unterstützt. Es war der Grund dafür, dass diese Wahl später unpraktisch werden könnte.

Also bietet DuskVM nativen Rust/WASM-Entwicklern ihren eigenen Weg, während DuskEVM Solidity-Teams in vertrauten Werkzeugen belässt. Das ist praktisch. Entwickler müssen nicht alles, was sie bereits wissen, wegwerfen, nur um auf Dusk aufzubauen.

Die Komplikation zeigt sich erst, wenn die Einführung tatsächlich funktioniert.
Wenn beide Umgebungen echte Anwendungen anziehen, könnte Dusk am Ende zwei Entwicklerkulturen haben, die nebeneinander wachsen. Unterschiedliche Tools, unterschiedliche Vertragsgewohnheiten, unterschiedliche Erwartungen daran, wie Apps miteinander interagieren.

Das muss nicht zwangsläufig irgendetwas kaputtmachen. Aber es kann das Ökosystem schwieriger machen, es kohärent zusammenzuhalten.

Was ich interessant finde, ist: Dusk reduziert möglicherweise eine Art von Reibung, schafft aber still und leise eine andere. Entwickler einzugewöhnen wird einfacher. Die beiden Welten sich wie ein einziges Netzwerk anfühlen zu lassen, könnte schwieriger werden.
Ich würde beobachten, was passiert, sobald Nutzer nicht mehr darauf achten, in welcher Umgebung eine App läuft. Wahrscheinlich ist das der Zeitpunkt, an dem diese Designentscheidung wirklich auf die Probe gestellt wird.
@Dusk_Foundation $DUSK #dusk