#dusk $DUSK @Dusk
Ich habe nachverfolgt, wie DuskVM und DuskEVM tatsächlich die Arbeit auf Dusk aufteilen, denn beide führen zwar Verträge aus, sind aber eindeutig nicht austauschbar.
DuskVM führt Rust/WASM-Verträge aus, die auf Wasmtime basieren, direkt auf Dusk's L1. Es ist der Pfad, der für Verträge gebaut ist, die direkten Zugriff auf Dusk's eigene Transaktionsmodelle, Datenschutzfunktionen oder Zero-Knowledge-Fähigkeiten benötigen — Piecrust's ZK-freundliche Host-Funktionen (PLONK, Groth16, BLS) leben hier ganz speziell.
DuskEVM läuft hingegen woanders. Es ist eine OP-Stack-basierte EVM-Äquivalent-Umgebung — die Testnet-Chain-ID ist in Dusk's eigenen Dokumenten mit 745 bestätigt — sodass Entwickler standardmäßige Solidity-Verträge bereitstellen können, etwa mit MetaMask, Hardhat oder Foundry, während Abrechnung und Veröffentlichung der Daten über DuskDS als Blobs erfolgen, und zwar über einen Sequencer und Batcher, statt dass alles unabhängig voneinander ausgeführt wird.
Ich habe herausgearbeitet, was sie voneinander trennt — nicht nur die Sprache. DuskVM-Verträge bekommen Datenschutz und ZK-Primitive nativerweise direkt auf der Ausführungsebene. DuskEVM-Verträge erhalten volle Tooling-Kompatibilität, und dort zahlen Nutzer ebenfalls Gas in DUSK — aber der Datenweg läuft über eine Schicht, die woanders abrechnet, statt nativ neben Dusk's eigenen Transaktionsmodellen zu laufen.
Beide gleichen sich in einem Punkt — sie rechnen über dieselbe Basis ab: DuskDS — und beide zahlen letztlich Gas in DUSK. Keines ersetzt das andere; jedes existiert, weil das jeweils andere seinen speziellen Job nicht wirklich genauso gut abdecken kann.
Für Builder ist die echte Entscheidung also nicht „welches ist besser“. Es geht darum, ob der Vertrag privacy-native Ausführung braucht oder vertrautes, chain-ID-verifizierbares EVM-Tooling — und Dusk hat zwei getrennte Spuren gebaut, statt eine Umgebung zu erzwingen, beides gleichzeitig zu leisten.
Dient es Build-ern wirklich besser, zwei eigenständig getrennte Ausführungsumgebungen zu pflegen, als eine auszuwählen und sie vollständig zu optimieren?
Ich habe nachverfolgt, wie DuskVM und DuskEVM tatsächlich die Arbeit auf Dusk aufteilen, denn beide führen zwar Verträge aus, sind aber eindeutig nicht austauschbar.
DuskVM führt Rust/WASM-Verträge aus, die auf Wasmtime basieren, direkt auf Dusk's L1. Es ist der Pfad, der für Verträge gebaut ist, die direkten Zugriff auf Dusk's eigene Transaktionsmodelle, Datenschutzfunktionen oder Zero-Knowledge-Fähigkeiten benötigen — Piecrust's ZK-freundliche Host-Funktionen (PLONK, Groth16, BLS) leben hier ganz speziell.
DuskEVM läuft hingegen woanders. Es ist eine OP-Stack-basierte EVM-Äquivalent-Umgebung — die Testnet-Chain-ID ist in Dusk's eigenen Dokumenten mit 745 bestätigt — sodass Entwickler standardmäßige Solidity-Verträge bereitstellen können, etwa mit MetaMask, Hardhat oder Foundry, während Abrechnung und Veröffentlichung der Daten über DuskDS als Blobs erfolgen, und zwar über einen Sequencer und Batcher, statt dass alles unabhängig voneinander ausgeführt wird.
Ich habe herausgearbeitet, was sie voneinander trennt — nicht nur die Sprache. DuskVM-Verträge bekommen Datenschutz und ZK-Primitive nativerweise direkt auf der Ausführungsebene. DuskEVM-Verträge erhalten volle Tooling-Kompatibilität, und dort zahlen Nutzer ebenfalls Gas in DUSK — aber der Datenweg läuft über eine Schicht, die woanders abrechnet, statt nativ neben Dusk's eigenen Transaktionsmodellen zu laufen.
Beide gleichen sich in einem Punkt — sie rechnen über dieselbe Basis ab: DuskDS — und beide zahlen letztlich Gas in DUSK. Keines ersetzt das andere; jedes existiert, weil das jeweils andere seinen speziellen Job nicht wirklich genauso gut abdecken kann.
Für Builder ist die echte Entscheidung also nicht „welches ist besser“. Es geht darum, ob der Vertrag privacy-native Ausführung braucht oder vertrautes, chain-ID-verifizierbares EVM-Tooling — und Dusk hat zwei getrennte Spuren gebaut, statt eine Umgebung zu erzwingen, beides gleichzeitig zu leisten.
Dient es Build-ern wirklich besser, zwei eigenständig getrennte Ausführungsumgebungen zu pflegen, als eine auszuwählen und sie vollständig zu optimieren?
