search

ethereum / portal-network-specs

Official repository for specifications for the Portal Network
299 stars 81 forks source link

FindContent message might not reach large radius node (State Network and History Network) #91

Open jinfwhuang opened 2 years ago

jinfwhuang commented 2 years ago

Related to https://github.com/ethereum/portal-network-specs/issues/89. Issue 89 is about a similar potential failure during gossip. This is about "req/resp".

When it fails to reach large radius node and the content is not available in the subnetwork, the findcontent will fail to locate the data. The DHT routing tables and routing logic could be improved.

https://github.com/ethereum/portal-network-specs/blob/master/state-network.md#find-content-0x05

pipermerriam commented 2 years ago

Currently, the transaction gossip network is the only network where this is a problem and that network doesn't use FINDCONTENT.

It is a gossip-only network, and thus it would only use OFFER/ACCEPT

I think this issue can be closed as #89 seems to cover the full issue.

jinfwhuang commented 2 years ago

I differentiate this issue from #89. #89 is about a gossip network, but this is about a find_value call on the "DHT".

Gossiping is recursively passing on a message through traversing the routing table. Value lookup is recursively passing the lookup request through traversing the routing table. I think a value lookup on this "radius"-aware DHT could also suffer from getting stuck on a low radius region of the network.

But it could be argued that if we have a solution for how to fix the routing table for the gossip network, applying a similar fix to the "DHT" network should also work. In that sense, it is a duplicate issue.

pipermerriam commented 2 years ago

I think a value lookup on this "radius"-aware DHT could also suffer from getting stuck on a low radius region of the network.

Right, I'm saying that there are no such value lookups in the transaction gossip network, and so I believe this is a non-issue.

jinfwhuang commented 2 years ago

Right, I'm saying that there are no such value lookups in the transaction gossip network, and so I believe this is a non-issue.

Got it. I updated the title to refer to state and history network.

pipermerriam commented 2 years ago

if #90 is not an issue (ring geometry works) then this is not an issue in the State network.

The history network uses XOR so this wouldn't be an issue there either. I think this is just a duplicate of #90 since content lookups are basically the same as node lookups.

jinfwhuang commented 2 years ago

I think this is orthogonal to the XOR vs. ring issue.

This is about some nodes have small radius and some nodes with large radius. Say that we get to the nodes that are very close to the content_id; however, those nodes still don't have enough radius coverage to the content_id. At that point, the vanilla routing table doesn't provide us any structure to find nodes with larger radius.

In a sense, the nodes space are two dimensional now. The one dimension is the id space; this could be traversed through the routing table. The second dimension is the node's choice of radius; our current construction of the routing table does allow us to traverse this dimension.

It is similar to #89. The only difference here is that it is about look up requests; #89 is about gossip. More or less the same thing. Maybe you are right, it is just a duplicate of #89.