Two vendors in Karachi's Saddar market once both claimed they sold me the same phone case first, and the shopkeeper just went with whoever grabbed the receipt book first. I figured Dusk handles competing blocks the same crude way, whichever one the network sees first wins.
That's backwards from how fallback actually works. When two candidate blocks both reach consensus in the same round, which can happen from delayed or lost messages during network congestion, Dusk doesn't favor whichever arrived first. It favors whichever reached consensus at the lowest iteration number. A block at iteration 5 can get replaced by one at iteration 2 if that lower iteration block also achieves quorum. The fallback procedure reverts the local chain to right before the higher iteration block, accepts the lower iteration one instead, and discards every successor that was built on top of the discarded block.
What actually shifted my thinking is the iteration 0 exception. A block that reaches consensus at iteration 0 can never be replaced by a lower iteration block, since there isn't one. It can still get reverted later, but only if something upstream of it, one of its ancestors, gets reverted first. So finality on Dusk isn't really about a single block's status, it's inherited from everything sitting underneath it.
What the whitepaper doesn't quantify is how often forks like this actually happen once the network is under real congestion at scale, not just in theory.
Anyone seen a real fallback event happen on a Dusk block yet?
#dusk $DUSK @Dusk
That's backwards from how fallback actually works. When two candidate blocks both reach consensus in the same round, which can happen from delayed or lost messages during network congestion, Dusk doesn't favor whichever arrived first. It favors whichever reached consensus at the lowest iteration number. A block at iteration 5 can get replaced by one at iteration 2 if that lower iteration block also achieves quorum. The fallback procedure reverts the local chain to right before the higher iteration block, accepts the lower iteration one instead, and discards every successor that was built on top of the discarded block.
What actually shifted my thinking is the iteration 0 exception. A block that reaches consensus at iteration 0 can never be replaced by a lower iteration block, since there isn't one. It can still get reverted later, but only if something upstream of it, one of its ancestors, gets reverted first. So finality on Dusk isn't really about a single block's status, it's inherited from everything sitting underneath it.
What the whitepaper doesn't quantify is how often forks like this actually happen once the network is under real congestion at scale, not just in theory.
Anyone seen a real fallback event happen on a Dusk block yet?
#dusk $DUSK @Dusk
