#dusk $DUSK @Dusk 平atform downtime for ten minutes—I can still wait. But if, after it’s restored, we also need to re-confirm whether the “original positions can still be accounted for,” then that’s already beyond the scope of a normal outage. Funds will definitely think twice.
I think DuskEVM’s H2 rehearsal revealed this dividing line.
The Sequencer responsible for ordering trades and packaging them was offline for too long, and it also lost the segment of records that hadn’t yet been finalized. When the system restored, it set an “expiry period” for the first batch of data it would backfill. Originally, that meant 3,600 Dusk layer-1 blocks. If the returned data comes back after that line, it may already be expired, and the recovery plan could be upgraded to resetting the L2 starting point or redeploying.
However, later the official widened the rehearsal window to 4,000 blocks—adding 400 more. I understand the purpose: to make sure the recovery data lands in time, so the original contracts, balances, and transaction history can continue to be used.
At first, I really took it as a minor parameter tweak. Then I plugged in the future real positions, and my stomach sank: the shutdown cost will not increase smoothly and steadily forever.
Because while the window hasn’t passed, trades are just paused. Once you cross the line, everything needs to be re-confirmed—whether the liquidity pool’s funds, the robots’ inventory, and users’ positions can still be used. I feel that even that extra short period could make the failure suddenly jump to a different severity.
So I won’t just look at the “monthly uptime rate.” How many blocks/time are left before the window expires, whether the first batch of data after recovery can be accepted, and whether the post-recovery history is the same—these indicators are much closer to real capital risk, and they’re more relevant to my trading.
My take on $DUSK : during downtime, losing a few Gas transactions is a small account. The bigger losses may come from capital not daring to stay for the long term, robots relocating their standby inventory elsewhere, and users reducing cross-layer back-and-forth. I think for DuskEVM to build sustained Gas demand, it first needs to prove that after a failure, the original market can be seamlessly taken back on the spot.
Those extra 400 blocks buy market continuity. But after service restoration, it’s the fact that the original books can still be carried over—that’s the trading experience I’m after.
$BTC
I think DuskEVM’s H2 rehearsal revealed this dividing line.
The Sequencer responsible for ordering trades and packaging them was offline for too long, and it also lost the segment of records that hadn’t yet been finalized. When the system restored, it set an “expiry period” for the first batch of data it would backfill. Originally, that meant 3,600 Dusk layer-1 blocks. If the returned data comes back after that line, it may already be expired, and the recovery plan could be upgraded to resetting the L2 starting point or redeploying.
However, later the official widened the rehearsal window to 4,000 blocks—adding 400 more. I understand the purpose: to make sure the recovery data lands in time, so the original contracts, balances, and transaction history can continue to be used.
At first, I really took it as a minor parameter tweak. Then I plugged in the future real positions, and my stomach sank: the shutdown cost will not increase smoothly and steadily forever.
Because while the window hasn’t passed, trades are just paused. Once you cross the line, everything needs to be re-confirmed—whether the liquidity pool’s funds, the robots’ inventory, and users’ positions can still be used. I feel that even that extra short period could make the failure suddenly jump to a different severity.
So I won’t just look at the “monthly uptime rate.” How many blocks/time are left before the window expires, whether the first batch of data after recovery can be accepted, and whether the post-recovery history is the same—these indicators are much closer to real capital risk, and they’re more relevant to my trading.
My take on $DUSK : during downtime, losing a few Gas transactions is a small account. The bigger losses may come from capital not daring to stay for the long term, robots relocating their standby inventory elsewhere, and users reducing cross-layer back-and-forth. I think for DuskEVM to build sustained Gas demand, it first needs to prove that after a failure, the original market can be seamlessly taken back on the spot.
Those extra 400 blocks buy market continuity. But after service restoration, it’s the fact that the original books can still be carried over—that’s the trading experience I’m after.
$BTC