Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Historical batches #3165

Merged
merged 7 commits into from
Jan 3, 2023
Merged

Conversation

arnetheduck
Copy link
Contributor

Supercedes #2649, see original PR for discussion.

arnetheduck and others added 4 commits October 27, 2022 10:33
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
@hwwhww hwwhww added the Capella label Dec 16, 2022
Copy link
Contributor

@djrtwo djrtwo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still need to review testing. logic looks good

specs/capella/beacon-chain.md Outdated Show resolved Hide resolved
@@ -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]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might just call this historical_summaries and HistoricalSummary.
slight preference for the var name to match the class name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No objections

Co-authored-by: Danny Ryan <dannyjryan@gmail.com>
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
Copy link
Contributor

@hwwhww hwwhww Jan 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree on changing the name to block/state_summary_root. although don't feel too strongly

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no objections :)

Copy link
Contributor

@hwwhww hwwhww left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants