#dusk $DUSK Today I’m reading the network layer documentation for @Dusk . I originally thought that all blockchain P2P networks were pretty much the same—broadcast transactions, sync blocks, nothing much to dig into. Then I came across the term "Kadcast" and realized that Dusk didn’t take the old Gossip protocol path.
The Gossip protocol works like the game of telephone: each node randomly selects a few neighbors to forward the message; those neighbors then forward it to their neighbors; and eventually the whole network knows. The advantage is good fault tolerance, but the cost is severe bandwidth waste—one and the same message may be received multiple times by the same node.
Kadcast replaces random broadcasting with a structured overlay network. Instead of randomly choosing neighbors, nodes forward messages directionally according to an organized topology. The official documentation says this can save 25% to 50% of bandwidth compared to the traditional Gossip protocol.
I understand that the constraint behind this design is: in financial scenarios, transaction confirmations can’t rely on the randomness of "sending it a few more times will eventually reach everyone". Structured routing makes the message propagation paths more predictable and the latency more controllable. For financial markets that require deterministic settlement, knowing "about how long the message takes to arrive" is as important as "that it arrives".
But the other side of this optimization is that structured networks are more sensitive to nodes joining and leaving. If a large number of nodes go offline at the same time, will the efficiency of rebuilding routing tables slow down the entire network? In the public documentation so far, I haven’t found any latency data under large-scale node volatility.
When I look at the network layer for #dusk , I’m not only interested in TPS and block time—I also want to see, after mainnet launch, the real-world measured bandwidth savings and the latency distribution of Kadcast under an actual node distribution. If DUSK’s underlying layer can run stably, then the financial applications on top will have a solid foundation. #dusk @Dusk
The Gossip protocol works like the game of telephone: each node randomly selects a few neighbors to forward the message; those neighbors then forward it to their neighbors; and eventually the whole network knows. The advantage is good fault tolerance, but the cost is severe bandwidth waste—one and the same message may be received multiple times by the same node.
Kadcast replaces random broadcasting with a structured overlay network. Instead of randomly choosing neighbors, nodes forward messages directionally according to an organized topology. The official documentation says this can save 25% to 50% of bandwidth compared to the traditional Gossip protocol.
I understand that the constraint behind this design is: in financial scenarios, transaction confirmations can’t rely on the randomness of "sending it a few more times will eventually reach everyone". Structured routing makes the message propagation paths more predictable and the latency more controllable. For financial markets that require deterministic settlement, knowing "about how long the message takes to arrive" is as important as "that it arrives".
But the other side of this optimization is that structured networks are more sensitive to nodes joining and leaving. If a large number of nodes go offline at the same time, will the efficiency of rebuilding routing tables slow down the entire network? In the public documentation so far, I haven’t found any latency data under large-scale node volatility.
When I look at the network layer for #dusk , I’m not only interested in TPS and block time—I also want to see, after mainnet launch, the real-world measured bandwidth savings and the latency distribution of Kadcast under an actual node distribution. If DUSK’s underlying layer can run stably, then the financial applications on top will have a solid foundation. #dusk @Dusk
Dusk的带宽真能省50%
0%
Kadcast主网能稳定运行吗
100%
节点掉线后路由多久恢复？
0%
1 votes • Voting closed