I went back through the documentation and spent more time than expected on two areas: Kadcast’s fault tolerance and the protocol’s finality rules.
At first, Kadcast’s use of Kademlia’s DHT looked fairly straightforward. Nodes can update their routing tables when peers disappear, while multiple peers in each bucket provide alternative paths when one node fails. But it made me wonder: how quickly can the network adapt when nodes are constantly joining, leaving, or becoming unreliable? And could highly uneven participation create weaker parts of the routing structure?
The consensus state model was even more interesting.
A block of @Dusk can move through accepted, attested, confirmed, and finally final. What helped me understand it was the distinction between an attested block and an accepted one. If previous iterations have failed, a successful block may be accepted but still remain replaceable. The more failed iterations there are, the longer confirmation can take.
For example, with two previous failed iterations, the rules require four consecutive attested or confirmed blocks before an accepted block becomes confirmed.
That raises questions for me around security and decentralization. Does this mechanism provide enough protection against temporary network instability without making finality unnecessarily slow? How does the protocol behave when failures are correlated across many nodes rather than isolated?
I also wonder how routing-table dynamics and consensus finality interact during periods of serious network disruption.
My understanding is still evolving, so I’d be interested in hearing how others interpret these trade-offs.
What failure scenarios do you think Kadcast handles particularly well? And where could its assumptions be tested?
$DUSK #dusk
#dusk $DUSK @Dusk
At first, Kadcast’s use of Kademlia’s DHT looked fairly straightforward. Nodes can update their routing tables when peers disappear, while multiple peers in each bucket provide alternative paths when one node fails. But it made me wonder: how quickly can the network adapt when nodes are constantly joining, leaving, or becoming unreliable? And could highly uneven participation create weaker parts of the routing structure?
The consensus state model was even more interesting.
A block of @Dusk can move through accepted, attested, confirmed, and finally final. What helped me understand it was the distinction between an attested block and an accepted one. If previous iterations have failed, a successful block may be accepted but still remain replaceable. The more failed iterations there are, the longer confirmation can take.
For example, with two previous failed iterations, the rules require four consecutive attested or confirmed blocks before an accepted block becomes confirmed.
That raises questions for me around security and decentralization. Does this mechanism provide enough protection against temporary network instability without making finality unnecessarily slow? How does the protocol behave when failures are correlated across many nodes rather than isolated?
I also wonder how routing-table dynamics and consensus finality interact during periods of serious network disruption.
My understanding is still evolving, so I’d be interested in hearing how others interpret these trade-offs.
What failure scenarios do you think Kadcast handles particularly well? And where could its assumptions be tested?
$DUSK #dusk
#dusk $DUSK @Dusk
