Früher dachte ich, der modulare Stack von Dusk sei hauptsächlich auf Performance ausgelegt. Dann merkte ich, dass die Trennung tiefer geht.

DuskDS übernimmt Konsens, Abrechnung und Datenverfügbarkeit. DuskEVM und DuskVM bieten zwei Ausführungspfade, die um DuskDS herum gebaut sind.
Sie führen Anwendungslogik aus, während DuskDS die zugrunde liegenden Mechanismen für Konsens und Finalität bereitstellt.
DuskEVM nutzt DuskDS für Abrechnung und Datenverfügbarkeit, während DuskVM direkt auf der Dusk-L1 ausführt und DuskDS Konsens und Finalität liefert.

Architektonisch klingt das sauber.
Aber die Lücke ist entscheidend, weil Entwickler jetzt über zwei Ebenen nachdenken müssen: ihre Vertragslogik und die darunterliegende Abrechnungsschicht, die tatsächlich entscheidet, was als wahr gilt.

Die meisten vergleichen EVM-Kompatibilität vs. native Ausführung.
Ich denke, der schärfere Vergleich ist Upgrade-Flexibilität vs. zusätzlicher Denk-/Begründungsaufwand.
Änderungen an DuskDS können beide Ausführungspfade beeinflussen, weil sie von seiner zugrunde liegenden Abrechnungs- und Datenverfügbarkeitsinfrastruktur abhängen.

Macht diese Trennung regulierte Anwendungen leichter zertifizierbar – oder verlagert sie nur mehr Komplexität in die Cross-Layer-Infrastruktur, die Entwickler möglicherweise gar nicht sehen?

#dusk $DUSK @Dusk
$GPS $TUT