Mein Cousin betreibt hinter seinem Haus zwei getrennte Workshops — einen für Holzarbeiten, einen für Schweißen. Ich habe ihn einmal gefragt, warum er nicht einfach eine kombinierte Werkstatt baut und für alles nutzt. Er meinte, sobald man versucht, einen einzigen Raum für beide Aufgaben gut einzusetzen, kommt man bei beiden Kompromisse eingegangen.
Ich ging davon aus, dass die Ausführungsschicht von Dusk so funktioniert wie die meisten Ketten, die ich mir angesehen hatte — EVM auswählen, bereitstellen, fertig. Diese Annahme zerbrach, als ich nachvollzog, was DuskVM tatsächlich ist.
DuskVM läuft auf Wasmtime und führt Rust/WASM-Verträge direkt auf Dusk’s L1 aus — eine völlig separate Umgebung von DuskEVM, nicht einfach eine Schicht, die daran „angeflanscht“ ist. Sie existiert ganz speziell für Verträge, die direkten Zugriff auf Dusk’s native Transaktionsmodelle, Privatsphäre und Zero-Knowledge-Fähigkeiten benötigen — genau die Dinge, für die das EVM-Ausführungsmodell nie gebaut wurde, um sie nativ offenzulegen.
Piecrust, die Engine darunter, ersetzte Dusk’s ursprüngliches RuskVM genau deshalb, weil RuskVM bei State-Wachstum und Performance an Grenzen stieß, die Dusk vor dem Skalieren der tokenisierten regulierten Vermögenswerte gelöst haben musste. In Dusk’s eigenen technischen Notizen heißt es, dass Piecrust RuskVM um mehr als das Zehnfache übertrifft — keine Schätzung, sondern ein direkt veröffentlichter Vergleich — mit PLONK-, Groth16- und BLS-Host-Funktionen, die direkt in die Laufzeit integriert sind.
DuskEVM übernimmt die andere Aufgabe komplett — vollständige EVM-Äquivalenz, standardmäßige Solidity-Tooling, Abrechnung über DuskDS für Entwickler, die vertraute Workflows wollen, ohne privacy-native primitiven zu benötigen.
Der eigentliche Test für DUSK ist, ob es sich wirklich auszahlt, diese beiden Umgebungen konsequent getrennt zu halten — statt privacy-native Verträge durch ein Ausführungsmodell zu pressen, das für etwas anderes gebaut wurde — und zwar, während die Adoption auf beiden Seiten wächst.
Gewinnt man durch zwei dedizierte Umgebungen einen echten Vorteil gegenüber einer kompromittierten Lösung, oder bedeutet es am Ende einfach doppelt so viel Wartungsaufwand bei nur halb so viel Klarheit?
#dusk $DUSK @Dusk
Ich ging davon aus, dass die Ausführungsschicht von Dusk so funktioniert wie die meisten Ketten, die ich mir angesehen hatte — EVM auswählen, bereitstellen, fertig. Diese Annahme zerbrach, als ich nachvollzog, was DuskVM tatsächlich ist.
DuskVM läuft auf Wasmtime und führt Rust/WASM-Verträge direkt auf Dusk’s L1 aus — eine völlig separate Umgebung von DuskEVM, nicht einfach eine Schicht, die daran „angeflanscht“ ist. Sie existiert ganz speziell für Verträge, die direkten Zugriff auf Dusk’s native Transaktionsmodelle, Privatsphäre und Zero-Knowledge-Fähigkeiten benötigen — genau die Dinge, für die das EVM-Ausführungsmodell nie gebaut wurde, um sie nativ offenzulegen.
Piecrust, die Engine darunter, ersetzte Dusk’s ursprüngliches RuskVM genau deshalb, weil RuskVM bei State-Wachstum und Performance an Grenzen stieß, die Dusk vor dem Skalieren der tokenisierten regulierten Vermögenswerte gelöst haben musste. In Dusk’s eigenen technischen Notizen heißt es, dass Piecrust RuskVM um mehr als das Zehnfache übertrifft — keine Schätzung, sondern ein direkt veröffentlichter Vergleich — mit PLONK-, Groth16- und BLS-Host-Funktionen, die direkt in die Laufzeit integriert sind.
DuskEVM übernimmt die andere Aufgabe komplett — vollständige EVM-Äquivalenz, standardmäßige Solidity-Tooling, Abrechnung über DuskDS für Entwickler, die vertraute Workflows wollen, ohne privacy-native primitiven zu benötigen.
Der eigentliche Test für DUSK ist, ob es sich wirklich auszahlt, diese beiden Umgebungen konsequent getrennt zu halten — statt privacy-native Verträge durch ein Ausführungsmodell zu pressen, das für etwas anderes gebaut wurde — und zwar, während die Adoption auf beiden Seiten wächst.
Gewinnt man durch zwei dedizierte Umgebungen einen echten Vorteil gegenüber einer kompromittierten Lösung, oder bedeutet es am Ende einfach doppelt so viel Wartungsaufwand bei nur halb so viel Klarheit?
#dusk $DUSK @Dusk