status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
eth2.0-specs/tests/generators/light_client/main.py

23 lines
679 B
Python
Raw Normal View History

Add EIP4844 testgen
2022-11-10 15:38:08 +00:00
from eth2spec.test.helpers.constants import ALTAIR, BELLATRIX, CAPELLA, EIP4844
Root `next_sync_committee` in `attested_header` `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
2022-04-29 14:22:26 +00:00
from eth2spec.gen_helpers.gen_from_tests.gen import run_state_test_generators
if __name__ == "__main__":
Move test files to `light_client` subdir
2022-07-15 19:36:26 +00:00
altair_mods = {key: 'eth2spec.test.altair.light_client.test_' + key for key in [
Move `merkle/single_proof` tests to `light_client/single_merkle_proof`
2022-07-22 13:34:09 +00:00
'single_merkle_proof',
Move test files to `light_client` subdir
2022-07-15 19:36:26 +00:00
'sync',
Root `next_sync_committee` in `attested_header` `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
2022-04-29 14:22:26 +00:00
'update_ranking',
]}
bellatrix_mods = altair_mods
Add Capella tests
2022-10-13 19:53:40 +00:00
capella_mods = bellatrix_mods
Add EIP4844 testgen
2022-11-10 15:38:08 +00:00
eip4844_mods = capella_mods
Root `next_sync_committee` in `attested_header` `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
2022-04-29 14:22:26 +00:00
all_mods = {
ALTAIR: altair_mods,
BELLATRIX: bellatrix_mods,
Add Capella tests
2022-10-13 19:53:40 +00:00
CAPELLA: capella_mods,
Add EIP4844 testgen
2022-11-10 15:38:08 +00:00
EIP4844: eip4844_mods,
Root `next_sync_committee` in `attested_header` `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
2022-04-29 14:22:26 +00:00
}
Move test files to `light_client` subdir
2022-07-15 19:36:26 +00:00
run_state_test_generators(runner_name="light_client", all_mods=all_mods)