#dusk $DUSK @Dusk bin heute rausgegangen und hab nach dem Grund gesucht, warum Dusk überhaupt dafür sorgt, zwei getrennte Ausführungsumgebungen zu fahren, statt einfach eine auszuwählen – und ehrlich? 😂 die Antwort stellte sich als eher echter Kompromiss heraus als als technischen Flex.
also: DuskVM ist eine Wasm-Umgebung, die um Wasmtime herum gebaut ist, und sie wird direkt auf dem Dusk L1 ausgeführt, ohne den Settlement-Hop, den DuskeVM verlangt – diesen Weg über DuskDS hatte ich vor einiger Zeit schon beschrieben. Sie ist für Rust-Contracts gedacht, die eine engere Integration mit Dusk-eigenen Transaktionsmodellen wollen, mit Protokoll-Level-Assets sowie mit Privacy- oder zk-Fähigkeiten speziell. DuskeVM existiert hingegen rein für Solidity und Standard-EVM-Tooling – Foundry, Hardhat, bestehende Wallets, das ganze Ethereum-Ökosystem, das die Leute bereits kennen. Dunks eigenes Schreiben liefert tatsächlich konkrete Zahlen dazu, warum diese Aufteilung wichtig ist: Demnach kann eine maßgeschneiderte, bespoke L1-Integration sechs bis zwölf Monate dauern und rund fünfzig Mal mehr kosten als ein vergleichbares EVM-Deployment. Außerdem wird explizit darauf verwiesen, dass Exchanges Monate brauchen, um sich an natives Dusk anzupassen, statt Wochen für EVM-Integrationen.
was ich nach dem Lesen dieser Zahlen immer wieder im Kopf habe, ist die Frage, ob diese Kostendifferenz stillschweigend fast alle standardmäßig zu DuskeVM drängt – sogar Projekte, die technisch gesehen mehr von DuskVMs engerer nativer Privacy-Integration profitieren würden. Wenn der Weg des geringsten Widerstands so viel günstiger und schneller ist: Wird dann die schwierigere, aber stärker zweckgebundene Option am Ende trotzdem untergenutzt, unabhängig davon, wie gut sie passen würde? Ich habe nichts gesehen, das diese Spannung direkt anspricht.
aber: Buildern zwei echte Wege zu geben, statt allen ein einziges Kompromissmodell aufzuzwingen, ist eine legitime Antwort auf wirklich unterschiedliche Anforderungen – nicht nur zusätzliches komplexitätszeug um der Komplexität willen.
ehrlich: weiß nicht, ob diese Kostendifferenz am Ende die meisten ernsthaften Projekte zu DuskeVM lenkt oder ob DuskVM für die Use Cases, die es wirklich brauchen, ganz gut für sich steht??
🤔
#dusk @Dusk $DUSK
also: DuskVM ist eine Wasm-Umgebung, die um Wasmtime herum gebaut ist, und sie wird direkt auf dem Dusk L1 ausgeführt, ohne den Settlement-Hop, den DuskeVM verlangt – diesen Weg über DuskDS hatte ich vor einiger Zeit schon beschrieben. Sie ist für Rust-Contracts gedacht, die eine engere Integration mit Dusk-eigenen Transaktionsmodellen wollen, mit Protokoll-Level-Assets sowie mit Privacy- oder zk-Fähigkeiten speziell. DuskeVM existiert hingegen rein für Solidity und Standard-EVM-Tooling – Foundry, Hardhat, bestehende Wallets, das ganze Ethereum-Ökosystem, das die Leute bereits kennen. Dunks eigenes Schreiben liefert tatsächlich konkrete Zahlen dazu, warum diese Aufteilung wichtig ist: Demnach kann eine maßgeschneiderte, bespoke L1-Integration sechs bis zwölf Monate dauern und rund fünfzig Mal mehr kosten als ein vergleichbares EVM-Deployment. Außerdem wird explizit darauf verwiesen, dass Exchanges Monate brauchen, um sich an natives Dusk anzupassen, statt Wochen für EVM-Integrationen.
was ich nach dem Lesen dieser Zahlen immer wieder im Kopf habe, ist die Frage, ob diese Kostendifferenz stillschweigend fast alle standardmäßig zu DuskeVM drängt – sogar Projekte, die technisch gesehen mehr von DuskVMs engerer nativer Privacy-Integration profitieren würden. Wenn der Weg des geringsten Widerstands so viel günstiger und schneller ist: Wird dann die schwierigere, aber stärker zweckgebundene Option am Ende trotzdem untergenutzt, unabhängig davon, wie gut sie passen würde? Ich habe nichts gesehen, das diese Spannung direkt anspricht.
aber: Buildern zwei echte Wege zu geben, statt allen ein einziges Kompromissmodell aufzuzwingen, ist eine legitime Antwort auf wirklich unterschiedliche Anforderungen – nicht nur zusätzliches komplexitätszeug um der Komplexität willen.
ehrlich: weiß nicht, ob diese Kostendifferenz am Ende die meisten ernsthaften Projekte zu DuskeVM lenkt oder ob DuskVM für die Use Cases, die es wirklich brauchen, ganz gut für sich steht??
🤔
#dusk @Dusk $DUSK