Helping my son with his homework until 11 o'clock. He said, “What happens if the computer crashes?” and it really caught me off guard.
I instinctively wanted to reply, “Just reboot,” but then I suddenly remembered a section from the Dusk whitepaper I’d been digging into these past few days—where they call this an “emergency mode.”
Under normal circumstances, producing a block follows a three-step process: proposal, verification, and approval. If 2/3 of people vote “yes,” it goes through. But if most nodes go offline or get stuck, and there are 16 consecutive failures, the system automatically switches to emergency mode. The timeout mechanism then gets turned off, and it keeps running until a real block is produced.
In plain terms, it’s not a “crash-reboot” situation. It’s switching to a different method and forcing it through to the end.
Most people don’t pay attention to this kind of thing in everyday life—whether the chain runs smoothly or how strict the consensus mechanism is, nobody really cares. But financial scenarios are different. Institutions want to ensure, “It can’t stop even in extreme cases,” which matters far more than TPS.
Even the block rewards are designed with a lot of detail: 80% to the block producer, 10% to the voters, and 10% to the protocol itself. This is specifically meant to prevent someone from deliberately trying to make the first few rounds fail in order to steal the rewards.
I usually don’t write about this kind of detail, but the deeper I dig, the more I feel that whether a project is willing to clearly explain what it will do in the worst case is more valuable than how pretty its marketing page looks. Right now, DuskEVM is still on the testnet. The consensus mechanism’s ability to withstand extreme market conditions hasn’t yet been validated at large scale.
Whether it will succeed—I don’t know. But for a project that dares to lay out its contingency plan in plain sight, I’m willing to take a closer look.
@Dusk $DUSK
#dusk
I instinctively wanted to reply, “Just reboot,” but then I suddenly remembered a section from the Dusk whitepaper I’d been digging into these past few days—where they call this an “emergency mode.”
Under normal circumstances, producing a block follows a three-step process: proposal, verification, and approval. If 2/3 of people vote “yes,” it goes through. But if most nodes go offline or get stuck, and there are 16 consecutive failures, the system automatically switches to emergency mode. The timeout mechanism then gets turned off, and it keeps running until a real block is produced.
In plain terms, it’s not a “crash-reboot” situation. It’s switching to a different method and forcing it through to the end.
Most people don’t pay attention to this kind of thing in everyday life—whether the chain runs smoothly or how strict the consensus mechanism is, nobody really cares. But financial scenarios are different. Institutions want to ensure, “It can’t stop even in extreme cases,” which matters far more than TPS.
Even the block rewards are designed with a lot of detail: 80% to the block producer, 10% to the voters, and 10% to the protocol itself. This is specifically meant to prevent someone from deliberately trying to make the first few rounds fail in order to steal the rewards.
I usually don’t write about this kind of detail, but the deeper I dig, the more I feel that whether a project is willing to clearly explain what it will do in the worst case is more valuable than how pretty its marketing page looks. Right now, DuskEVM is still on the testnet. The consensus mechanism’s ability to withstand extreme market conditions hasn’t yet been validated at large scale.
Whether it will succeed—I don’t know. But for a project that dares to lay out its contingency plan in plain sight, I’m willing to take a closer look.
@Dusk $DUSK
#dusk