search

ethereum / portal-network-specs

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

Add ephemeral block headers to the history network spec #341

Open pipermerriam opened 1 month ago

pipermerriam commented 1 month ago

fixes #336

should probably depend on #291

What is wrong

We are going to move towards keeping unproven headers in a separate content type than the proven ones. This is based on the discussion in #336

How was it fixed

We will refer to headers near the front of the chain that are not in a stable HistoricalSummaries as "ephemeral" headers. Their only proving path is through tracing the Header.parent_hash through the chain of headers and anchoring to a trusted header. This trusted header must come from an independent oracle (such as the portal beacon network).

All clients in the network will be assumed to have some quantity of these recent headers. The Ping and Pong custom_data field will also be modified to include a new field that signals how many of these recent headers a client is holding.

Clients will need to perform a data migration on their database to remove the previous unproven headers that are no longer valid after this change. Values in the database that previously used the None proof type should be purged, and the subsequent values should be modifed to correct the Union selector if they have been stored with that as part of the data field.

Clients will need to implement a mechanism to purge ephemeral headers as or after they transition out of the most recent epoch boundary.

Clients will need to implement a syncing mechanism to fetch and fill their database with the appropriate window of recent headers that are still within the current unfinalized epoch.

Clients will need to implement an oracle (such as the portal beacon network) to be continually updated on what the most recent block header is, and to use this as the validation anchor for any headers requested this way.

Our hive and testing infrastructure will need to be updated to reflect these changes.

KolbyML commented 1 month ago

This PR changes the custom_payload for history. I propose we deploy this change through https://github.com/ethereum/portal-network-specs/pull/348 which should make upgrading custom_payload easier in the future without the risk of breaking interop and allowing us a window for all implementations to update to the new format before deprecating older versions.