search

ethereum / portal-network-specs

Official repository for specifications for the Portal Network
302 stars 82 forks source link

Passive Bridges #128

Open nasdf opened 2 years ago

nasdf commented 2 years ago

This is an idea I had for a new bridge design. Any feedback would be appreciated.

The current bridge design requires nodes to actively push content into the network. This has the drawback of adding content that is potentially not as useful to end users of the network. Passive bridges solve this issue by fetching missing data lazily.

Passive bridges will work like normal network participants but can be identified by a special radius value. The radius value allows other participants to first query the network and if not found query the bridge. This allows for any missing content to be added on demand.

pipermerriam commented 2 years ago

I'm a little worried about approaches that create a node on the network that can be externally identified and which can be universally queried for any data. This introduces an incentive to just ask them for the data first instead of falling back to them since they are guaranteed to have it.

Maybe an alternate approach to this would be some method of "reporting" that content is missing that would allow normal nodes to do the legwork of reporting something is missing and the bridge nodes to be able to learn about missing data without revealing themselves.

My initial thoughts are this could be some kind of structured gossip protocol but it isn't clear how it should be structured...

nasdf commented 2 years ago

Good point about having them become the preferred provider for all data. I think the concept of a special radius value can be replaced by a mechanism to rank the bridges lower when querying the DHT.

If it is possible to fit this into the current state / history networks it could simplify the current bridge design and allow for networks to be bootstrapped more easily.

To reiterate some of the key attributes: