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.
Runtime configurations apply to a certain network and the name of that
network is useful for humans such that they can talk about it.
Some of the existing configs already include a `CONFIG_NAME` toggle -
might as well add it here as well and avoid some confusion - this name
above all becomes useful in the beacon API.
By extension, the `CONFIG_NAME` config will appear in the beacon api as
a result of being defined here.
Polish `merge/beacon-chain.md` with mostly non-substantive changes.
**Non-substantive changes**
* rename `MAX_EXECUTION_TRANSACTIONS` to `MAX_TRANSACTIONS_PER_PAYLOAD`
- rename "execution transaction" to just "transaction" as per discussion with Danny
* rename `compute_time_at_slot` to `compute_timestamp_at_slot`
- the function returns a Unix timestamp
- "timestamp" matches `execution_payload.timestamp`
* be explicit about `ExecutionEngine.execution_state` for clarity
* rename `ExecutionPayload.number` to `ExecutionPayload.block_number`
- more specific ("number" is pretty vague)
- consistent with `ExecutionPayload.block_hash`
* rename `new_block` to `on_payload`
- the `on_` prefix is consistent with other event handlers (e.g. see `on_tick`, `on_block`, `on_attestation` [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/fork-choice.md#handlers))
- the `_payload` suffix is more to the point given the function accepts an `execution_payload`
- avoids conflict with `on_block` which is already used in the fork choice
* rework the table of contents for consistency
* order `is_execution_enabled` after `is_transition_completed` and `is_transition_block`
- `is_execution_enabled` refers to `is_transition_completed` and `is_transition_block`
* rename "transition" to "merge"
- "transition" is a bit vague—we will have other transitions at future hard forks
- there is no need for two words to refer to the same concept
* add a bunch of inline comments, e.g. in `process_execution_payload`
* make the `process_execution_payload` signature consistent with the other `process_` functions in `process_block` which take as arguments `state` and `block.body`
* remove `TRANSITION_TOTAL_DIFFICULTY`
- to be put in `merge/fork-choice.md` where it is used
* various misc cleanups
**Substantive changes**
* reorder `ExecutionPayload` fields
- for consistency with yellow paper and Eth1
- same for `ExecutionPayloadHeader`
- added comments separating out the execution block header fields from the extra fields (cosmetic)
this avoids the type overhead of having to define a max size for
the object's data and skips the overhead of serialization/consensus
for a type that does not need it
Etan Kissling
George Kadianakis
Hsiao-Wei Wang
Alex Stokes
ChihChengLiang
Danny Ryan
Mikhail Kalinin
Jacek Sieka
protolambda
Fredrik Svantes
Sam.An
Justin