release for jan testnets #3192
Merged
release for jan testnets #3192
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
Introduce `block_to_light_client_header` helper function to enable future forks to override it with additional info (e.g., execution), without having to change the general light client logic. Likewise, update existing light client data creation flow to use `block_to_light_client_header` and default-initialize empty fields. Furthermore, generalize `create_update` helper to streamline test code using `block_to_light_client_header`. Note: In Altair spec, LC header is the same as `BeaconBlockHeader`. however; future forks will extend it with more information.
BlobsSidecarsByRange: Change range lower bound to EIP4844_FORK_EPOCH
Co-authored-by: Danny Ryan <dannyjryan@gmail.com>
Clarify BeaconBlockAndBlobsSidecarByRoot no blob available
Handle unavailable data outside of prune window
Add `compute_kzg_proof` as a public method
…l_batches` -> `historical_summaries`
…ot` to `state_summary_root`
* Squash commits * Rename TEST_TYPE to TEST_PRESET_TYPE * Try python3 -m pytest -n 16 * updating actions versions * adding cleanup * reorder * Add eip4844 Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
Historical batches
…thdrawals (#3184) * tests/formats: update epoch and operations formats to reflect push-withdrawals of PR 3068 * fix typo * Update epoch processing readme Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
Add `block_to_light_client_header` helper
Fix typo in eip4844/BeaconBlocksByRoot docs
Co-authored-by: Danny Ryan <dannyjryan@gmail.com>
EIP4844: Enable withdrawal
Add notes for new state historical accumulators
Ensure that no duplidate block hashes in `sync/from_syncing_to_invalid` test case
to 1.3.0-rc.0
bump VERSION.txt
Move `is_data_available` check to fork-choice `on_block`
…mmaries_update Fix test file name
djrtwo
changed the title
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.
todo:
is_data_availablecheck to fork-choiceon_block#3185sync/from_syncing_to_invalidtest case #3187