$DUSK #Dämmerung — DuskEVM überspringt das klassische 7-Tage-Challenge-Fenster von Optimism. Diese Verzögerung war nicht einfach ein UX-Fehler; sie ist Teil des Sicherheitsmodells.
Wenn man in den Bericht von @DuskFoundation zur OP-Stack-Portierung eintaucht, dann setzt sich DuskEVM zu DuskDS, während ein MIPS-basierter Pre-Verifier Zustandsübergänge prüft, bevor sie für das Settlement akzeptiert werden. In Dunks Dokumentation heißt es, dass Withdrawals ungefähr in 15 Minuten finalisieren.
Zunächst wirkt das wie ein unkompliziertes UX-Upgrade. Aber die Sicherheitsfrage ist spannender.
Im Standard-OP-Stack bietet das 7-Tage-Fenster Zeit für permissionless Fraud Proofs, um einen ungültigen State Root herauszufordern. Dusk verlagert die Verifikation stattdessen früher in den Ablauf.
Daher würde ich das nicht einfach als „Entfernen der Vertrauensanforderung“ beschreiben. Entscheidend ist die Frage, wo jetzt die Sicherheitsannahme verankert ist: Wird die Pre-Verifikation unabhängig durch den DuskDS-Validator-Set erzwungen, oder hängt sie von einem separaten Verifier-Set ab?
Diese Unterscheidung ist wichtig. Schnellere Finalität ist wertvoll, aber nur dann, wenn wir verstehen, was darunter verändert wurde.
Als Nächstes prüfe ich das Rusk-GitHub sowie Dunks technische Doku, um herauszufinden, wie das Pre-Verifier-Set mit den DuskDS-Validatoren zusammenhängt.
#dusk $DUSK @Dusk
Wenn man in den Bericht von @DuskFoundation zur OP-Stack-Portierung eintaucht, dann setzt sich DuskEVM zu DuskDS, während ein MIPS-basierter Pre-Verifier Zustandsübergänge prüft, bevor sie für das Settlement akzeptiert werden. In Dunks Dokumentation heißt es, dass Withdrawals ungefähr in 15 Minuten finalisieren.
Zunächst wirkt das wie ein unkompliziertes UX-Upgrade. Aber die Sicherheitsfrage ist spannender.
Im Standard-OP-Stack bietet das 7-Tage-Fenster Zeit für permissionless Fraud Proofs, um einen ungültigen State Root herauszufordern. Dusk verlagert die Verifikation stattdessen früher in den Ablauf.
Daher würde ich das nicht einfach als „Entfernen der Vertrauensanforderung“ beschreiben. Entscheidend ist die Frage, wo jetzt die Sicherheitsannahme verankert ist: Wird die Pre-Verifikation unabhängig durch den DuskDS-Validator-Set erzwungen, oder hängt sie von einem separaten Verifier-Set ab?
Diese Unterscheidung ist wichtig. Schnellere Finalität ist wertvoll, aber nur dann, wenn wir verstehen, was darunter verändert wurde.
Als Nächstes prüfe ich das Rusk-GitHub sowie Dunks technische Doku, um herauszufinden, wie das Pre-Verifier-Set mit den DuskDS-Validatoren zusammenhängt.
#dusk $DUSK @Dusk
