Electra introduces two changes that affect light client data handling:
1. The `ExecutionPayloadHeader` is extended with new fields.
This is handled similarly as before with the Deneb fork.
2. The `BeaconState` generalized indices change due to lack of EIP-6493.
This is handled by making the generalized index be fork dependent via
a helper function that computes it dynamically. Furthermore, the case
where pre-Electra light client data is consumed by an Electra based
`LightClientStore` requires normalizing the shorter proof of the
pre-Electra data to fit into the Electra data structure by prepending
a zero hash.
* Add docs
* update link to template
* Add more info
* Try mkdocs
* Create docs.yml
* Update docs.yml
* update
* update
* update
* Try mkdocs
* Add "B: Make it executable for pytest and test generator" section
* Use mkdocs-material
* Use `mkdocs-awesome-pages-plugin` to create custom specs order
* Add toc permalink
* Update site_url
* Add .pages files for navigations. Update highlight style
* Dark theme
* Fix list indent
While the light client sync protocol currently provides access to the
latest `BeaconBlockHeader`, obtaining the matching execution data needs
workarounds such as downloading the full block.
Having ready access to the EL state root simplifies use cases that need
a way to cross-check `eth_getProof` responses against LC data.
Access to `block_hash` unlocks scenarios where a CL light client drives
an EL without `engine_newPayload`. As of Altair, only the CL beacon
block root is available, but the EL block hash is needed for engine API.
Other fields in the `ExecutionPayloadHeader` such as `logs_bloom` may
allow light client applications to monitor blocks for local interest,
e.g. for transfers affecting a certain wallet. This enables to download
only the few relevant blocks instead of every single one.
A new `LightClientStore` is proposed into the Capella spec that may be
used to sync LC data that includes execution data. Existing pre-Capella
LC data will remain as is, but can be locally upgraded before feeding it
into the new `LightClientStore` so that light clients do not need to run
a potentially expensive fork transition at a specific time. This enables
the `LightClientStore` to be upgraded at a use case dependent timing at
any time before Capella hits. Smart contract and embedded deployments
benefit from reduced code size and do not need synchronization with the
beacon chain clock to perform the Capella fork.
