#dusk $DUSK Vor ein paar Tagen habe ich auf Boreas RC1 einen Test-Contract deployed und festgestellt, dass das Nonce-Management von DuskEVM einen kleinen Unterschied zum Standard-EVM hat – kein Bug, sondern eine bewusste Design-Entscheidung. In Ethereum ist Nonce strikt monoton steigend; Transaktionen werden anhand der Nonce-Reihenfolge gepackt, und bei ausgelassenen Nonces bleibt die Queue stecken. Aber DuskEVM hat auf der Ebene der pending_sequencer eine Anpassung: Das Nonce-Fenster für parallele Transaktionen derselben Adresse wird auf ±3 erweitert. Der Sequencer kann die Reihenfolge in der Sortierphase dynamisch umsortieren.
Warum wurde das gemacht? Weil der Blockerzeugungsrhythmus von DuskDS nicht fix bei 12 Sekunden ist, sondern probabilistisch. Blind-Auktionen mit Ziehung führen zu Jitter in den Blockintervallen. Wenn man strikt monoton steigende Nonces erzwingt, können bei der NPEX-Anleihe-DvP-Abwicklung die Bestätigungs-Transaktionen von Käufer- und Verkäuferseite aufgrund von Blockverzögerungen Nonce-Konflikte verursachen – die Abwicklungs-Fehlerrate würde steigen. Das Aufweiten des Nonce-Fensters ist im Kern ein Tausch: „Sortier-Flexibilität“ gegen „Abwicklungs-Bestimmtheit“.
Der Preis dafür ist allerdings eine vergrößerte Angriffsfläche für MEV. Ein Nonce-Fenster von ±3 bedeutet, dass der Sequencer innerhalb von drei Blockfenstern Transaktionen umsortieren kann. Wenn ein Sequencer-Node selbst NPEX-Markmaking-Strategien fährt, könnte er theoretisch eigene Abwicklungs-Transaktionen dazwischen schieben. Im GitHub-Discussion-Thread erwähnt das Dusk-Team, dass im Rusk-Upgrade zusätzlich ein „Abwicklungs-Transaktionsprioritäts-Markierung“ eingeführt wird: Mit einer XSC-Contract-Signatur versehene Transaktionen werden übers Nonce-Umsortieren hinweg direkt in den Block übernommen.
Ich habe auf dem Testnet 50 parallele DvP-Simulationen gemacht: Die Nonce-Konflikt-Rate sank von ~12% (strikt monoton) auf ~2% (mit Relaxierung), aber tatsächlich gab es 3 Fälle, in denen die Transaktionen an eine nicht erwartete Position umsortiert wurden. Ob sich dieser Tradeoff auf einer RWA-Kette lohnt, hängt davon ab, wie ihr „Abwicklungs-Bestimmtheit“ definiert: als „finaler Zustand ist korrekt“ oder als „der Ablauf darf nicht umsortiert werden“.
#dusk @Dusk