Add ExecutionPayloadHeader to LC data
#3151
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Introduce `get_lc_beacon_slot` and `get_lc_beacon_root` accessors similar to `get_current_slot(state)` to account for future extensions to the light client header structure that may override how those fields are accessed. Idea is to extend with execution accessors in the future.
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.
|
Builds on top of:
All of these PRs have been merged into this branch – filter for the last commit of this PR to review the Capella specific additions. |
|
|
@etan-status |
etan-status
added a commit
to status-im/nimbus-eth2
that referenced
this pull request
Jan 15, 2023
Implements the proposed light client data format for Capella: - ethereum/consensus-specs#3151
etan-status
added a commit
to status-im/nimbus-eth2
that referenced
this pull request
Jan 15, 2023
Implements the proposed light client data format for Capella: - ethereum/consensus-specs#3151
etan-status
added a commit
to status-im/nimbus-eth2
that referenced
this pull request
Jan 15, 2023
Implements the proposed light client data format for EIP4844: - ethereum/consensus-specs#3151
etan-status
added a commit
to etan-status/beacon-APIs
that referenced
this pull request
Jan 15, 2023
Implements the light client data format for Capella / EIP4844: - ethereum/consensus-specs#3151
etan-status
added a commit
to etan-status/beacon-APIs
that referenced
this pull request
Jan 15, 2023
Implements the light client data format for Capella / EIP4844: - ethereum/consensus-specs#3151
etan-status
added a commit
to etan-status/beacon-APIs
that referenced
this pull request
Jan 15, 2023
Implements the light client data format for Capella / EIP4844: - ethereum/consensus-specs#3151
etan-status
added a commit
to etan-status/beacon-APIs
that referenced
this pull request
Jan 15, 2023
Implements the light client data format for Capella / EIP4844: - ethereum/consensus-specs#3151
etan-status
added a commit
to etan-status/beacon-APIs
that referenced
this pull request
Jan 15, 2023
Implements the light client data format for Capella / EIP4844: - ethereum/consensus-specs#3151
etan-status
added a commit
to status-im/nimbus-eth2
that referenced
this pull request
Jan 16, 2023
Implements the proposed light client data format for Capella: - ethereum/consensus-specs#3151
|
Implemented in Nimbus: status-im/nimbus-eth2#4514 |
etan-status
added a commit
to status-im/nimbus-eth2
that referenced
this pull request
Jan 16, 2023
Implements the proposed light client data format for EIP4844: - ethereum/consensus-specs#3151
etan-status
added a commit
to status-im/nimbus-eth2
that referenced
this pull request
Jan 16, 2023
Implements the proposed light client data format for EIP4844: - ethereum/consensus-specs#3151
etan-status
added a commit
to status-im/nimbus-eth2
that referenced
this pull request
Jan 16, 2023
Implements the proposed light client data format for EIP4844: - ethereum/consensus-specs#3151
hwwhww
approved these changes
Jan 17, 2023
etan-status
added a commit
to status-im/nimbus-eth2
that referenced
this pull request
Jan 18, 2023
Implements the proposed light client data format for Capella: - ethereum/consensus-specs#3151
etan-status
added a commit
to status-im/nimbus-eth2
that referenced
this pull request
Jan 18, 2023
Implements the proposed light client data format for EIP4844: - ethereum/consensus-specs#3151
etan-status
added a commit
to status-im/nimbus-eth2
that referenced
this pull request
Jan 19, 2023
Implements the proposed light client data format for EIP4844: - ethereum/consensus-specs#3151
etan-status
added a commit
to etan-status/beacon-APIs
that referenced
this pull request
Jan 26, 2023
Implements the light client data format for Capella / EIP4844: - ethereum/consensus-specs#3151
etan-status
added a commit
to etan-status/beacon-APIs
that referenced
this pull request
Jan 26, 2023
Implements the light client data format for Capella: - ethereum/consensus-specs#3151
rolfyone
pushed a commit
to ethereum/beacon-APIs
that referenced
this pull request
Jan 28, 2023
Implements the light client data format for Capella: - ethereum/consensus-specs#3151
4 tasks
Ingridmichelledev
added a commit
to Ingridmichelledev/API-beacons
that referenced
this pull request
Mar 3, 2023
Implements the light client data format for Capella: - ethereum/consensus-specs#3151
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While the light client sync protocol currently provides access to the
latest
BeaconBlockHeader, obtaining the matching execution data needsworkarounds 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_getProofresponses against LC data.Access to
block_hashunlocks scenarios where a CL light client drivesan EL without
engine_newPayload. As of Altair, only the CL beaconblock root is available, but the EL block hash is needed for engine API.
Other fields in the
ExecutionPayloadHeadersuch aslogs_bloommayallow 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
LightClientStoreis proposed into the Capella spec that may beused 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
LightClientStoreso that light clients do not need to runa potentially expensive fork transition at a specific time. This enables
the
LightClientStoreto be upgraded at a use case dependent timing atany 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.