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

Bellatrix release candidate #2970

Merged
merged 150 commits into from
Aug 16, 2022
Merged

Bellatrix release candidate #2970

merged 150 commits into from
Aug 16, 2022

Conversation

djrtwo
Copy link
Contributor

@djrtwo djrtwo commented Aug 15, 2022

Includes BELLATRIX_FORK_EPOCH and tentative TERMINAL_TOTAL_DIFFICULTY for mainnet params

Note: TTD to be finalized in next few days. If adjusted, another release candidate will rapidly follow

todo:

etan-status and others added 30 commits May 2, 2022 13:08
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.
Some edits to remove stale information
…lines

Remove `@disable_process_reveal_deadlines` from `sanity/test_blocks.py`
* 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>
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)
mkalinin and others added 19 commits July 28, 2022 16:21
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 djrtwo changed the title Bellatrix release candidate [DO NOT MERGE] Bellatrix release candidate Aug 15, 2022
@hwwhww
Copy link
Contributor

hwwhww commented Aug 16, 2022

With #2972, the test vectors were built successfully.

consensus-spec-tests diff: https://docs.google.com/spreadsheets/d/1p4YLXa1ThJKSZuhMpfiNOCS_CVFEQk5KvQX8-FB7QJY/edit?usp=sharing

@djrtwo djrtwo added the Bellatrix CL+EL Merge label Aug 16, 2022
@djrtwo djrtwo changed the title [DO NOT MERGE] Bellatrix release candidate Bellatrix release candidate Aug 16, 2022
@djrtwo djrtwo merged commit a865bf6 into master Aug 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bellatrix CL+EL Merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.