After Maghreb I started digging through Dusk consensus notes and kept coming back to the quiet statistical gap that keeps sitting there. @Dusk
The Succinct Attestation design aims for deterministic finality. Once a block is ratified it is treated as final under normal conditions, and the protocol says there should be no user-facing reorgs in ordinary operation.
Forks can still appear when delays or congestion let more than one iteration reach consensus in the same round. The official rule is simple: always keep the block from the lowest iteration and discard the others. There is also rolling finality — a block starts as accepted, can still be replaced while it is only attested, and becomes immutable only after later blocks confirm it.
The statistical point is the one that stuck. Seeing 3 forks in 1,000 trials looks the same as 300 forks in 100,000 trials if you only look at the raw rate. Without standard error and 95% confidence intervals you cannot tell whether the estimate is stable or just noise. Proper testing needs large sample sizes like the suggested 100,000 random validator-delay profiles and multiple latency patterns, not one friendly network model.
Official docs describe the fork rules and claim low-latency finality. They do not publish large-scale results with confidence intervals under skewed or unfriendly delays.
That statistical gap was harder to ignore then I expected. A low observed fork rate is useful. Knowing how uncertain that rate is when the network gets messy is what actually builds trust. Still chewing on whether that statistical layer will show up in the public materials.
#dusk $DUSK
The Succinct Attestation design aims for deterministic finality. Once a block is ratified it is treated as final under normal conditions, and the protocol says there should be no user-facing reorgs in ordinary operation.
Forks can still appear when delays or congestion let more than one iteration reach consensus in the same round. The official rule is simple: always keep the block from the lowest iteration and discard the others. There is also rolling finality — a block starts as accepted, can still be replaced while it is only attested, and becomes immutable only after later blocks confirm it.
The statistical point is the one that stuck. Seeing 3 forks in 1,000 trials looks the same as 300 forks in 100,000 trials if you only look at the raw rate. Without standard error and 95% confidence intervals you cannot tell whether the estimate is stable or just noise. Proper testing needs large sample sizes like the suggested 100,000 random validator-delay profiles and multiple latency patterns, not one friendly network model.
Official docs describe the fork rules and claim low-latency finality. They do not publish large-scale results with confidence intervals under skewed or unfriendly delays.
That statistical gap was harder to ignore then I expected. A low observed fork rate is useful. Knowing how uncertain that rate is when the network gets messy is what actually builds trust. Still chewing on whether that statistical layer will show up in the public materials.
#dusk $DUSK