status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
eth2.0-specs/specs/capella/light-client/sync-protocol.md

95 lines
2.7 KiB
Markdown
Raw Normal View History

Add `ExecutionPayloadHeader` to LC data 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.
2022-12-11 23:43:07 +00:00
# Capella Light Client -- Sync Protocol
**Notice**: This document is a work-in-progress for researchers and implementers.
## Table of contents
<!-- TOC -->
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
- [Introduction](#introduction)
- [Constants](#constants)
Align formatting
2023-12-27 11:54:36 +00:00
- [Helper types](#helper-types)
- [`ExecutionBranch`](#executionbranch)
Add `ExecutionPayloadHeader` to LC data 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.
2022-12-11 23:43:07 +00:00
- [Containers](#containers)
Merge branch 'dev' into lc-eph
2023-01-12 17:39:11 +00:00
- [Modified `LightClientHeader`](#modified-lightclientheader)
Add `ExecutionPayloadHeader` to LC data 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.
2022-12-11 23:43:07 +00:00
- [Helper functions](#helper-functions)
- [`get_lc_execution_root`](#get_lc_execution_root)
Merge branch 'dev' into lc-eph
2023-01-12 17:39:11 +00:00
- [Modified `is_valid_light_client_header`](#modified-is_valid_light_client_header)
Add `ExecutionPayloadHeader` to LC data 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.
2022-12-11 23:43:07 +00:00
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
<!-- /TOC -->
## Introduction
This upgrade adds information about the execution payload to light client data as part of the Capella upgrade. It extends the [Altair Light Client specifications](../../altair/light-client/sync-protocol.md). The [fork document](./fork.md) explains how to upgrade existing Altair based deployments to Capella.
Additional documents describes the impact of the upgrade on certain roles:
- [Full node](./full-node.md)
- [Networking](./p2p-interface.md)
## Constants
| Name | Value |
| - | - |
| `EXECUTION_PAYLOAD_INDEX` | `get_generalized_index(BeaconBlockBody, 'execution_payload')` (= 25) |
Align formatting
2023-12-27 11:54:36 +00:00
## Helper types
### `ExecutionBranch`
Capella addition
2023-12-27 11:44:05 +00:00
```python
Use proper types when dealing with LC Merkle proofs
2023-12-27 12:59:31 +00:00
class ExecutionBranch(Vector[Bytes32, floorlog2(EXECUTION_PAYLOAD_INDEX)]):
Capella addition
2023-12-27 11:44:05 +00:00
pass
```
Add `ExecutionPayloadHeader` to LC data 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.
2022-12-11 23:43:07 +00:00
## Containers
Merge branch 'dev' into lc-eph
2023-01-12 17:39:11 +00:00
### Modified `LightClientHeader`
Add `ExecutionPayloadHeader` to LC data 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.
2022-12-11 23:43:07 +00:00
```python
class LightClientHeader(Container):
# Beacon block header
beacon: BeaconBlockHeader
# Execution payload header corresponding to `beacon.body_root` (from Capella onward)
execution: ExecutionPayloadHeader
Capella addition
2023-12-27 11:44:05 +00:00
execution_branch: ExecutionBranch
Add `ExecutionPayloadHeader` to LC data 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.
2022-12-11 23:43:07 +00:00
```
## Helper functions
### `get_lc_execution_root`
```python
def get_lc_execution_root(header: LightClientHeader) -> Root:
Merge branch 'dev' into lc-eph
2023-01-12 17:39:11 +00:00
epoch = compute_epoch_at_slot(header.beacon.slot)
Compute epoch only once for better readability
2022-12-12 12:09:18 +00:00
if epoch >= CAPELLA_FORK_EPOCH:
Add `ExecutionPayloadHeader` to LC data 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.
2022-12-11 23:43:07 +00:00
return hash_tree_root(header.execution)
return Root()
```
Merge branch 'dev' into lc-eph
2023-01-12 17:39:11 +00:00
### Modified `is_valid_light_client_header`
Add `ExecutionPayloadHeader` to LC data 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.
2022-12-11 23:43:07 +00:00
```python
def is_valid_light_client_header(header: LightClientHeader) -> bool:
Merge branch 'dev' into lc-eph
2023-01-12 17:39:11 +00:00
epoch = compute_epoch_at_slot(header.beacon.slot)
Compute epoch only once for better readability
2022-12-12 12:09:18 +00:00
if epoch < CAPELLA_FORK_EPOCH:
Fix `is_valid_light_client_header`
2022-12-12 12:39:14 +00:00
return (
header.execution == ExecutionPayloadHeader()
Use proper types when dealing with LC Merkle proofs
2023-12-27 12:59:31 +00:00
and header.execution_branch == ExecutionBranch()
Fix `is_valid_light_client_header`
2022-12-12 12:39:14 +00:00
)
Flip `is_valid_light_client_header` logic for extensibility
2022-12-12 11:33:58 +00:00
return is_valid_merkle_branch(
leaf=get_lc_execution_root(header),
branch=header.execution_branch,
depth=floorlog2(EXECUTION_PAYLOAD_INDEX),
index=get_subtree_index(EXECUTION_PAYLOAD_INDEX),
root=header.beacon.body_root,
Add `ExecutionPayloadHeader` to LC data 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.
2022-12-11 23:43:07 +00:00
)
```