search

harnen / p2p-service-discovery

0 stars 4 forks source link

Adapt Kademlia to behave as in Ethereum #1

Open harnen opened 4 years ago

harnen commented 4 years ago
harnen commented 4 years ago

There's this Ethereum wiki entry. We should probably confirm if that's the latest one and no changes are coming in Eth 2.0

srene commented 4 years ago

There's this Ethereum wiki entry. We should probably confirm if that's the latest one and no changes are coming in Eth 2.0

Thanks. By now I drafted the discovery process extracting the info from this paper https://www.researchgate.net/publication/335441865_Eclipsing_Ethereum_Peers_with_False_Friends which i think it explains the process in more detail. I will now check the go code to confirm that actually works like this, and later i will list the modifications required in kademlia.

harnen commented 4 years ago

One thing to verify would be to see in what order are we sending requests. The Kademlia paper says that we could use latency measurements (and send the request to the closest nodes first). This is not currently implemented in peersim.

srene commented 4 years ago

Do you mean how nodes are ordered in the same k-bucket? I think are ordered for liveness order (the last seen first). I'm checking geth code but it'll take some time..

On 08/06/2020 10:32, Michał Król wrote:

One thing to verify would be to see in what order are we sending requests. The Kademlia paper says that we could use latency measurements (and send the request to the closest nodes first). This is not currently implemented in peersim.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/harnen/p2p-service-discovery/issues/1#issuecomment-640453929, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNSP4XVZF6G7CBQZXUBX33RVSO2PANCNFSM4NST45MQ.

harnen commented 4 years ago

Within a k-bucket is the last seen first. My question is how do you chose nodes when you send request to find nodes. You can send up to alpha requests in parallel and stop whenyou do not receive new information, but which nodes are contact first? The Kademlia paper mentions:

Kademlia can route for lower latency because it has the flexibility of choosing any one of k nodes to forward a request to.

But we could also ask Felix about it I guess.

srene commented 4 years ago

According to  https://github.com/ethereum/devp2p/blob/master/discv4.md, The lookup initiator starts by picking |α| closest nodes to the target it knows of, so it's based on the log distance of the node id. Alpha is equal to 3. The process is repeated with the results and iterated until there is no new |α| closest nodes

On 08/06/2020 17:23, Michał Król wrote:

Within a k-bucket is the last seen first. My question is how do you chose nodes when you send request to find nodes. You can send up to alpha requests in parallel and stop whenyou do not receive new information, but which nodes are contact first? The Kademlia paper mentions:

|Kademlia can route for lower latency because it has the flexibility of choosing any one of k nodes to forward a request to.|

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/harnen/p2p-service-discovery/issues/1#issuecomment-640698768, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNSP4TA2LEXESPSNFUPMNLRVT667ANCNFSM4NST45MQ.