Add HistoricalSummariesBlockProof for headers from Capella onwards #291

kdeme · 2024-04-19T13:38:44Z

PR on top of #287

In draft as this would require a stable Portal beacon network deployed to have access to the historical_summaries.

ogenev · 2024-04-22T12:27:59Z

history-network.md

@@ -179,8 +181,21 @@ HistoricalRootsBlockProof = Container[
    slot: Slot
 ]

-BlockHeaderProof = Union[None, AccumulatorProof, HistoricalRootsBlockProof]
+# BeaconState historical_summaries proof (for Capella onwards)
+HistoricalSummariesProof = Vector[Bytes32, 13] # Proof that BeaconBlockHeader root is part of HistoricalSummaries


There is possible collusion with the proof for the HistoricalSummaries beacon content type in the beacon network here.

In Trin, I'm using HistoricalSummariesStateProof for the proof of the beacon content.

Yes I know, I mentioned that name clash here: #287 (comment)

I might reverse the naming because of that.

I've altered the naming which should avoid the name clash and hopefully also be more clear.

acolytec3 · 2024-08-07T12:44:43Z

history/history-network.md

-BlockHeaderProof = Union[None, HistoricalHashesAccumulatorProof, HistoricalRootsBlockProof]
+# Proof that BeaconBlock root is part of HistoricalRoots and thus canonical
+# For Capella and onwards
+HistoricalSummariesProof = Vector[Bytes32, 13]


What would you think about renaming this to something like HistoricalSummariesRootsProof or something similar so it's just 100% clear what it is? In parallel, I wonder if we could rename this beacon chain object to HistoricalSummariesWithStateProof to be 100% clear this is the proof that the summaries are rooted in the current beacon state.

In Trin we use HistoricalSummariesBlockProof and HistoricalSummariesStateProof. Happy to switch to whatever we decide.

