3

So we can establish that XOR distance metric is a real metric (it’s symmetric, satisfies triangle inequality, etc.)

I was thinking before reading about Kademlia and its k-buckets that each node would simply find its own id and store its closest k neighbors, and vice versa. Nodes would periodically ping their neghbors and evict them from the list if they didn’t respond.

Now if I want to find some key X, I simply issue this request to the closest node among my neighbors to X, and this continues recursively until you get a node that is closest to X among itself and all its neighbors. This node would be among those who store the value for X, and then they would just reverse the steps (ie unwind the stack) to return the value to the requester.

A node would simply look up its own id when joining the network, and then add each of ots neighbors.

Seems much more straightforward than Kademlia. Would this work? Is it just much slower because each lookup may have many more hops?

Gregory Magarshak
  • 1,883
  • 2
  • 25
  • 35

1 Answers1

2

No.

Without kademlia's routing table you would have no guarantee that any node's neighbor list would actually contain contacts that are closer to the target key and thus could help your query converge towards the target.

This can even happen at the 0th hop, i.e. your local routing table may only contain neighbors that are further away from the target node than yourself. You will have no better contacts to query. You would actually have to go backwards on the distance metric, but xor distance does not allow negative distances since it is just a ring of positive integers modulo N, so negative distances wrap around to the most distant nodes, which is equivalent to kademlia's bucket with 0 prefix bits shared.

the8472
  • 40,999
  • 5
  • 70
  • 122