Als ich zum ersten Mal die Architektur von DUSK gesehen habe, hatte ich eine Frage: Warum braucht es zwei virtuelle Maschinen? DuskVM führt native Smart Contracts aus, und DuskEVM führt Ethereum-kompatible Contracts aus. Ist das nicht eine zusätzliche Komplexität? Doch bei genauerer Recherche habe ich herausgefunden, dass dieses Design eigentlich ein sehr reales Problem lösen soll: das Abwägen von Sicherheit und Performance.
DuskVM ist die native virtuelle Maschine von DUSK. Sie läuft direkt auf der Konsensschicht und kann auf alle zugrunde liegenden Funktionen zugreifen, etwa Zero-Knowledge-Proofs, Privacy-Transaktionen und das Phoenix-Protokoll. DuskEVM basiert auf OP Stack: Es führt Ethereum-Smart-Contracts aus, die finale Abrechnung jedoch wird von DuskDS übernommen. Der entscheidende Unterschied ist: In DuskVM sind Contracts direkt an die Konsenssicherheit von DUSK gebunden, während Contracts in DuskEVM auf eine externe Bridging-Schicht angewiesen sind.
Das führt zu einer interessanten Aufgabenverteilung: Sensible Assets (z. B. RWA-Tokens, Compliance-Assets) sollten auf DuskVM liegen, weil sie die Privacy- und Compliance-Fähigkeiten von DUSK direkt nutzen müssen. Normale DeFi-Anwendungen (z. B. dezentrale Börsen, Kreditprotokolle) können hingegen auf DuskEVM laufen, denn Entwickler müssen nur bestehenden Ethereum-Code migrieren und sparen sich so die Mühe, Contracts komplett neu zu schreiben.
Ich habe mir dazu auch Entwickler-Feedback angesehen: Wenn man auf DuskEVM ein Uniswap-V2-Clone bereitstellt, muss man nur etwa 20 Zeilen Code anpassen (hauptsächlich zur Integration der Netzwerkparameter). Wenn man dagegen auf DuskVM von Null an entwickeln will, braucht man dagegen Hunderte Zeilen Code. Dafür sind die Transaktionen auf DuskVM schneller (im Schnitt 1,5 Sekunden pro Block) und es fallen keine Bridging-Gebühren an. Das ist also im Kern eine Entscheidung zwischen „Entwicklungs-Effizienz“ und „Performance“.
Ein weiterer Punkt, der besonders beachtet werden sollte, ist die Sicherheitsisolation. Die Daten von DuskVM und DuskEVM sind physisch voneinander getrennt; die Contracts in DuskEVM können nicht direkt auf den Privacy-Status von DuskVM zugreifen. Das verhindert Angriffe wie den „Flashloan-Angriff“, die durch Schwachstellen beim Zugriff über Ebenen hinweg ausgenutzt werden könnten. In einem Sicherheitsaudit im September 2025 hat DUSK den Fokus auf Tests bei Aufrufen zwischen den VMs gelegt. Dabei wurde festgestellt, dass alle Aufrufe über ein „Sandbox-Gateway“ laufen müssen; dieses Gateway prüft die Berechtigungen und den Typ des Aufrufers und verhindert, dass bösartiger Code durchdringt. $BTC
Ich denke jedoch, dass diese Dual-Architektur auch potenzielle Risiken birgt: Wenn in der Bridging-Logik zwischen den beiden VMs eine Schwachstelle existiert, könnte sie ausgenutzt werden. Beispielsweise könnte ein Angreifer einen DuskEVM-Contract-Aufruf fälschen, um Ressourcen von DuskVM zu verbrauchen.
#dusk @Dusk $DUSK