Ich habe ein häufiges Missverständnis erst dann auseinandergeklickt, als ich die neuesten Entwicklersdokumente zu @Dusk abgeglichen habe: DuskEVM und DuskVM sind nicht dieselbe virtuelle Maschine mit zwei neuen Namen, und auch nicht so, dass „ein neues EVM die nativen Chains wegwischt“. Die Doku für Entwickler liefert zwei Ausführungspfade: Wer mit Solidity, Foundry und Hardhat vertraut ist, nutzt DuskEVM; wer direkt mit L1-Assets zu tun hat, Phoenix/Moonlight, Logik rund um Rust/WASM oder Zero-Knowledge-Fähigkeiten braucht, geht über DuskVM.
DuskEVM ist der OP-Stack-Pfad: Ausführung und Tools sollen so nah wie möglich am Ethereum-Ökosystem bleiben, und Abrechnung sowie Datenveröffentlichung übernimmt DuskDS; $DUSK macht weiterhin das Gas. DuskVM läuft dagegen direkt auf L1 und führt WASM-Contracts aus—dadurch ist es näher am nativen Transaction-Modell und an den Protokollfähigkeiten. Das eine reduziert die Migrationskosten, das andere bewahrt die Differenzierungsfähigkeit: Das eine adressiert die Frage „Kommen Entwickler überhaupt?“, das andere „Können sie danach auch Dinge tun, die ein normales EVM nicht sauber kann“.
Doch beide Wege erzeugen auch neue Kosten. Wie Assets über Layer hinweg übertragen werden, wo derselbe Business-Flow seinen Zustand ablegt, und wie EVM-Anwendungen an Hegderes geheime Prozesse angebunden werden—das erledigt sich nicht automatisch nur, weil irgendwo „modular“ steht. Die offizielle DuskEVM-Bridge-Anleitung über Layer hinweg zeigt aktuell eindeutig nur den Testnet-Prozess. Für Withdrawals braucht es zudem drei on-chain Schritte: Initiierung, Beweis und abschließende Bestätigung—man kann die Architekturkarte also nicht vorschnell als reibungsloses Mainnet-Erlebnis skizzieren.
Wenn ich die Multi-Layer-Route von #dusk bewerte, zähle ich nicht einfach nur, wie viele Sprachen unterstützt werden. Ich achte darauf, in welcher Schicht die Anwendung wirklich landet, wie man sich von einem Cross-Layer-Fehlschlag erholt und ob die Privacy-Funktionen direkt von Entwicklern aufgerufen werden können. Sollte die neue Chain zuerst mit EVM laufen, um die Ökosystem-Geschwindigkeit zu holen, oder zuerst die Integrität nativer Techniken bewahren?
DuskEVM ist der OP-Stack-Pfad: Ausführung und Tools sollen so nah wie möglich am Ethereum-Ökosystem bleiben, und Abrechnung sowie Datenveröffentlichung übernimmt DuskDS; $DUSK macht weiterhin das Gas. DuskVM läuft dagegen direkt auf L1 und führt WASM-Contracts aus—dadurch ist es näher am nativen Transaction-Modell und an den Protokollfähigkeiten. Das eine reduziert die Migrationskosten, das andere bewahrt die Differenzierungsfähigkeit: Das eine adressiert die Frage „Kommen Entwickler überhaupt?“, das andere „Können sie danach auch Dinge tun, die ein normales EVM nicht sauber kann“.
Doch beide Wege erzeugen auch neue Kosten. Wie Assets über Layer hinweg übertragen werden, wo derselbe Business-Flow seinen Zustand ablegt, und wie EVM-Anwendungen an Hegderes geheime Prozesse angebunden werden—das erledigt sich nicht automatisch nur, weil irgendwo „modular“ steht. Die offizielle DuskEVM-Bridge-Anleitung über Layer hinweg zeigt aktuell eindeutig nur den Testnet-Prozess. Für Withdrawals braucht es zudem drei on-chain Schritte: Initiierung, Beweis und abschließende Bestätigung—man kann die Architekturkarte also nicht vorschnell als reibungsloses Mainnet-Erlebnis skizzieren.
Wenn ich die Multi-Layer-Route von #dusk bewerte, zähle ich nicht einfach nur, wie viele Sprachen unterstützt werden. Ich achte darauf, in welcher Schicht die Anwendung wirklich landet, wie man sich von einem Cross-Layer-Fehlschlag erholt und ob die Privacy-Funktionen direkt von Entwicklern aufgerufen werden können. Sollte die neue Chain zuerst mit EVM laufen, um die Ökosystem-Geschwindigkeit zu holen, oder zuerst die Integrität nativer Techniken bewahren?
