Dusk pulled me down a different rabbit hole tonight not privacy this time, just how blocks physically get from one node to every other node without the network choking on itself.
most blockchains still use gossip protocols:
a node hears about a block, forwards it to random peers, those peers forward it again, and the same data gets retransmitted constantly across redundant paths. Dusk replaced that with Kadcast, built on Kademlia-style XOR-distance routing. Every node gets a binary ID, and distance between any two nodes is just the XOR of their IDs, which sorts peers into structured "k-buckets" instead of random connections. When a block needs broadcasting, it doesn't flood the network, it propagates along deterministic paths based on that distance metric. Cited research behind the design shows roughly 25-50% less bandwidth used versus gossip, and it apparently cuts stale/orphaned block rates by 10-30% in fast-block conditions.
Here's what actually got me: Kadcast even salts the distance metric per broadcast, using a hash derived from the block or transaction data itself, so node positions get pseudo-randomized on every single propagation round. That's specifically there to stop an attacker from predicting routing paths and positioning themselves to intercept or delay specific messages — an Eclipse-attack defense baked directly into the network layer, not bolted on as a firewall rule somewhere.
@Dusk needed this because Succinct Attestation depends on committees exchanging votes fast and reliably — a slow, congested network layer would quietly undermine the fast finality the consensus promises on paper. $DUSK -secured validators are only as fast as the messages reaching them. Neat solution to a problem most chains never even name. Does structured routing like this hold up as validator count actually scales into the thousands, or does k-bucket maintenance become its own bottleneck eventually?
#dusk $DUSK @Dusk
most blockchains still use gossip protocols:
a node hears about a block, forwards it to random peers, those peers forward it again, and the same data gets retransmitted constantly across redundant paths. Dusk replaced that with Kadcast, built on Kademlia-style XOR-distance routing. Every node gets a binary ID, and distance between any two nodes is just the XOR of their IDs, which sorts peers into structured "k-buckets" instead of random connections. When a block needs broadcasting, it doesn't flood the network, it propagates along deterministic paths based on that distance metric. Cited research behind the design shows roughly 25-50% less bandwidth used versus gossip, and it apparently cuts stale/orphaned block rates by 10-30% in fast-block conditions.
Here's what actually got me: Kadcast even salts the distance metric per broadcast, using a hash derived from the block or transaction data itself, so node positions get pseudo-randomized on every single propagation round. That's specifically there to stop an attacker from predicting routing paths and positioning themselves to intercept or delay specific messages — an Eclipse-attack defense baked directly into the network layer, not bolted on as a firewall rule somewhere.
@Dusk needed this because Succinct Attestation depends on committees exchanging votes fast and reliably — a slow, congested network layer would quietly undermine the fast finality the consensus promises on paper. $DUSK -secured validators are only as fast as the messages reaching them. Neat solution to a problem most chains never even name. Does structured routing like this hold up as validator count actually scales into the thousands, or does k-bucket maintenance become its own bottleneck eventually?
#dusk $DUSK @Dusk
