Ein Detail in Dusk, das ich immer wieder noch interessanter finde, sind die zwei unterschiedlichen Wege, die Entwickler einschlagen können.
Ein Team kann direkt auf der nativen Ebene aufbauen und dafür Rust, WASM, DuskVM sowie native ZK-Funktionalität nutzen. Ein anderes Team kann über DuskEVM kommen – mit Solidity, Foundry, Hardhat, viem oder ethers – und dabei weiterhin DUSK für Gas sowie DuskDS für Settlement und Datenverfügbarkeit verwenden.
Diese Trennung ergibt für mich Sinn, weil regulierte Finanzen wahrscheinlich nicht jede Anwendung genau auf dieselbe Weise brauchen. Einige Teams möchten vielleicht maximalen Einfluss auf Privatsphäre und Ausführung haben, während andere lieber die Tools beibehalten möchten, die sie bereits kennen. Dusk scheint zu versuchen, beides zu ermöglichen, statt Entwickler in nur eine Route zu zwingen.
Das Interessante ist, dass DuskEVM sich noch im Testnet befindet, während die native Dusk-Ebene bereits live ist. Ich mag diese Unterscheidung tatsächlich, weil sie die Roadmap leichter beurteilbar macht. Die Story zur EVM-Kompatibilität muss sich noch anhand echter Anwendungen beweisen – nicht nur anhand von Dokumentation.
Mich interessiert, wie das Entwickler-Ökosystem aussehen wird, sobald beide Wege gereift sind. Werden Builder hauptsächlich den vertrauten EVM-Weg wählen, oder wird die native Dusk-Stack-Option für Anwendungen, bei denen Privatsphäre und regulierte Assets wirklich wichtig sind, spannender werden?
$DUSK @Dusk #dusk
Ein Team kann direkt auf der nativen Ebene aufbauen und dafür Rust, WASM, DuskVM sowie native ZK-Funktionalität nutzen. Ein anderes Team kann über DuskEVM kommen – mit Solidity, Foundry, Hardhat, viem oder ethers – und dabei weiterhin DUSK für Gas sowie DuskDS für Settlement und Datenverfügbarkeit verwenden.
Diese Trennung ergibt für mich Sinn, weil regulierte Finanzen wahrscheinlich nicht jede Anwendung genau auf dieselbe Weise brauchen. Einige Teams möchten vielleicht maximalen Einfluss auf Privatsphäre und Ausführung haben, während andere lieber die Tools beibehalten möchten, die sie bereits kennen. Dusk scheint zu versuchen, beides zu ermöglichen, statt Entwickler in nur eine Route zu zwingen.
Das Interessante ist, dass DuskEVM sich noch im Testnet befindet, während die native Dusk-Ebene bereits live ist. Ich mag diese Unterscheidung tatsächlich, weil sie die Roadmap leichter beurteilbar macht. Die Story zur EVM-Kompatibilität muss sich noch anhand echter Anwendungen beweisen – nicht nur anhand von Dokumentation.
Mich interessiert, wie das Entwickler-Ökosystem aussehen wird, sobald beide Wege gereift sind. Werden Builder hauptsächlich den vertrauten EVM-Weg wählen, oder wird die native Dusk-Stack-Option für Anwendungen, bei denen Privatsphäre und regulierte Assets wirklich wichtig sind, spannender werden?
$DUSK @Dusk #dusk