How are UUIDs assigned in P2P protocols

Question

I am learning about P2P in general (mainly blockchain). I know many P2P protocols uses a distributed hash table for node lookup (kademlia) that maps UUIDs of nodes to their addresses.

I am curious about the most common way of UUID assignment.

Do nodes generate their own UUIDs? This would be dangerous since a naive or malicious node could generate an already existing uuid, right?

Or do some kind of boot nodes generate UUIDs for the joining nodes by wrapping a UUID in a certificate that normal nodes later can verify (since they all trust the boot nodes). The boot nodes would act as certificate authorities. It feels like using centralized CAs goes against the purpose of a P2P network though...

Or are some kind of Web of Trust used, where nodes vouch for each others UUID?

How are UUIDs commonly assigned in a P2P protocol?

Answer 1

UUIDs are allocated by the clients at random. This is their advantage - the space is large enough that a conflict is unlikely, but the protocol has to be robust enough to handle conflicts gracefully. Centralized management can be avoided.

Do nodes generate their own UUIDs?

Yes

This would be dangerous since a naive or malicious node could generate an already existing uuid, right?

No - because the protocol has to expect UUID conflicts from time to time.

Or do some kind of boot nodes generate UUIDs for the joining nodes by wrapping a UUID in a certificate that normal nodes later can verify (since they all trust the boot nodes).

I think the idea behind a P2P protocol is to avoid having centralized nodes.

Blockchain in particular uses a consensus model where the majority of the nodes have to agree something for something to be true, and malicious nodes have to be expected. While this applies to the protocol overall in principle, I am unfamiliar of the mechanics of the P2P communication layer specifically to confirm that is how the P2P layer in a given blockchain implementation operates.

Answer 2

DHT nodes randomly generates node ID by themselves.

def generate_id(length):
id = ""
for i in range(length):
    id += chr(randint(0, 255))

return id


def generate_node_id():
hash = sha1()
hash.update(generate_id(20))
return hash.digest()`

Node ID is generated randomly. Node ID is a 160-bit SHA-1 hash so the keyspace is 2^160. It is unlikely that one node has the same Node ID as the other node. Even if a malicious node impersonates another node, nothing will happen.

That node continues to function as usual without facing denial of service. Other nodes will continue to query that node for lookup search as that node has stayed longer in DHT than a malicious node and is known to other nodes. Whereas the malicious node has to propagate his presence in DHT which can take some time.

The situation will look something like same node ID but with two different routing tables. Some new nodes will query that malicious node as they discover him and he may return false responses but as the data in DHT is replicated very quickly, even if a single node is acting malicious that doesn't affect other nodes in DHT. Instead a threat actor signs up thousands of random nodes in DHT to propagate false information. This is called Sybil attack.

Cloning node ID is not really a problem because nodes die very quickly. By the time a malicious node will propagate his presence, the victim is probably gone offline and come back with new node ID. Though BitTorrent spec recommends to keep the same node ID as earlier because your earlier node ID might be still in other's routing table.