Implementation of the KadCast Network layer. Actually, being implemented here: https://github.com/dusk-network/dusk-blockchain/tree/kadcast/pkg/p2p/kadcast
Vanilla networking types have broadcast operations which show a high complexity of
Requests on this model, add one
RTT for each hop, which ends being a big propagation delay in networks with a considerable amount of nodes.
Kadcast leaves out of scope privacy concerns on the P2P layer.
Kadcast is built on the top of
Kademlia and makes usage of its bases in order to then improve the broadcast timings/performance and the resiliance of the network.
Kadcast message types:
Kadcast is an UDP-based peer-to-peer protocol in which nodes for a structured overlay. (It can be build agnostigly to the transport protocol used, but we will supose UDP for now.)
All of the nodes have an unique identifier which is generated when they join the network and it's tipically the hash of the private key or the public key and has a length of
This ID determinates the position of the node in a binary routing tree. That's the basics of the Kademlia system.
Nodes mantain the routing state classifiing other nodes in
k-buckets storing for each node the triplet:
(ip_addr, port, ID.
Each bucket is a list of the
k last recently seen nodes at a certain distance in relation to our node.
Kis a system-wide parameter which determines the routing state and the lookup complexity.
This distance corresponds to the
non-euclidean XOR metric which represents:
d(x,y) = (x ^ y).
And that implies that each node holds
K buckets where on each bucket we can fit the nodes that have a distance
2^i <= d < 2^(i +1).
If a node wants to add anew entry to a given bucket that already holds
kentries, it employs a least recently used
Before dropping an entry from the list, the peer will send a
PINGmessage to see whether the respective node is still reachable. Only if the node is not reachable anymore, it will be dropped.
By doing this the protocol favors the old and stable nodes on the network.
This is the process a node has to do in order to join the P2P network.
The main goal is to connect to the
boostrap nodes and then, retrieve info about the rest of the peers of the network in order to fill our buckets with neighbours.
- When a node �first joins the network, it has to know the address of at least one bootstrapping node. It therefore sends
PINGmessages to known nodes to check whether they are actually online. Additionally,
PINGtransmits the sending node’s routing information to the recipient, thereby distributing its existence in the network. The bootstrap node will reply with a
PONGmessage which also contains it's node info.
Starts just after the boostraping process.
The main goal is to fill up the k-buckets with
k different nodes.
- The process starts by sending a
FIND_NODEmessage to the bootstraping nodes that have been added to the k-buckets with the
- Then the lookup process starts:
- The node looks up the 𝛼 closest nodes regarding the XOR-metric in its own buckets.
- It queries this 𝛼 nodes for the ID by sending
FIND_NODEmessages and stores the .
- The queried nodes respond with a set of k nodes they belive are the closest to
- Based on the info adquired information, the node builds a new set of closest nodes and repeats the steps 1 and 3 repeatedly until it does not get closer nodes than it had on the previous iteration.
Note that like the bucket size, 𝛼 and k are global constants that will determine the redundancy and overhead of the network. The typical values are:
k = [20, 100]&
𝛼 = 3.
In my head this should be done for each bucket until we don't get closest nodes or either, the bucket is full.
We should discuss it
Each node periodically refreshes every bucket it has not seen some activity from in the last hour: for each such bucket, it picks a random
ID with appropriate distance and performs a look up to populate its buckets with fresh routing information.
For this propagation process, we will use the
CHUNK messages and the
redundant broadcasting algorithm purposed on the Kadcast paper.
- The algorithm delegates the broadcasting to the sub-trees (buckets).
- This sub-trees delegate at the same time into a decreasing heigh
- When the broadcast process is initiated, the miner is responsible for the entire height
h = L.
- The miner picks a random peer from each bucket and delegates the broadcast responsibilities by sending the
CHUNKmessages to them (which carry the data and her routing info).
- The receiver of the
CHUNKmessage assugns a new height
hwhich assigns the receiver's broadcast responsibility. So it stores the data of the
CHUNKmessage and then it sends it back with the new height value to
k - hwhich btw is the the number of buckets where a random peer will be selected to send the
CHUNKagain this time.
Improving the broadcast Reliability and Performance
- Even the IP protocol grants the best effort datagram, it cannot grant that the network won't have packet losses. And since protocols with CRC codes or RT procedures like
TCPare slow compared to others without theese kind of properties like
- We also cannot assume that all of the peers play fair and behave correctly on the network. In order to avoid the aforementioned problems:
- Instead of delegating the broadcast to one peer per bucket, we select β delegates.
This increases the probability of at least one honest node receiving the message.
As each broadcast process is repeated on every hop (decreasing the height), therefore Kadcast nodes ignore duplicate
2) Kadcast has to consider transmission failures. Due to that, Kadcast employs forward error connection schemes based on RaptorQ
FEC overhead factor can be adjusted through the paramenter
f = (n-s)/s.
Need to review RaptorQ paper to get this more clear.
With the benchmarks it's demonstrated that we can get full network coverage even assuming a 12% packet-loss ratio with a
β = 3 &
f = 0,15.
This can be improved or decreased according to our needs.
This section will be expanded once we get closer to a basic protocol implementation. ATM, the paper gives solutions for DOS, Sybil and Eclipse attacks and obstruction of block delivery.