To be honest, when I first started running the Dusk nodes, I didn’t really take the network layer that seriously. As long as consensus could run through, blocks could be produced, and rewards could be received, who would have the time to keep staring at the UDP packets bouncing back and forth on a port? Until one time, the team in the server room got back to me and said that the node’s outbound traffic was higher than expected—after looking into it, it turned out it wasn’t that RPC was being scraped, but rather that the Gossip broadcast mechanism started to “talk nonsense” once the scale went up. One message gets shouted in a group, then everyone forwards it once more—there’s an N-squared effect. Anyone familiar with P2P knows what I mean.
The big plan dipped a bit, but BTC is still building up its power!
When the Dusk docs bring Kadcast into the picture, I actually looked at it with a picky mindset. The phrase “structured overlay network” basically means you draw a map for the messages and then send them instead of randomly stumbling around. The official claim of a 25% to 50% bandwidth reduction sounded good, so I ran a rough comparison using my own nodes over two weeks—turning off the Kadcast optimization switch (the testnet has this option) versus keeping it on. Compared to the enabled state, the outbound traffic can indeed be reduced by close to 40%. But let me make this clear: this is purely a network-layer metric. Don’t equate it with “getting a 60% discount on node costs.” The money for the machines, storage, and the hardware expenses for the Prover—none of that is spared.
What truly made me feel this is worth highlighting is the little detail about port configuration. In the node guide, 9000/udp is marked as required, while 8080/tcp is optional. That signal is too direct: in Dusk’s architecture, Kadcast isn’t just a nice-to-have—it’s the lifeline of communication. When a proposal needs to be transmitted, validation votes have to fly, and approved-phase results need to be consolidated, if any step stalls due to network congestion, the consensus experience falls apart immediately. You can make block production as fast as you want, but if messages can’t get through, it’s effectively zero.
People who’ve run nodes in ETH’s ecosystem all have a similar feeling: once you get into the thousands of nodes on the testnet, the synchronization delay starts to drift. Dusk separates propagation efficiency and treats it as a standalone optimization layer—so the direction is right. But what matters long term is whether, after the node count doubles and doubles again, Kadcast’s “map” can still maintain a low redundancy rate and stable latency. This has nothing to do with TPS, and nothing to do with security thresholds. It’s simply homework for the communication layer itself.
@Dusk $DUSK #dusk
The big plan dipped a bit, but BTC is still building up its power!
When the Dusk docs bring Kadcast into the picture, I actually looked at it with a picky mindset. The phrase “structured overlay network” basically means you draw a map for the messages and then send them instead of randomly stumbling around. The official claim of a 25% to 50% bandwidth reduction sounded good, so I ran a rough comparison using my own nodes over two weeks—turning off the Kadcast optimization switch (the testnet has this option) versus keeping it on. Compared to the enabled state, the outbound traffic can indeed be reduced by close to 40%. But let me make this clear: this is purely a network-layer metric. Don’t equate it with “getting a 60% discount on node costs.” The money for the machines, storage, and the hardware expenses for the Prover—none of that is spared.
What truly made me feel this is worth highlighting is the little detail about port configuration. In the node guide, 9000/udp is marked as required, while 8080/tcp is optional. That signal is too direct: in Dusk’s architecture, Kadcast isn’t just a nice-to-have—it’s the lifeline of communication. When a proposal needs to be transmitted, validation votes have to fly, and approved-phase results need to be consolidated, if any step stalls due to network congestion, the consensus experience falls apart immediately. You can make block production as fast as you want, but if messages can’t get through, it’s effectively zero.
People who’ve run nodes in ETH’s ecosystem all have a similar feeling: once you get into the thousands of nodes on the testnet, the synchronization delay starts to drift. Dusk separates propagation efficiency and treats it as a standalone optimization layer—so the direction is right. But what matters long term is whether, after the node count doubles and doubles again, Kadcast’s “map” can still maintain a low redundancy rate and stable latency. This has nothing to do with TPS, and nothing to do with security thresholds. It’s simply homework for the communication layer itself.
@Dusk $DUSK #dusk