#dusk $DUSK @Dusk какое-то время я сидел с задачей на перемещении Dusk в OP Stack, перекусывая, и меня не отпускает одна мысль.
Сейчас DuskEVM работает на OP Stack и возвращается к DuskDS вместо того, чтобы оставаться там с классическим 7-дневным оптимистическим окном челленджа, к которому все привыкли. Dusk подаёт это как детерминированную финальность: никакого ожидания неделю, никакого «фрод-пруф» в чистилище. На бумаге звучит чисто.
И вот 16 августа 2026 года происходит кое-что.
Команда Dusk сама замечает подозрительную активность в кошельке, управляемом командой и привязанном к операциям моста. Реакция? Не то, чтобы автоматически включилась on-chain fraud proof. Команда отключила и переработала затронутые адреса моста, вручную приостановила работу сервисов моста и внедрила блоклист для Web Wallet получателей, которые попали под отметку.
Это… команда людей тянет рычаги, а не слой расчетов делает что-то «без доверия».
Хм. Я не критикую — исправили быстро, разумно, ровно так, как хотелось бы. Но это напоминание: отсутствие fault window — это заявление про математику финальности слоя исполнения, а не про то, кто именно вмешивается, когда что-то идёт не так выше по цепочке.
В тот день значимым «страховочным тросом» была команда с правами администратора, а не архитектура OP Stack.
Меня даже остановило по ходу задачи: в заметках я написал, что «нет 7-дневного окна — значит без доверия», а потом зачеркнул.
Где именно детерминированное урегулирование реально снижает зависимость от оперативной команды — вместо того, чтобы просто перенести доверие туда, где оно менее заметно?
Сейчас DuskEVM работает на OP Stack и возвращается к DuskDS вместо того, чтобы оставаться там с классическим 7-дневным оптимистическим окном челленджа, к которому все привыкли. Dusk подаёт это как детерминированную финальность: никакого ожидания неделю, никакого «фрод-пруф» в чистилище. На бумаге звучит чисто.
И вот 16 августа 2026 года происходит кое-что.
Команда Dusk сама замечает подозрительную активность в кошельке, управляемом командой и привязанном к операциям моста. Реакция? Не то, чтобы автоматически включилась on-chain fraud proof. Команда отключила и переработала затронутые адреса моста, вручную приостановила работу сервисов моста и внедрила блоклист для Web Wallet получателей, которые попали под отметку.
Это… команда людей тянет рычаги, а не слой расчетов делает что-то «без доверия».
Хм. Я не критикую — исправили быстро, разумно, ровно так, как хотелось бы. Но это напоминание: отсутствие fault window — это заявление про математику финальности слоя исполнения, а не про то, кто именно вмешивается, когда что-то идёт не так выше по цепочке.
В тот день значимым «страховочным тросом» была команда с правами администратора, а не архитектура OP Stack.
Меня даже остановило по ходу задачи: в заметках я написал, что «нет 7-дневного окна — значит без доверия», а потом зачеркнул.
Где именно детерминированное урегулирование реально снижает зависимость от оперативной команды — вместо того, чтобы просто перенести доверие туда, где оно менее заметно?