I think the HistoricalSummariesBlockProof is the container below that holds both the BeaconBlockProof (i.e. the proof that an EL blockhash is part of a beacon block and then what is currently called thethe HistoricalSummariesProof which anchors the Beacon Block root in the HistoricalSummaries. As such, was thinking maybe we can call this second one "HistoricalSummariesRootProof" to reflect that we're anchoring the beacon block root in the particular block_summary_root for the period in which it falls.

I've altered the naming which should avoid the name clash and hopefully also be more clear.

acolytec3 · 2024-08-27T17:39:36Z

history/history-network.md

+
+# Proof for EL BlockHeader for Capella and onwards
+HistoricalSummariesBlockProof = Container[
+    beaconBlockProof: BeaconBlockProof,


As mentioned on Discord, this type isn't valid for post Capella Beacon Blocks since the proof length is now 12 elements long. I'm assuming we should add a new postCapellaBeaconBlockProof type that's a vector of 12 elements

Another (preferred) idea is to change the type of BeaconBlockProof to a List[Bytes32, 12]

I've made the change to List. I'm thinking however about also changing it to 1 same type for also the version that use historical_roots.

history/history-network.md

KolbyML

I would like to make it more clear the Portal Beacon Network isn't required and is one of many options to avoid additional confusion with EL teams for example.

It is easier to prevent confusion then to resolve it later on sorta like preventative care

KolbyML · 2024-10-21T18:53:56Z

history/history-network.md

+This chain of two proofs allows for verifying that an EL `BlockHeader` is part of the canonical chain. The only requirement is having access to the beacon chain `historical_summaries`.
+The `historical_summaries` is a [`BeaconState` field](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#beaconstate) that was introduced since the Capella fork. It gets updated every period (8192 slots). The `BlockProofHistoricalSummaries` MUST be used to verify blocks from the Capella fork onwards.
+
+The Portal beacon network [provides access](./beacon-chain/beacon-network.md#historicalsummaries) to an up to date `historical_summaries` object.


This can lead to confusion that the Portal Beacon Network is the only option to get these.

I think we should either

not mention the Portal Beacon Network

or mention multiple sources implementations could get this data, for example an EL client wouldn't run the Portal Beacon Network as it already has access to this data from their CL client.

The reason I mention this as it is a question I had to answer multiple times to EL layer teams and is consistently a cause of confusion

Perhaps I can alter it to:

"The historical_summaries can be taken from the CL BeaconState (Link to beacon API endpoint) or the Portal beacon network also provides access to an up to date historical_summaries object."

And hopefully in a secondary PR I can add a specific API endpoint for it :)

This sounds like a good solution to me because then it is clear you aren't forced to use Portal beacon but it is 1 of 2 options, which should prevent confusion

adjusted in ec0200c

kdeme · 2024-10-21T18:55:30Z

Again, I'd be fine with moving forward and merging this (after reviews), but with the same remark as here: #287 (comment)

And it also should be clear that we cannot really do the full validation yet for these type of headers as long as we do not have access to historical_summaries.

KolbyML

looks good

) * Add HistoricalSummariesBlockProof for headers from Capella onwards * Add more explanation + charts * Adjust options for getting historical_summaries based on feedback

kdeme force-pushed the historical-roots-block-proofs branch from 41225d6 to b0564a6 Compare April 22, 2024 09:19

kdeme force-pushed the historical-summaries-block-proofs branch from 4d12b99 to a250fee Compare April 22, 2024 09:24

ogenev mentioned this pull request Apr 22, 2024

feat(ethportal-api): add and refactor post-merge header proofs ethereum/trin#1264

Merged

1 task

ogenev reviewed Apr 22, 2024

View reviewed changes

This was referenced May 7, 2024

Verification of beacon LightClientBootstrap objects #296

Open

History Network: Task list for (somewhat?) "feature completeness" #240

Open

kdeme added the history-network label May 7, 2024

kdeme mentioned this pull request May 23, 2024

Requirements for Portal usage in EL client for history data expiry (EIP-4444) #308

Open

acolytec3 mentioned this pull request Jul 5, 2024

Support header verification and construction for post-merge proofs ethereumjs/ultralight#597

Open

5 tasks

kdeme force-pushed the historical-roots-block-proofs branch 2 times, most recently from 75e9a54 to d4d2cd9 Compare July 16, 2024 17:10

kdeme force-pushed the historical-summaries-block-proofs branch 2 times, most recently from bc3266a to c73d137 Compare July 16, 2024 17:14

acolytec3 reviewed Aug 7, 2024

View reviewed changes

acolytec3 reviewed Aug 27, 2024

View reviewed changes

KolbyML mentioned this pull request Sep 6, 2024

Proposal for block header lookup via block number in the history network #334

Merged

pipermerriam reviewed Sep 10, 2024

View reviewed changes

history/history-network.md Outdated Show resolved Hide resolved

kdeme commented Sep 11, 2024

View reviewed changes

history/history-network.md Outdated Show resolved Hide resolved

kdeme force-pushed the historical-roots-block-proofs branch from d4d2cd9 to da43ef0 Compare September 17, 2024 11:02

Add HistoricalSummariesBlockProof for headers from Capella onwards

79fa69d

kdeme force-pushed the historical-summaries-block-proofs branch from c73d137 to 79fa69d Compare September 18, 2024 09:05

Add more explanation + charts

adf6db5

kdeme requested review from acolytec3 and ogenev September 20, 2024 14:00

pipermerriam mentioned this pull request Sep 26, 2024

Add ephemeral block headers to the history network spec #341

Open

kdeme marked this pull request as ready for review October 21, 2024 18:53

KolbyML reviewed Oct 21, 2024

View reviewed changes

Adjust options for getting historical_summaries based on feedback

ec0200c

KolbyML approved these changes Oct 21, 2024

View reviewed changes

ogenev approved these changes Oct 23, 2024

View reviewed changes

KolbyML merged commit f5aed01 into historical-roots-block-proofs Oct 25, 2024
3 checks passed

KolbyML deleted the historical-summaries-block-proofs branch October 25, 2024 18:56

fearlessfe mentioned this pull request Oct 29, 2024

Add HistoricalSummariesBlockProof for headers from Capella onwards optimism-java/shisui#212

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add HistoricalSummariesBlockProof for headers from Capella onwards #291

Add HistoricalSummariesBlockProof for headers from Capella onwards #291

kdeme commented Apr 19, 2024

ogenev Apr 22, 2024

kdeme Apr 22, 2024

kdeme Sep 18, 2024

acolytec3 Aug 7, 2024

ogenev Aug 9, 2024

acolytec3 Aug 9, 2024

kdeme Sep 18, 2024

acolytec3 Aug 27, 2024

acolytec3 Aug 27, 2024

kdeme Sep 18, 2024

KolbyML left a comment

KolbyML Oct 21, 2024

kdeme Oct 21, 2024

KolbyML Oct 21, 2024

kdeme Oct 21, 2024

kdeme commented Oct 21, 2024

KolbyML left a comment

Add HistoricalSummariesBlockProof for headers from Capella onwards #291

Add HistoricalSummariesBlockProof for headers from Capella onwards #291

Conversation

kdeme commented Apr 19, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KolbyML left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kdeme commented Oct 21, 2024

KolbyML left a comment

Choose a reason for hiding this comment