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.
While the current Altair specs define structures to aid light client
development, one missing key aspect is the network protocol definition.
Certain implementations have started defining their own REST based APIs,
e.g., Lodestar at https://github.com/ChainSafe/lodestar/blob/master/packages/api/src/routes/lightclient.ts
While such APIs are useful, REST does not seem to be the ideomatic
choice as the sole API available at such a low level for Ethereum.
This patch introduces a libp2p based protocol to allow light clients to
sync to the latest `BeaconBlockHeader` in a trustless and decentralized
manner, building on top of prior work from:
- @hwwhww at https://github.com/ethereum/consensus-specs/pull/2267
- @jinfwhuang at https://github.com/ethereum/consensus-specs/pull/2786
- Lodestar's REST API (also has an endpoint to fetch merkle proofs!)
Justin Traglia
parithosh
Etan Kissling
Hsiao-Wei Wang
Paul Harris
Potuz
Alex Stokes
Manu NALEPA
0xYYY
terence tsao
Paul Hauner
ethDreamer
lsankar4033
Danny Ryan
Piotr Chromiec
vbuterin
Mikhail Kalinin
protolambda