Running Boreas RC1 nodes changed how I think about network infrastructure.
Not because of the block times or staking rewards. Because I started tcpdump-ing the sync traffic out of habit and noticed something most people never look at. @Dusk_Foundation nodes do not use Geth's gossipsub stack for block propagation. They use Kadcast.
That one detail matters more than most headline metrics.
Gossip protocol works by having each node push blocks to N random peers, who then push to their own peers. Exponential spread sounds efficient until you realize the same block arrives at the same node five times from five different paths. Bandwidth gets eaten by duplicates, not useful data.
Kadcast solves this differently. Nodes arrange into k-buckets using Kademlia XOR distance. The block producer sends only to the closest k nodes. Each hop follows the routing table forward without broadcasting to the full network. Every node receives each message once. Redundant packets drop close to zero.
For Dusk's architecture this is not a minor optimization. Phoenix PLONK proofs, Zedger commitments, and Hedger confidential variable proofs are all sizable payloads. DuskEVM Sequencer batches going back to DuskDS for SBA verification run through this same network. Under gossip, 50 nodes mutually forwarding verification requests would overwhelm household bandwidth. Kadcast cuts total bytes per block propagation by roughly one order of magnitude at that scale.
I ran two local testnet nodes simultaneously. One using Kadcast, one simulating gossip forwarding. Same block height, compared tcpdump captures directly. Inbound traffic on the Kadcast node was 38% of the gossip simulation. SBA signature rounds across producer, validator, and approver also moved through Kadcast, and block production jitter dropped noticeably.
Most node operators watch block times. The propagation layer underneath determines whether those block times stay stable under load.
#dusk $DUSK #Binance
Not because of the block times or staking rewards. Because I started tcpdump-ing the sync traffic out of habit and noticed something most people never look at. @Dusk_Foundation nodes do not use Geth's gossipsub stack for block propagation. They use Kadcast.
That one detail matters more than most headline metrics.
Gossip protocol works by having each node push blocks to N random peers, who then push to their own peers. Exponential spread sounds efficient until you realize the same block arrives at the same node five times from five different paths. Bandwidth gets eaten by duplicates, not useful data.
Kadcast solves this differently. Nodes arrange into k-buckets using Kademlia XOR distance. The block producer sends only to the closest k nodes. Each hop follows the routing table forward without broadcasting to the full network. Every node receives each message once. Redundant packets drop close to zero.
For Dusk's architecture this is not a minor optimization. Phoenix PLONK proofs, Zedger commitments, and Hedger confidential variable proofs are all sizable payloads. DuskEVM Sequencer batches going back to DuskDS for SBA verification run through this same network. Under gossip, 50 nodes mutually forwarding verification requests would overwhelm household bandwidth. Kadcast cuts total bytes per block propagation by roughly one order of magnitude at that scale.
I ran two local testnet nodes simultaneously. One using Kadcast, one simulating gossip forwarding. Same block height, compared tcpdump captures directly. Inbound traffic on the Kadcast node was 38% of the gossip simulation. SBA signature rounds across producer, validator, and approver also moved through Kadcast, and block production jitter dropped noticeably.
Most node operators watch block times. The propagation layer underneath determines whether those block times stay stable under load.
#dusk $DUSK #Binance