$DUSK #暮色 — DuskEVM 跳過 Optimism 經典的 7 天挑戰窗口。那種延遲並非單純的體驗缺陷；它是安全模型的一部分。
在深入查看 @DuskFoundation 關於將 OP Stack 遷移的說明後，DuskEVM 收斂到 DuskDS，而基於 MIPS 的預驗證器會在狀態轉移被接受用於結算之前檢查它們。Dusk 的文檔描述，提款大約在 15 分鐘內完成最終確認。
起初，這看起來像是一個直接的體驗升級。但安全問題更值得關注。
在標準的 OP Stack 中，7 天窗口爲無需許可（permissionless）的欺詐證明提供時間，以挑戰無效的狀態根。Dusk 的設計則把驗證提前到了流程更早的位置。
所以我不會把這簡單描述爲“移除了信任要求”。更關鍵的問題是：安全假設現在落在了哪裏——是由 DuskDS 的驗證者集合獨立強制執行預驗證，還是依賴於一個獨立的驗證者集合？
這種區別很重要。更快的最終性固然有價值，但前提是我們理解在其背後到底發生了什麼變化。
接下來我會查看 Rusk 的 GitHub 以及 Dusk 的技術文檔，看看預驗證者集合如何與 DuskDS 驗證者關聯。
#dusk $DUSK @Dusk
在深入查看 @DuskFoundation 關於將 OP Stack 遷移的說明後，DuskEVM 收斂到 DuskDS，而基於 MIPS 的預驗證器會在狀態轉移被接受用於結算之前檢查它們。Dusk 的文檔描述，提款大約在 15 分鐘內完成最終確認。
起初，這看起來像是一個直接的體驗升級。但安全問題更值得關注。
在標準的 OP Stack 中，7 天窗口爲無需許可（permissionless）的欺詐證明提供時間，以挑戰無效的狀態根。Dusk 的設計則把驗證提前到了流程更早的位置。
所以我不會把這簡單描述爲“移除了信任要求”。更關鍵的問題是：安全假設現在落在了哪裏——是由 DuskDS 的驗證者集合獨立強制執行預驗證，還是依賴於一個獨立的驗證者集合？
這種區別很重要。更快的最終性固然有價值，但前提是我們理解在其背後到底發生了什麼變化。
接下來我會查看 Rusk 的 GitHub 以及 Dusk 的技術文檔，看看預驗證者集合如何與 DuskDS 驗證者關聯。
#dusk $DUSK @Dusk
