Nachdem ich die Entwicklungsdokumentation zu @Dusk vollständig durchgearbeitet habe, ist mir erst jetzt aufgefallen, dass das, was man am meisten ansehen sollte, nicht irgendein TPS-Slogan ist, sondern die Aufteilung des Entwicklungszugangs in zwei Umgebungen: DuskVM und DuskEVM. Das sieht aus wie das Rad doppelt zu erfinden – im Kern geht es aber darum, dass sich „native Privacy-Fähigkeiten“ und „fertiges Entwicklungs-Ökosystem“ nicht auf einmal gleichzeitig lösen lassen.
DuskVM lässt Rust/WASM-Verträge direkt auf L1 laufen. Das ist näher an Phoenix, das Transaktionen abschirmt, ZK-Fähigkeiten und das Modell nativer Assets abbildet. DuskEVM basiert auf OP Stack: Entwickler können weiterhin mit Solidity, Hardhat, Foundry und den vertrauten Wallet-Tools arbeiten. Die Ausführungsergebnisse werden dann über DuskDS zur Abrechnung und Datenverfügbarkeit weitergeleitet. Kurz gesagt: Das eine ist wie ein spezialisiertes Labor – tiefgehend, aber mit hoher Einstiegshürde; das andere ist wie eine standardisierte Schnittstelle – schnell angeschlossen, erfordert jedoch die Koordination über mehrere Ebenen.
Dieser Weg ist in der Tat pragmatisch. Viele Privacy-Chain-Technologien sind sehr aufwendig – am Ende bleiben sie jedoch stecken, weil sich niemand wirklich dafür entwickeln will. Klassische EVM-Chain-Tools sind zwar umfassend, aber sie können nativen Umgang mit regulierten Assets nur schwer abbilden: für Vertraulichkeit und selektive Offenlegung fehlt oft die passende „native“ Unterstützung. Dusk lässt beide Arten von Entwicklern zurück – zumindest wird damit das alte Problem vermieden, dass die Technik zwar „korrekt“ ist, aber das Ökosystem leer bleibt.
Doch der Bonus kommt nicht umsonst: Zwei Umgebungen bedeuten mehr Engineering-Komplexität. Wo der Vertrag jeweils liegt, wie Assets über Ebenen hinweg fließen und welche Ebene im Fehlerfall verantwortlich ist – all das erhöht den Aufwand. Vor allem hängt DuskEVM von DuskDS für Abrechnung und Datenverfügbarkeit ab. Für die Nutzer sieht es zwar nach einer vertrauten EVM-Oberfläche aus, darunter ist es aber keine gewöhnliche Ethereum-Sidechain. Wenn Dokumentation, Browser und Hinweise zum Status über die Ebenen hinweg nicht mitkommen, erzeugen Kompatibilitätsprobleme sogar neue Kosten beim Verstehen.
Ich ziehe außerdem nicht nur aufgrund von „Unterstützung für Solidity“ das Fazit, dass die Entwicklerbasis von #dusk wachsen wird. Als Nächstes lohnt vor allem der Blick auf Folgendes: die tatsächliche Anzahl echter Verträge im Mainnet, ob die Pfade für Assets über Ebenen hinweg reibungslos funktionieren, und wann Hedger-ähnliche Privacy-Fähigkeiten zu wiederverwendbaren Bausteinen werden. $DUSK ist als Gas- und Sicherheits-Asset in beiden Umgebungen zwar wertvoll – aber der endgültige Wert muss sich über reale Aufrufzahlen beweisen, nicht über Architekturdiagramme im Kreis.
Findest du, dass zwei Ausführungsumgebungen kluge Arbeitsteilung sind, oder sie eher die Wartungsschwierigkeiten vervielfachen? Hinterlasse gern deine Einschätzung.
$BTW $ETH
DuskVM lässt Rust/WASM-Verträge direkt auf L1 laufen. Das ist näher an Phoenix, das Transaktionen abschirmt, ZK-Fähigkeiten und das Modell nativer Assets abbildet. DuskEVM basiert auf OP Stack: Entwickler können weiterhin mit Solidity, Hardhat, Foundry und den vertrauten Wallet-Tools arbeiten. Die Ausführungsergebnisse werden dann über DuskDS zur Abrechnung und Datenverfügbarkeit weitergeleitet. Kurz gesagt: Das eine ist wie ein spezialisiertes Labor – tiefgehend, aber mit hoher Einstiegshürde; das andere ist wie eine standardisierte Schnittstelle – schnell angeschlossen, erfordert jedoch die Koordination über mehrere Ebenen.
Dieser Weg ist in der Tat pragmatisch. Viele Privacy-Chain-Technologien sind sehr aufwendig – am Ende bleiben sie jedoch stecken, weil sich niemand wirklich dafür entwickeln will. Klassische EVM-Chain-Tools sind zwar umfassend, aber sie können nativen Umgang mit regulierten Assets nur schwer abbilden: für Vertraulichkeit und selektive Offenlegung fehlt oft die passende „native“ Unterstützung. Dusk lässt beide Arten von Entwicklern zurück – zumindest wird damit das alte Problem vermieden, dass die Technik zwar „korrekt“ ist, aber das Ökosystem leer bleibt.
Doch der Bonus kommt nicht umsonst: Zwei Umgebungen bedeuten mehr Engineering-Komplexität. Wo der Vertrag jeweils liegt, wie Assets über Ebenen hinweg fließen und welche Ebene im Fehlerfall verantwortlich ist – all das erhöht den Aufwand. Vor allem hängt DuskEVM von DuskDS für Abrechnung und Datenverfügbarkeit ab. Für die Nutzer sieht es zwar nach einer vertrauten EVM-Oberfläche aus, darunter ist es aber keine gewöhnliche Ethereum-Sidechain. Wenn Dokumentation, Browser und Hinweise zum Status über die Ebenen hinweg nicht mitkommen, erzeugen Kompatibilitätsprobleme sogar neue Kosten beim Verstehen.
Ich ziehe außerdem nicht nur aufgrund von „Unterstützung für Solidity“ das Fazit, dass die Entwicklerbasis von #dusk wachsen wird. Als Nächstes lohnt vor allem der Blick auf Folgendes: die tatsächliche Anzahl echter Verträge im Mainnet, ob die Pfade für Assets über Ebenen hinweg reibungslos funktionieren, und wann Hedger-ähnliche Privacy-Fähigkeiten zu wiederverwendbaren Bausteinen werden. $DUSK ist als Gas- und Sicherheits-Asset in beiden Umgebungen zwar wertvoll – aber der endgültige Wert muss sich über reale Aufrufzahlen beweisen, nicht über Architekturdiagramme im Kreis.
Findest du, dass zwei Ausführungsumgebungen kluge Arbeitsteilung sind, oder sie eher die Wartungsschwierigkeiten vervielfachen? Hinterlasse gern deine Einschätzung.
$BTW $ETH
