Первое предупреждение пришло из строки под диаграммой жизненного цикла — её легко пропустить.

Разъяснитель от сообщества по DuskEVM прямо заявил: нет 7-дневного окна по ошибке, ~15 минут на финализацию вывода, MIPS pre-verifier устраняет задержку fraud proof (доказательства мошенничества). Чистая цифра — подумал, что можно планировать вывод по ней.

Предположение: официальная документация подтвердит это число.

Но я нашёл не то. Собственная документация Dusk описывает жизненный цикл DuskEVM в четыре шага: транзакция к секвенсору, включение в L2-блок, батчер публикует в DuskDS, затем с помощью state commitments (связанных обязательств по состоянию) и fault proofs (доказательств ошибочности) это состояние соединяется с расчётным урегулированием. Fault proofs названы явно. Нигде нет 15 минут. Вместо этого — строка, говорящая не делать выводы о финальности по истечению времени: вместо этого проверьте статус в протоколе или в кошельке.

Вот реальный разрыв. Включение быстро — в документах говорится об этом прямо. А расчётное урегулирование — отдельная история, зависящая от вещей, на которые никто не поставил таймер.

Так что шаг fault proof не исчез — просто он не задокументирован так, как система permissionless challenge от Optimism, где любой может запустить провайдер и наблюдать за тем, как идёт оспаривание.

Не знаю, это сжато и решается конфиденциально, или просто пока не опубликовано.

Рад, что проверил, прежде чем привязывать время вывода к чужой цифре.

Что будет с тем числом в 15 минут в первый раз, когда fault proof понадобится оспаривать в разгаре rush по расчетному урегулированию? 👍

#dusk $DUSK @Dusk