Historical batches #3165
Merged
Historical batches #3165
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR, a continuation of replaces `historical_roots` with `historical_block_roots`. By keeping an accumulator of historical block roots in the state, it becomes possible to validate the entire block history that led up to that particular state without executing the transitions, and without checking them one by one in backwards order using a parent chain. This is interesting for archival purposes as well as when implementing sync protocols that can verify chunks of blocks quickly, meaning they can be downloaded in any order. It's also useful as it provides a canonical hash by which such chunks of blocks can be named, with a direct reference in the state. In this PR, `historical_roots` is frozen at its current value and `historical_batches` are computed from the merge epoch onwards. After this PR, `block_batch_root` in the state can be used to verify an era of blocks against the state with a simple root check. The `historical_roots` values on the other hand can be used to verify that a constant distributed with clients is valid for a particular state, and therefore extends the block validation all the way back to genesis without backfilling `block_batch_root` and without introducing any new security assumptions in the client. As far as naming goes, it's convenient to talk about an "era" being 8192 slots ~= 1.14 days. The 8192 number comes from the SLOTS_PER_HISTORICAL_ROOT constant. With multiple easily verifable blocks in a file, it becomes trivial to offload block history to out-of-protocol transfer methods (bittorrent / ftp / whatever) - including execution payloads, paving the way for a future in which clients purge block history in p2p. This PR can be applied along with the merge which simplifies payload distribution from the get-go. Both execution and consensus clients benefit because from the merge onwards, they both need to be able to supply ranges of blocks in the sync protocol from what effectively is "cold storage". Another possibility is to include it in a future cleanup PR - this complicates the "cold storage" mode above by not covering exection payloads from start.
avoids changing "header" fields in state
djrtwo
reviewed
Dec 20, 2022
specs/capella/beacon-chain.md
Outdated
| @@ -226,6 +241,8 @@ class BeaconState(Container): | |||
| # Withdrawals | |||
| next_withdrawal_index: WithdrawalIndex # [New in Capella] | |||
| next_withdrawal_validator_index: ValidatorIndex # [New in Capella] | |||
| # Deep history valid from Capella onwards | |||
| historical_batches: List[HistoricalBatchSummary, HISTORICAL_ROOTS_LIMIT] # [New in Capella] | |||
There was a problem hiding this comment.
I might just call this historical_summaries and HistoricalSummary.
slight preference for the var name to match the class name
Co-authored-by: Danny Ryan <[email protected]>
arnetheduck
commented
Dec 22, 2022
…l_batches` -> `historical_summaries`
hwwhww
reviewed
Jan 2, 2023
specs/capella/beacon-chain.md
Outdated
Comment on lines
124
to
130
| class HistoricalSummary(Container): | ||
| """ | ||
| `HistoricalSummary` matches the components of the phase0 `HistoricalBatch` | ||
| making the two hash_tree_root-compatible. | ||
| """ | ||
| block_batch_root: Root | ||
| state_batch_root: Root |
There was a problem hiding this comment.
@djrtwo @arnetheduck
Should we also rename block_batch_root to block_summary_root and state_batch_root to state_summary_root? The docstring hints it has a connection to HistoricalBatch, so I didn't change it. I'm okay with either way.
There was a problem hiding this comment.
agree on changing the name to block/state_summary_root. although don't feel too strongly
There was a problem hiding this comment.
no objections :)
…ot` to `state_summary_root`
hwwhww
approved these changes
Jan 3, 2023
There was a problem hiding this comment.
For the record: in the EIP-4844 call today (ethereum/pm#701), we decided to bring Capella back to EIP-4844. I will open another PR to clean up the no ops.
@arnetheduck, this PR was first proposed on May 20, 2021 (!!!) Congrats!
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Supercedes #2649, see original PR for discussion.