-
Notifications
You must be signed in to change notification settings - Fork 984
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
Bellatrix release candidate #2970
Merged
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
As the sync committee signs the previous block, the situation arises at every sync committee period boundary, that the new sync committee signs a block in the previous sync committee period. The light client cannot reliably detect this condition (e.g., assume that this is the case when it is currently on the last slot of a sync committee period), because the last couple slots of a sync committee period may not have a block. For example, when receiving a `LightClientUpdate` that is constructed as in the following illustration, it is unknown whether `sync_aggregate` was signed by the current or next sync committee at `attested_header`. ``` slot N N + 1 | N + 2 (slot not sent!) | +-----------------+ \ / | +----------------+ | attested_header | <--- X ----|---- | sync_aggregate | +-----------------+ / \ | +----------------+ missed | | sync committee period boundary ``` This patch addresses this edge case by including the slot at which the `sync_aggregate` was created into the `LightClientUpdate` object. Note that the `signature_slot` cannot be trusted beyond the purpose of signature verification, as it could be manipulated to any other slot within the same sync committee period and fork version, without making the `sync_aggregate` invalid.
bump version.txt
Some edits to remove stale information
Update README.md for test formats
…lines Remove `@disable_process_reveal_deadlines` from `sanity/test_blocks.py`
Tidy up README.md specs list
* t push base design for partial withdrawals * moor tests * clean up withdrawals naming * make partial withdrawal randomized tests better * Apply suggestions from code review Co-authored-by: Alex Stokes <r.alex.stokes@gmail.com> Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com> * fix mainnet brokn test * name swap * lint Co-authored-by: Alex Stokes <r.alex.stokes@gmail.com> Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
All code pretty much straight up copied from ethereum/EIPs#5088
Allow light client to verify signatures at period boundary
The `fork_version` field in `LightClientUpdate` can be derived from the `update.signature_slot` value by consulting the locally configured fork schedule. The light client already needs access to the fork schedule to determine the `GeneralizedIndex` values used for merkle proofs, and the memory layouts of the structures (including `LightClientUpdate`). The `fork_version` itself is network dependent and doesn't reveal that info.
Fix Name Discrepancy (WITHDRAWAL_QUEUE_LIMIT)
Optimizing EIP-4844 block validation (using KZG proofs)
fixed typo in on_block() definition
Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
Do not overload index with WithdrawalIndex and ValidatorIndex
Co-authored-by: Danny Ryan <dannyjryan@gmail.com>
Opti sync: how to apply `latestValidHash` when payload is `INVALID`
more execution payload tests and cleanup old ones
Opti sync: elaborate on why sync optimistically
* Do not overload index with WithdrawalIndex and ValidatorIndex * a few more bellatrix tests * use function from other PR * fix tests * Update tests/core/pyspec/eth2spec/test/bellatrix/transition/test_transition.py Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com> * refactor to reuse bellatrix transitio ntests for all transitions Co-authored-by: Potuz <potuz@prysmaticlabs.com> Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
* merge mainnet ttd and bellatrix values * Update configs/minimal.yaml Co-authored-by: Paul Harris <paul.harris@consensys.net> Co-authored-by: Paul Harris <paul.harris@consensys.net>
* Extend optimistic node definition * Update sync/optimistic.md Co-authored-by: terencechain <terence@prysmaticlabs.com> Co-authored-by: terencechain <terence@prysmaticlabs.com>
djrtwo
changed the title
Bellatrix release candidate
[DO NOT MERGE] Bellatrix release candidate
Aug 15, 2022
With #2972, the test vectors were built successfully.
|
Fix transition test generator
djrtwo
changed the title
[DO NOT MERGE] Bellatrix release candidate
Bellatrix release candidate
Aug 16, 2022
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.
Includes
BELLATRIX_FORK_EPOCH
and tentativeTERMINAL_TOTAL_DIFFICULTY
for mainnet paramsNote: TTD to be finalized in next few days. If adjusted, another release candidate will rapidly follow
todo: