When it comes to blockchain performance, out of ten people, nine immediately think of TPS. The remaining one might look at latency instead. But with the Dusk project, once you pull up its whitepaper and go through it carefully, you’ll find something more worth watching than transaction speed: how nodes “talk” to each other.
That’s all well and good for the big pie—BTC dropped not that much!
I’m not saying TPS doesn’t matter, but “faster computation” and “faster transmission” are completely different things. No matter how powerful your execution layer is or how clever your consensus design is, if messages get stuck in the node network—proposals can’t reach validators, and validation results can’t make it back to the ratification committee—then the whole three-phase process just has to wait. If blocks arrive a few seconds late, the experience suffers a bit; if it’s worse, different nodes may even see different candidate blocks, and the stale block rate climbs right up.
Dusk chose the Kadcast approach. It’s not the gossip-style broadcast where everything just gets forwarded to everyone. Instead, it builds a structured overlay on top of the Kademlia DHT: the XOR distance between node IDs determines routing, and messages unfold step by step like a tree. Sounds academic, right? But the core logic can be summed up in one sentence: every message takes only the route it should take—no detours.
The whitepaper cites research showing that Kadcast can save 25% to 50% of bandwidth compared to Gossip. For example, if it used to consume 100 units of bandwidth, it’s now roughly 50 to 75. But those numbers can’t be directly translated into “node costs cut in half.” Machine specs don’t change, proof computation doesn’t change, storage overhead doesn’t change—the only thing that changes is the transmission cost in the network layer. Still, for people running nodes, what does “half the bandwidth” really mean? It means you can connect more nodes under the same bandwidth conditions, or that with the same network size, you’re less likely to get throttled by bandwidth fees.
There’s a detail that really illustrates the point. In the node documentation, 9000/udp is marked as a required port for Kadcast. If the Provisioner wants to participate in consensus, it must be able to reach that channel. In contrast, 8080/tcp is optional—it’s only needed if you require the query interface. In other words, Kadcast isn’t a decorative item on an architecture diagram—it directly sets the threshold for whether a node can participate in consensus.
Anyone familiar with BTC’s peer-to-peer broadcasting knows that how messages travel through the node network has never been a small matter. @Dusk $DUSK #dusk
That’s all well and good for the big pie—BTC dropped not that much!
I’m not saying TPS doesn’t matter, but “faster computation” and “faster transmission” are completely different things. No matter how powerful your execution layer is or how clever your consensus design is, if messages get stuck in the node network—proposals can’t reach validators, and validation results can’t make it back to the ratification committee—then the whole three-phase process just has to wait. If blocks arrive a few seconds late, the experience suffers a bit; if it’s worse, different nodes may even see different candidate blocks, and the stale block rate climbs right up.
Dusk chose the Kadcast approach. It’s not the gossip-style broadcast where everything just gets forwarded to everyone. Instead, it builds a structured overlay on top of the Kademlia DHT: the XOR distance between node IDs determines routing, and messages unfold step by step like a tree. Sounds academic, right? But the core logic can be summed up in one sentence: every message takes only the route it should take—no detours.
The whitepaper cites research showing that Kadcast can save 25% to 50% of bandwidth compared to Gossip. For example, if it used to consume 100 units of bandwidth, it’s now roughly 50 to 75. But those numbers can’t be directly translated into “node costs cut in half.” Machine specs don’t change, proof computation doesn’t change, storage overhead doesn’t change—the only thing that changes is the transmission cost in the network layer. Still, for people running nodes, what does “half the bandwidth” really mean? It means you can connect more nodes under the same bandwidth conditions, or that with the same network size, you’re less likely to get throttled by bandwidth fees.
There’s a detail that really illustrates the point. In the node documentation, 9000/udp is marked as a required port for Kadcast. If the Provisioner wants to participate in consensus, it must be able to reach that channel. In contrast, 8080/tcp is optional—it’s only needed if you require the query interface. In other words, Kadcast isn’t a decorative item on an architecture diagram—it directly sets the threshold for whether a node can participate in consensus.
Anyone familiar with BTC’s peer-to-peer broadcasting knows that how messages travel through the node network has never been a small matter. @Dusk $DUSK #dusk