#dusk $DUSK @Dusk bin heute ausgiebig der Frage nachgegangen, warum „Dusk“ überhaupt zwei getrennte Ausführungsumgebungen betreibt, statt einfach eine auszuwählen—und ehrlich? 😂 Die Antwort stellte sich weniger als technischer Flex heraus, sondern eher als echter Kompromiss.
Also: DuskVM ist eine WASM-Umgebung, die um wasmtime herum gebaut ist, und sie läuft direkt auf dem Dusk L1 selbst, ohne diesen Settlement-Hop, den DuskEVM braucht—über DuskDS, worüber ich vor einiger Zeit geschrieben habe. DuskVM ist vor allem für Rust-Contracts gedacht, die eine engere Integration in die eigenen Transaktionsmodelle von Dusk wollen, Protokoll-Level-Assets sowie Privacy- oder zk-Fähigkeiten. DuskEVM existiert dagegen rein für Solidity und die üblichen EVM-Tools: Foundry, Hardhat, bestehende Wallets, also das komplette Ethereum-Ökosystem, das die Leute ohnehin schon kennen. Dusk selbst liefert dazu offenbar auch echte Zahlen: Eine maßgeschneiderte, bespoke L1-Integration kann wohl sechs bis zwölf Monate dauern und ungefähr fünfzigmal so teuer sein wie ein vergleichbares EVM-Deployment. Außerdem weisen sie darauf hin, dass Exchanges speziell Monate brauchen, um sich an nativen Dusk anzupassen—während es bei EVM-Integrationen eher Wochen sind.
Was ich seit dem Lesen dieser Zahlen immer wieder im Kopf habe, ist: Schiebt diese Kostenlücke vielleicht ganz still fast alle automatisch Richtung DuskEVM—selbst Projekte, die technisch gesehen stärker von DuskVMs engerer nativer Privacy-Integration profitieren würden? Wenn der Weg des geringsten Widerstands so viel günstiger und schneller ist, werden dann am Ende nicht doch die härteren, aber stärker zweckgebundenen Optionen zu wenig genutzt—egal ob sie besser passen? Ich habe nichts gesehen, das diese Spannung direkt anspricht.
Trotzdem: Zwei echte Pfade für Builder anzubieten, statt allen ein einziges Kompromissmodell aufzuzwingen, ist eine legitime Antwort auf wirklich unterschiedliche Anforderungen—nicht nur „zusätzliche Komplexität“ um ihrer selbst willen.
Ich weiß ehrlich nicht, ob diese Kostenlücke am Ende die meisten ernsthaften Projekte Richtung DuskEVM lenkt oder ob DuskVM sich für genau die Use Cases behauptet, die es wirklich brauchen??
🤔
#dusk @Dusk $DUSK
Also: DuskVM ist eine WASM-Umgebung, die um wasmtime herum gebaut ist, und sie läuft direkt auf dem Dusk L1 selbst, ohne diesen Settlement-Hop, den DuskEVM braucht—über DuskDS, worüber ich vor einiger Zeit geschrieben habe. DuskVM ist vor allem für Rust-Contracts gedacht, die eine engere Integration in die eigenen Transaktionsmodelle von Dusk wollen, Protokoll-Level-Assets sowie Privacy- oder zk-Fähigkeiten. DuskEVM existiert dagegen rein für Solidity und die üblichen EVM-Tools: Foundry, Hardhat, bestehende Wallets, also das komplette Ethereum-Ökosystem, das die Leute ohnehin schon kennen. Dusk selbst liefert dazu offenbar auch echte Zahlen: Eine maßgeschneiderte, bespoke L1-Integration kann wohl sechs bis zwölf Monate dauern und ungefähr fünfzigmal so teuer sein wie ein vergleichbares EVM-Deployment. Außerdem weisen sie darauf hin, dass Exchanges speziell Monate brauchen, um sich an nativen Dusk anzupassen—während es bei EVM-Integrationen eher Wochen sind.
Was ich seit dem Lesen dieser Zahlen immer wieder im Kopf habe, ist: Schiebt diese Kostenlücke vielleicht ganz still fast alle automatisch Richtung DuskEVM—selbst Projekte, die technisch gesehen stärker von DuskVMs engerer nativer Privacy-Integration profitieren würden? Wenn der Weg des geringsten Widerstands so viel günstiger und schneller ist, werden dann am Ende nicht doch die härteren, aber stärker zweckgebundenen Optionen zu wenig genutzt—egal ob sie besser passen? Ich habe nichts gesehen, das diese Spannung direkt anspricht.
Trotzdem: Zwei echte Pfade für Builder anzubieten, statt allen ein einziges Kompromissmodell aufzuzwingen, ist eine legitime Antwort auf wirklich unterschiedliche Anforderungen—nicht nur „zusätzliche Komplexität“ um ihrer selbst willen.
Ich weiß ehrlich nicht, ob diese Kostenlücke am Ende die meisten ernsthaften Projekte Richtung DuskEVM lenkt oder ob DuskVM sich für genau die Use Cases behauptet, die es wirklich brauchen??
🤔
#dusk @Dusk $DUSK