Add a suggestion on how to verify recent headers #292
Conversation
history-network.md
Outdated
| accept headers without a proof. | ||
| accept headers without a proof. These headers MAY be verified if the node is following Portal beacon light client updates by verifying the `ExecutionPayloadHeader.block_hash` of the relevant `LightClientHeader`. | ||
|
|
||
| Clients SHOULD have a way of keeping track of the recent headers that it has stored without a proof (`None`). When these headers get added in the `historical_summaries` at the end of a period, they will be re-gossiped with their proofs. Clients SHOULD accept these headers with their proof and discard the old headers without proof. |
There was a problem hiding this comment.
The idea from #239 (comment) might be a cleaner solution to this.
kdeme
force-pushed
the
historical-summaries-block-proofs
branch
from
4d12b99 to
a250fee
Compare
kdeme
force-pushed
the
proving-recent-headers
branch
from
9043a28 to
93fafc3
Compare
kdeme
force-pushed
the
historical-summaries-block-proofs
branch
2 times, most recently
from
bc3266a to
c73d137
Compare
|
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. |
I think it is pretty clear already as is written that it is part of the beacon state. |
kdeme
force-pushed
the
historical-summaries-block-proofs
branch
from
c73d137 to
79fa69d
Compare
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?
kdeme
force-pushed
the
proving-recent-headers
branch
from
93fafc3 to
7b9ecf2
Compare
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?