search

ethereum / portal-network-specs

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

Add a suggestion on how to verify recent headers #292

Closed kdeme closed 3 weeks ago

kdeme commented 7 months ago

Adds the suggestion the verify recent headers (not yet part of the historical_summaries) by using the LightClientHeader data of the Portal beacon network (requires light client sync).

This does not resolve the issue when a node just gets started and needs to verify backtracking headers (headers between head of chain and the last header of the last period). In theory this could be resolved by doing a backwards sync of the headers, but it is probably not even an issue for the network in the first place?

KolbyML commented 3 months ago

If we are listing the Portal Beacon Network as a provider of these summaries we should also list a consensus client. The reason I think we should list both is to show it as different paths to accomplish the same thing.

Especially with all the confusion around this we have gotten from L1 teams.

ogenev commented 3 months ago

If we are listing the Portal Beacon Network as a provider of these summaries we should also list a consensus client. The reason I think we should list both is to show it as different paths to accomplish the same thing.

Especially with all the confusion around this we have gotten from L1 teams.

The consensus client is used to bridge the historical summaries to the portal beacon network. IMO, listing a consensus client should be part of the portal beacon bridge specs.

kdeme commented 3 months ago

If we are listing the Portal Beacon Network as a provider of these summaries we should also list a consensus client. The reason I think we should list both is to show it as different paths to accomplish the same thing.

Especially with all the confusion around this we have gotten from L1 teams.

I think it is pretty clear already as is written that it is part of the beacon state. The only way to currently get it from a consensus client is to use a beacon REST API debug endpoint that grabs the whole state, not ideal. When I'm fully back at work I'll try to get a new endpoint for only the summaries in. For the time being, I could adjust the text here a bit to refer to using the debug endpoint to get the beacon state as an additional option when you have access to a consensus client.