search

ethereum / portal-network-specs

Official repository for specifications for the Portal Network
313 stars 85 forks source link

Add validation description for LightClientBootstrap + Update #306

Closed kdeme closed 5 months ago

kdeme commented 6 months ago

This explicitly adds the validation mentioned in step1 for https://github.com/ethereum/portal-network-specs/issues/296 and https://github.com/ethereum/portal-network-specs/issues/305

acolytec3 commented 5 months ago

This looks fine to me. A while back, I implemented an alternative solution in Ultralight for identifying a "probably" trusted bootstrap (basically just requesting recent LC updates and trying to gain a majority view on a trusted block root from comparing the responses provided of multiple peers) though that's not reliable except in a probabilistic way. Any opinions about including something like that as a fallback way of joining the network (e.g. in the case where a trusted block root can't be acquired directly?

pipermerriam commented 5 months ago

Any opinions about including something like that as a fallback way of joining the network

IMHO I think you should require a trusted block root to enter the network and using a probabilistic approach that can't be guaranteed is probably irresponsible client design at this stage of client development. If anything, it introduces an incentive to attack our network since it's very directly able to be attacked by spinning up a large number of malicious nodes.

kdeme commented 5 months ago

Any opinions about including something like that as a fallback way

I think this should be a client implementers choice, as I would probably advise against it for reasons that @pipermerriam points out. If it does turn out to be too big of an issue that many bootstraps are not available, we should move to the version where we provide all bootstrap (back-fill) with proofs against the roots of the historical_summaries.

pipermerriam commented 5 months ago

To be clear, I'm advising against the probabilistic approach mainly because I think it will be a time sink at this stage of protocol development, and the trusted root approach should be simple to implement. I fully agree that clients can and should choose to to implement whatever approach they prefer here.