Als DuskEVM existierte, hätte das Dusk Network eine einfachere Präsentation liefern können: eine einzige Ausführungsumgebung, Solidity für alle – fertig. Stattdessen ist in der Dokumentation klar festgehalten, dass die native Dusk-Entwicklung, also Rust-Verträge, die zu WASM kompiliert und von DuskVM ausgeführt werden, weiterhin der empfohlene Weg ist, wann immer eine Anwendung Protokollsteuerung, benutzerdefinierte Transaktionsmodelle oder Zero-Knowledge-Fähigkeiten benötigt, die nah an der Basisschicht liegen. Ich finde diese Entscheidung interessant, sie zu verteidigen, denn das Betreiben zweier Ausführungspfade ist teurer im Aufbau und in der Erklärung als die Pflege nur eines.
Die Logik scheint zu sein, dass DuskEVM und DuskVM für unterschiedliche Kundengruppen optimiert sind, statt um dieselbe Zielgruppe zu konkurrieren. Ein Team, das ein bestehendes Ethereum-DeFi-Protokoll portiert, möchte vertraute Tools, vorhandene Audits und Wallets, die bereits funktionieren – dafür ist DuskEVM da. Ein Team, das Logik für Wertpapierabwicklungen entwickelt, mit begrenzten Übertragungen, Dividendenausschüttungen oder Compliance-Regeln, die direkt in einen Vertrag eingebaut sind, liegt näher an dem, wofür Zedger und native DuskVM-Verträge von Anfang an konzipiert wurden, denn dieses hybride Transaktionsmodell wurde genau für diese Art von Security-Token-Buchführung entwickelt, statt nachträglich aus einem allgemeinen Muster „angepasst“ zu werden.
Ich bin nicht ganz überzeugt, dass dieser Zwei-Wege-Ansatz verhindert, dass die eigene Entwicklerbasis des Dusk Network und der Dokumentationsaufwand über zwei Zielgruppen hinweg fragmentiert werden, anstatt sich hinter einer einzigen zu konzentrieren. Zwei Ausführungsumgebungen bedeuten zwei Sätze von Tools, die man pflegen muss, zwei mentale Modelle für neue Mitwirkende und zwei Antworten auf die einfache Frage, wo eine neue Anwendung tatsächlich gebaut werden sollte. Ich verstehe die Wette, denn eine frühe Beschränkung auf einen Pfad hätte stillschweigend die jeweils nicht berücksichtigte Zielgruppe abgehängt. Ob das Dusk Network in den kommenden Jahren groß genug bleibt, um beide Pfade richtig zu unterstützen, lohnt sich jedenfalls zu beobachten.
#dusk $DUSK @Dusk
Die Logik scheint zu sein, dass DuskEVM und DuskVM für unterschiedliche Kundengruppen optimiert sind, statt um dieselbe Zielgruppe zu konkurrieren. Ein Team, das ein bestehendes Ethereum-DeFi-Protokoll portiert, möchte vertraute Tools, vorhandene Audits und Wallets, die bereits funktionieren – dafür ist DuskEVM da. Ein Team, das Logik für Wertpapierabwicklungen entwickelt, mit begrenzten Übertragungen, Dividendenausschüttungen oder Compliance-Regeln, die direkt in einen Vertrag eingebaut sind, liegt näher an dem, wofür Zedger und native DuskVM-Verträge von Anfang an konzipiert wurden, denn dieses hybride Transaktionsmodell wurde genau für diese Art von Security-Token-Buchführung entwickelt, statt nachträglich aus einem allgemeinen Muster „angepasst“ zu werden.
Ich bin nicht ganz überzeugt, dass dieser Zwei-Wege-Ansatz verhindert, dass die eigene Entwicklerbasis des Dusk Network und der Dokumentationsaufwand über zwei Zielgruppen hinweg fragmentiert werden, anstatt sich hinter einer einzigen zu konzentrieren. Zwei Ausführungsumgebungen bedeuten zwei Sätze von Tools, die man pflegen muss, zwei mentale Modelle für neue Mitwirkende und zwei Antworten auf die einfache Frage, wo eine neue Anwendung tatsächlich gebaut werden sollte. Ich verstehe die Wette, denn eine frühe Beschränkung auf einen Pfad hätte stillschweigend die jeweils nicht berücksichtigte Zielgruppe abgehängt. Ob das Dusk Network in den kommenden Jahren groß genug bleibt, um beide Pfade richtig zu unterstützen, lohnt sich jedenfalls zu beobachten.
#dusk $DUSK @Dusk
