#dusk $DUSK @Dusk
Die Juni-2025-Ankündigung des Dusk-Netzwerks sagte, dass DuskEVM (OP-Stack-basiert) das übliche 7-Tage-Fehlerfenster überspringt, weil DuskDS einen mit MIPS betriebenen Pre-Verifier ausführt, der Zustandsübergänge prüft, bevor sie die Kette erreichen. Das ist ihr eigener Blogbeitrag, verknüpft mit $DUSK , #dusk, @Dusk.
Die aktuelle Live-Dokumentationsseite für DuskEVM auf docs.dusk.network wiederholt das nicht. Dort wird stattdessen ein standardmäßiger Rollup-Lifecycle beschrieben – Sequencer, Batcher und dann „State Commitments und Fraud Proofs“, die die Ausführung zurück zu Dusk DS verknüpfen – und es wird ausdrücklich gewarnt: Leite keine Finalität aus der verstrichenen Zeit ab; nutze Protokoll- oder Wallet-Status. Diese Vorsicht erwartet man von einer Kette, die noch ein Challenge-Fenster hat, nicht von einer, bei der man es entfernt hat.
Ich habe versucht zu prüfen, ob die Seite der Dokumentation vor der Ankündigung liegt – was erklären würde, dass es sich um veraltete Doku handelt und nicht um einen direkten Widerspruch zur Live-Information. Ich konnte dafür aber keinen Zeitstempel auf dieser konkreten Seite finden – die Doku-Seite wird aus einem aktiv gepflegten GitHub-Repo generiert, aber ich konnte die Commit-Historie nicht abrufen. Daher ist das, was ich tatsächlich habe, enger gefasst als „Dusk widerspricht sich selbst“: Es sind zwei offizielle Quellen, die unterschiedliche Finalitätsmodelle beschreiben, und ich kann derzeit nicht sagen, welches davon heute für DuskEVM gilt.
Als Nächstes würde ich prüfen: die Commit-Historie des Doku-Repos für die DuskEVM-Seite oder den Bridge-Contract selbst, um zu sehen, ob eine Challenge-Periode on-chain durchgesetzt wird.
Die Juni-2025-Ankündigung des Dusk-Netzwerks sagte, dass DuskEVM (OP-Stack-basiert) das übliche 7-Tage-Fehlerfenster überspringt, weil DuskDS einen mit MIPS betriebenen Pre-Verifier ausführt, der Zustandsübergänge prüft, bevor sie die Kette erreichen. Das ist ihr eigener Blogbeitrag, verknüpft mit $DUSK , #dusk, @Dusk.
Die aktuelle Live-Dokumentationsseite für DuskEVM auf docs.dusk.network wiederholt das nicht. Dort wird stattdessen ein standardmäßiger Rollup-Lifecycle beschrieben – Sequencer, Batcher und dann „State Commitments und Fraud Proofs“, die die Ausführung zurück zu Dusk DS verknüpfen – und es wird ausdrücklich gewarnt: Leite keine Finalität aus der verstrichenen Zeit ab; nutze Protokoll- oder Wallet-Status. Diese Vorsicht erwartet man von einer Kette, die noch ein Challenge-Fenster hat, nicht von einer, bei der man es entfernt hat.
Ich habe versucht zu prüfen, ob die Seite der Dokumentation vor der Ankündigung liegt – was erklären würde, dass es sich um veraltete Doku handelt und nicht um einen direkten Widerspruch zur Live-Information. Ich konnte dafür aber keinen Zeitstempel auf dieser konkreten Seite finden – die Doku-Seite wird aus einem aktiv gepflegten GitHub-Repo generiert, aber ich konnte die Commit-Historie nicht abrufen. Daher ist das, was ich tatsächlich habe, enger gefasst als „Dusk widerspricht sich selbst“: Es sind zwei offizielle Quellen, die unterschiedliche Finalitätsmodelle beschreiben, und ich kann derzeit nicht sagen, welches davon heute für DuskEVM gilt.
Als Nächstes würde ich prüfen: die Commit-Historie des Doku-Repos für die DuskEVM-Seite oder den Bridge-Contract selbst, um zu sehen, ob eine Challenge-Periode on-chain durchgesetzt wird.
