This commit changes the public API of the KZG library to the following high-level API:
```
- verify_kzg_proof()
- compute_aggregate_kzg_proof()
- verify_aggregate_kzg_proof()
- blob_to_kzg_commitment()
```
compared to the previous much more low-level API:
```
- compute_powers()
- matrix_lincomb()
- lincomb()
- bytes_to_bls_field()
- evaluate_polynomial_in_evaluation_form()
- verify_kzg_proof()
- compute_kzg_proof()
```
This means that all the cryptographic logic (including Fiat-Shamir) is now isolated and hidden in the KZG library and the `validator.md` file ends up being significantly simplified, only calling high-level KZG functions.
Some additional things that this commit does:
- Moves all EIP4844 cryptography into polynomial-commitments.md
- Improves the Fiat-Shamir stack by removing the need for SSZ and by introducing simple domain separators
Co-authored-by: Kevaundray Wedderburn <kevtheappdev@gmail.com>
Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
Co-authored-by: Dankrad Feist <mail@dankradfeist.de>
Moving the `is_post_xxx` functions to a separate module allows `genesis`
to also use them (cyclic import from `context` prevented this before).
This allows removing `FORKS_BEFORE_ALTAIR` and `FORKS_BEFORE_BELLATRIX`
constants and adding a more general `is_post_fork` function that needs
less maintenance. This then allows definition of `with_all_phases_from`
to streamline the implementation of the `with_xxx_and_later` decorators.
Future light client tests will also incorporate execution payload data.
To avoid confusion, rename the current `root` check to `beacon_root`.
Doing this now, as #3066 already requires LC test runners to update.
Currently, `test_single_merkle_proof` only supports `BeaconState` tests.
For future tests, different object classes are desirable. Update format
to allow testing other objects as well.
* 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>
Replaces `process_slot_for_light_client_store` which force updates the
`LightClientStore` automatically based on `finalized_header` age with
`try_light_client_store_force_update` which may be manually called based
on use case dependent heuristics if light client sync appears stuck.
Not all use cases share the same risk profile.
Adds `create_light_client_bootstrap` and `create_light_client_update`
functions as a reference implementation for serving light client data.
This also enables a new test harness to verify that light client data
gets applied to a `LightClientStore` as expected.
- Implement all the required glue code to make things executable
- Implement a dummy KZG trusted setup
Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
Introduces a new `LightClientBootstrap` structure to allow setting up a
`LightClientStore` with the initial sync committee and block header from
a user-configured trusted block root.
This leads to new cases where the `LightClientStore` is only aware of
the current but not the next sync committee. As a side effect of these
new cases, the store's `finalized_header` may now advance into the next
sync committee period before a corresponding `LightClientUpdate` with
the new sync committee is obtained, improving responsiveness.
Note that so far, `LightClientUpdate.attested_header.slot` needed to be
newer than `LightClientStore.finalized_header.slot`. However, it is now
necessary to also consider certain older updates to try and backfill the
`next_sync_committee`. The `is_better_update` helper is also updated to
improve `best_valid_update` tracking.
`LightClientUpdate` structures currently use different merkle proof root
depending on the presence of `finalized_header`. By always rooting it in
the same state (the `attested_header.state_root`), logic gets simpler.
Caveats:
- In periods of extended non-finality, `update.finalized_header` may now
be outdated by several sync committee periods. The old implementation
rejected such updates as the `next_sync_committee` in them was stale,
but the new implementation can properly handle this case.
- The `next_sync_committee` can no longer be considered finalized based
on `is_finality_update`. Instead, waiting until `finalized_header` is
in the `attested_header`'s sync committee period is now necessary.
- Because `update.finalized_header > store.finalized_header` no longer
holds (for updates with finality), an `is_better_update` helper is
added to improve `best_valid_update` tracking (in the past, finalized
updates with supermajority participation would always directly apply)
This PR builds on prior work from:
- @hwwhww at https://github.com/ethereum/consensus-specs/pull/2829