Die meisten Ketten behandeln Replay-Schutz als ein Nonce-Problem. Für Wertpapier-Settlement ist das aber nur die halbe Geschichte.
Ein Doppelklick oder ein wenig Netzwerk-Jitter kann dieselbe Anweisung zweimal auslösen. Krypto-Nonces stoppen reines Replay, aber die Business-Schicht kann sie dennoch zweimal ausführen – mit derselben Instruktionsnummer, demselben Settlement-Datum, demselben Kontenpaar – und so enden Phantom-Wertpapiere oder „Cash Legs“. Teilweiser Erfolg ist besonders tückisch: Die erste „Leg“ zieht ab, der Status hängt in „pending“, und die zweite „Leg“ zieht erneut ab. Die Reconcilers sehen doppelte Positionen und beginnen, Angriffsszenarien zu konstruieren. Vertrauliche Transaktionen machen das noch schlimmer, weil man die beiden Klartexte nicht einfach nebeneinanderlegen kann. Der einzige belastbare Unterschied ist ein dauerhaftes Business-Identifier – nicht „die Beträge sehen gleich aus“.
Sobald die Finalität den Zustand fest einrastet, wird das Aufräumen teuer. Besser ist es, bei einem Konflikt der Identifier hart zu fehlschlagen, als die Anweisung zweimal auszuführen. Auch der Scope ist wichtig: „dasselbe Konto/derselbe Tag“ ist zu eng; ein Lifetime-Key für diese Instruktion verhindert das Replay, wenn sich das Settlement-Datum verschiebt.
Dusk’ deterministische Finalität und Privacy-Primitiven sind für regulierte Kanäle gebaut. Während sich DuskEVM-Testnet und die vertraulichen Settlement-Muster weiterentwickeln, wird der entscheidende Vorteil bei Systemen liegen, die den Business-Idempotenz-Key als zweiten, nicht verhandelbaren Lock behandeln – nicht als nachträglichen Gedanken. Ohne ihn wandern Doppelklicks nur von den Backend-Logs auf die Chain und werden dauerhaft.
$DUSK #dusk @Dusk $AKE $BEAT
Ein Doppelklick oder ein wenig Netzwerk-Jitter kann dieselbe Anweisung zweimal auslösen. Krypto-Nonces stoppen reines Replay, aber die Business-Schicht kann sie dennoch zweimal ausführen – mit derselben Instruktionsnummer, demselben Settlement-Datum, demselben Kontenpaar – und so enden Phantom-Wertpapiere oder „Cash Legs“. Teilweiser Erfolg ist besonders tückisch: Die erste „Leg“ zieht ab, der Status hängt in „pending“, und die zweite „Leg“ zieht erneut ab. Die Reconcilers sehen doppelte Positionen und beginnen, Angriffsszenarien zu konstruieren. Vertrauliche Transaktionen machen das noch schlimmer, weil man die beiden Klartexte nicht einfach nebeneinanderlegen kann. Der einzige belastbare Unterschied ist ein dauerhaftes Business-Identifier – nicht „die Beträge sehen gleich aus“.
Sobald die Finalität den Zustand fest einrastet, wird das Aufräumen teuer. Besser ist es, bei einem Konflikt der Identifier hart zu fehlschlagen, als die Anweisung zweimal auszuführen. Auch der Scope ist wichtig: „dasselbe Konto/derselbe Tag“ ist zu eng; ein Lifetime-Key für diese Instruktion verhindert das Replay, wenn sich das Settlement-Datum verschiebt.
Dusk’ deterministische Finalität und Privacy-Primitiven sind für regulierte Kanäle gebaut. Während sich DuskEVM-Testnet und die vertraulichen Settlement-Muster weiterentwickeln, wird der entscheidende Vorteil bei Systemen liegen, die den Business-Idempotenz-Key als zweiten, nicht verhandelbaren Lock behandeln – nicht als nachträglichen Gedanken. Ohne ihn wandern Doppelklicks nur von den Backend-Logs auf die Chain und werden dauerhaft.
$DUSK #dusk @Dusk $AKE $BEAT