#dusk $DUSK @Dusk
I’ve seen blockchain teams treat networking like plumbing. As long as blocks arrive, the architecture rarely gets much attention.
Kadcast makes me look at that layer differently.
Dusk is not relying on the usual “receive, gossip, repeat” model alone. Kadcast organizes peers through a structured Kademlia-style overlay, so message propagation has some awareness of where nodes sit in the network. That sounds like a small implementation detail, but it changes the problem. Instead of hoping enough random peers spread a message quickly, the protocol is trying to make propagation more deliberate.
The part I find most interesting is how it handles imperfect networks. Kadcast uses UDP, which gives up some delivery guarantees, then adds redundancy and forward error correction to tolerate packet loss. In other words, it is not trying to make the network perfectly reliable. It is designing around the assumption that the network will be messy.
That is a much more useful framing for me.
Traditional gossip gets a lot of its resilience from redundancy. Kadcast appears to push more of that intelligence into peer selection and message routing. The tradeoff is complexity. A structured overlay now has to defend its routing tables, peer discovery and bootstrap process against bad actors and unfavorable topology.
So I’m less interested in raw propagation benchmarks.
The real test is whether Kadcast can keep latency predictable when nodes disappear, packets are dropped, peers behave badly, and the network gets larger.
Fast propagation is useful.
Predictable propagation under stress is what I’d actually want to measure.
I’ve seen blockchain teams treat networking like plumbing. As long as blocks arrive, the architecture rarely gets much attention.
Kadcast makes me look at that layer differently.
Dusk is not relying on the usual “receive, gossip, repeat” model alone. Kadcast organizes peers through a structured Kademlia-style overlay, so message propagation has some awareness of where nodes sit in the network. That sounds like a small implementation detail, but it changes the problem. Instead of hoping enough random peers spread a message quickly, the protocol is trying to make propagation more deliberate.
The part I find most interesting is how it handles imperfect networks. Kadcast uses UDP, which gives up some delivery guarantees, then adds redundancy and forward error correction to tolerate packet loss. In other words, it is not trying to make the network perfectly reliable. It is designing around the assumption that the network will be messy.
That is a much more useful framing for me.
Traditional gossip gets a lot of its resilience from redundancy. Kadcast appears to push more of that intelligence into peer selection and message routing. The tradeoff is complexity. A structured overlay now has to defend its routing tables, peer discovery and bootstrap process against bad actors and unfavorable topology.
So I’m less interested in raw propagation benchmarks.
The real test is whether Kadcast can keep latency predictable when nodes disappear, packets are dropped, peers behave badly, and the network gets larger.
Fast propagation is useful.
Predictable propagation under stress is what I’d actually want to measure.