#dusk $DUSK @Dusk
In ihrer Ankündigung im Juni 2025 erklärte Dusk Network, dass DuskEVM (auf OP Stack basierend) das übliche 7-Tage-Fehlerfenster überspringt. Grund dafür sei, dass DuskDS einen MIPS-basierten Pre-Verifier betreibt, der Zustandsübergänge prüft, bevor sie die Chain erreichen. Das sei ihr eigener Blogbeitrag, verbunden 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-Lebenszyklus beschrieben — Sequencer, Batcher und dann „State Commitments und Fault Proofs“, die die Ausführung zurück zu Dusk DS verknüpfen. Außerdem gibt es eine ausdrückliche Warnung: Leite keine Finalität aus der verstrichenen Zeit ab; nutze Protokoll- oder Wallet-Status. Diese Vorsicht würde man von einer Chain erwarten, die noch ein Challenge-Fenster hat — nicht von einer, die es entfernt hat.
Ich habe versucht zu prüfen, ob die Dokumentationsseite vor der Ankündigung entstanden ist. Dann ließe sich das als veraltete Doku statt als laufender Widerspruch erklären. Einen Zeitstempel für genau diese Seite konnte ich jedoch nicht finden — die Doku-Website wird aus einem aktiv gepflegten GitHub-Repository generiert, aber ich konnte den Commit-Verlauf nicht abrufen. Daher habe ich tatsächlich nur etwas Schmaleres als „Dusk widerspricht sich selbst“: Es sind zwei offizielle Quellen, die unterschiedliche Finality-Modelle beschreiben, und ich kann aktuell nicht feststellen, welches davon heute für DuskEVM gilt.
Als Nächstes würde ich prüfen: den Commit-Verlauf des Doku-Repositories für die DuskEVM-Seite oder den Bridge-Contract selbst, um zu sehen, ob auf der Chain ein Challenge-Zeitraum on-chain erzwungen wird.
In ihrer Ankündigung im Juni 2025 erklärte Dusk Network, dass DuskEVM (auf OP Stack basierend) das übliche 7-Tage-Fehlerfenster überspringt. Grund dafür sei, dass DuskDS einen MIPS-basierten Pre-Verifier betreibt, der Zustandsübergänge prüft, bevor sie die Chain erreichen. Das sei ihr eigener Blogbeitrag, verbunden 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-Lebenszyklus beschrieben — Sequencer, Batcher und dann „State Commitments und Fault Proofs“, die die Ausführung zurück zu Dusk DS verknüpfen. Außerdem gibt es eine ausdrückliche Warnung: Leite keine Finalität aus der verstrichenen Zeit ab; nutze Protokoll- oder Wallet-Status. Diese Vorsicht würde man von einer Chain erwarten, die noch ein Challenge-Fenster hat — nicht von einer, die es entfernt hat.
Ich habe versucht zu prüfen, ob die Dokumentationsseite vor der Ankündigung entstanden ist. Dann ließe sich das als veraltete Doku statt als laufender Widerspruch erklären. Einen Zeitstempel für genau diese Seite konnte ich jedoch nicht finden — die Doku-Website wird aus einem aktiv gepflegten GitHub-Repository generiert, aber ich konnte den Commit-Verlauf nicht abrufen. Daher habe ich tatsächlich nur etwas Schmaleres als „Dusk widerspricht sich selbst“: Es sind zwei offizielle Quellen, die unterschiedliche Finality-Modelle beschreiben, und ich kann aktuell nicht feststellen, welches davon heute für DuskEVM gilt.
Als Nächstes würde ich prüfen: den Commit-Verlauf des Doku-Repositories für die DuskEVM-Seite oder den Bridge-Contract selbst, um zu sehen, ob auf der Chain ein Challenge-Zeitraum on-chain erzwungen wird.