Add light client functionality to ePBS #18
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
Update light client protocol to proof execution data based on state. A new field `latest_execution_payload_root` is required for this reason. There is an open issue where `initialize_beacon_state_from_eth1` takes an `ExecutionPayloadHeader` but is not properly updated for the new semantics of this type to be a bid instead of an SSZ summary. `latest_execution_payload_root` is not correctly initialized, requiring hackery in `light_client.py`. This is left as is for now until naming of the SSZ summary vs the bid type is resolved. With ePBS, the execution data inside the `LightClientHeader` is at least one slot behind the latest `BeaconBlockHeader`, as execution data is only made available after the beacon block is signed. While noticeable in interactive use cases, this is not really avoidable as ePBS makes the `ExecutionPayload` available later than at slot start. The test framework lacks proper end to end ePBS related capabilities and some non light client test logic was minimally adjusted to fix LC tests. The LC implementation may be simplified further with EIP-7688 as it stabilizes `hash_tree_root` across forks. For example, the conversions to recover historical `ExecutionPayload` roots during the initial handful of epochs where `finalized_header` is in ELECTRA while `attested_header` is in EIP-7332, would be easier.
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.
Update light client protocol to proof execution data based on state. A new field
latest_execution_payload_rootis required for this reason. There is an open issue whereinitialize_beacon_state_from_eth1takes anExecutionPayloadHeaderbut is not properly updated for the new semantics of this type to be a bid instead of an SSZ summary.latest_execution_payload_rootis not correctly initialized, requiring hackery inlight_client.py. This is left as is for now until naming of the SSZ summary vs the bid type is resolved.With ePBS, the execution data inside the
LightClientHeaderis at least one slot behind the latestBeaconBlockHeader, as execution data is only made available after the beacon block is signed. While noticeable in interactive use cases, this is not really avoidable as ePBS makes theExecutionPayloadavailable later than at slot start.The test framework lacks proper end to end ePBS related capabilities and some non light client test logic was minimally adjusted to fix LC tests.
The LC implementation may be simplified further with EIP-7688 as it stabilizes
hash_tree_rootacross forks. For example, the conversions to recover historicalExecutionPayloadroots during the initial handful of epochs wherefinalized_headeris in ELECTRA whileattested_headeris in EIP-7332, would be easier.