#dusk $DUSK Ich habe heute in den DuskEVM-Testnetzdokumenten von @Dusk gelesen. Zuerst dachte ich: „Dusk unterstützt endlich Solidity“ – eine standardmäßige, EVM-kompatible Schicht, sodass Entwickler einfach Ethereum-Verträge rüberportieren und loslegen können. Doch als ich die Beziehung zwischen DuskEVM und DuskDS in der Architekturzeichnung sah, merkte ich: so einfach ist es nicht.
DuskEVM basiert auf OP Stack, nutzt die standardmäßige Ethereum-JSON-RPC-Schnittstelle, Chain ID745, und als Gas-Token dient weiterhin $DUSK . Entwickler können mit Foundry oder Hardhat Verträge bereitstellen, und der Testnet-Explorer ist ebenfalls Blockscout. Auf den ersten Blick sieht das im Grunde wie jede andere OP-Stack-Kette aus.
Der Knackpunkt: DuskEVM übernimmt nicht selbst Abrechnung (Settlement) und DA. Es verlagert die Ausführung auf die EVM-Schicht, während Abrechnung und Datenverfügbarkeit an DuskDS gehen – also die Konsens- und Finality-Schicht von Dusk L1. Das bedeutet: Die EVM-Verträge laufen zwar in einer kompatiblen Umgebung, aber der finale Zustand wird durch den Succinct-Attestation-Konsens von DuskDS festgelockt. Man erhält also deterministische Finalität – statt nur probabilistischer Bestätigung.
Ich würde es so vergleichen: Das ist nicht so, als würde man in der Innenstadt ein weiteres Einkaufszentrum mit exakt denselben Spezifikationen eröffnen. Eher so, dass die Läden im Einkaufszentrum ein Kassensystem benutzen, das alle kennen (EVM) – aber jede einzelne Buchung am Ende trotzdem im Tresor des Hauptsitzes (DuskDS) abgerechnet wird. Für Kund:innen fühlt sich der Unterschied nicht an, aber bei Audit und Compliance zählt das Hauptbuch, nicht der Kassen-Cache.
Hier gibt es eine leicht übersehbare Einschränkung: DuskEVM und Dusk L1 sind über eine Bridge miteinander verbunden. DUSK ist in den Kontensystemen auf beiden Seiten dieselbe Art von Asset, doch für Transfers über die Ebenen ist ein Bridge-Vorgang nötig. Wenn die Bridge-Liquidität knapp ist oder die Verzögerung zu hoch, leidet die DeFi-Erfahrung auf der EVM-Ebene. In der Phase des Testnetzes gibt es derzeit noch nicht viele belastbare Daten zu tatsächlichem Durchsatz und Latenz der Bridge. @Dusk
Daher, wenn man auf den Schritt „EVM“ bei #dusk schaut, werde ich vor allem auf die reale Anzahl der bereitgestellten Verträge im Testnetz achten, auf die Verteilung der Bridge-Delays sowie auf die Reibungskosten für den Asset-Transfer zwischen DuskEVM und Dusk L1. $DUSK Nur einen EVM-Einstieg zu haben heißt nicht, dass Entwickler automatisch kommen – entscheidend ist, ob es danach gelingt, sie auch zu halten.