# Top-up sync

For syncing the EL and CL together, assuming they both have a reasonably recent starting point (as by checkpoint/snap sync), one of the methods available today is the following:

* CL starts two loops - Optimistic CL sync and EL top-up sync
* The optimistic CL sync proceeds as usual, as when the CL is operating an optimistic sync with or without an EL
* Allowing the CL to sync independently of the EL implies validating the block hash in the CL using an RLP-based hash computation, a technique employed by several consensus clients
* Introducing RLP can be avoided via [EIP-8237](https://github.com/ethereum/consensus-specs/pull/5183) - EIP-8237 represents a _net complexity increase_ since we're computing additional hashes just for this purpose
* A better option is to move the block to [SSZ (EIP-7807)](https://eips.ethereum.org/EIPS/eip-7807)
* In parallel, it launches a top-up sync for the EL that:
* queries the EL for its latest block number (BN)
* if BN+1 has been synced by the CL, sends BN+1 via newPayload to the EL, together with fcU
* repeats until el has reached CL head (at this point, the CL is fully and non-optimistically synced and can resume duties if close to the network consensus)

Once both loops have finished, both the EL and the CL are in sync - in particular, assuming it has a state, the EL does not need to fetch blocks via devp2p.

This method of syncing works throughout the maximum weak subjectivity period for which we require CL clients to retain history, ie ~5 months and has a number of advantages, specially for short topups:

* it is easy to understand and explain to users since the CL is "driving" the sync
* it is typically fast since the CL must download these blocks anyway and can do so efficiently - the blocks are processed in the same manner as when reacting to gossip and the EL can be treated as a simple and predictable state transition function with respect to block processing
* it provides an upgrade path towards migrating away from devp2p (ie the EL no longer needs to support block transfers via devp2p, with snap sync and mempools remaining there)

## Edge cases

### Forks

When switching forks, CL must make sure the fork is present on the EL - this means starting the topup loop on fork switch _or_ topping up any blocks in the new fork that the EL might not have observed

### Backfill / checkpoint sync

When checkpoint-syncing, the checkpoint might be ahead of the EL head and a gap may ensure - this gap will be filled when the CL performs the (mandatory) backfill of 5 months of blocks, ie as the gap is backfilled, block `BN+1` will eventually reach the CL at which point it can proceed to sync the EL as usual

### Storage owner

In current client architectures, both the CL and the EL have the opportunity to store the execution payload.

### No state

The choreography of fcU vs newPayload needs to be made deterministic such that the EL has an opportunity to sync state - ie to differentiate the case where the EL cannot process a block at all vs the case where it needs a particular block to proceed.

## Gloas

The infrastructure to implement top-up sync is already present in gloas:

* All necessary execution data structures are known to the CL since they are part of the gossip layer
* The by-root topup already provides the necessary cl-el execution api interface
* [ExecutionPayloadEnvelopesByRange](https://github.com/ethereum/consensus-specs/blob/v1.7.0-alpha.5/specs/gloas/p2p-interface.md#executionpayloadenvelopesbyrange-v1) fetches historical execution payloads, either loading them from the CL or EL depending on client architecture

The process can potentially be simplified by including block number in [ExecutionPayloadBid](https://github.com/ethereum/consensus-specs/blob/v1.7.0-alpha.5/specs/gloas/beacon-chain.md#executionpayloadbid) to simplify mapping of slot to block number.

## Future direction

Possible upgrades to the above include:

* SSZ-based execution API for fetching and uploading execution payloads
* batched version of the above (ie send 1024 payloads together)
* The exact sequencing of query bn/newPayload/fcU can be further simplified and streamlined to avoid unnecessary latency spikes
* For finalized blocks, we can ask the EL to perform reduced verification - in particular, we can potentially delay state root execution until we're "close" to the network head, for some definition of "close".

The above aligns with a vision to reduce the _overall_ complexity of ethereum node by removing duplicated functionality - ie network propagation of blocks which necessarily must exist in the CL due to it being the primary distribution point of current block information, but no longer is needed on the EL side.

### Meeting notes

* https://hackmd.io/@nixorokish/ELCLsync

---

**EDIT (Toni):**
For summary, with top up sync we can deprecate the eth block-distribution messages (`NewBlockHashes`, `NewBlock`, `GetBlockHeaders`/`BlockHeaders`, `GetBlockBodies`/`BlockBodies`) since the CL becomes the canonical block source via newPayload while the mempool path (`Transactions`, `NewPooledTransactionHashes`, `GetPooledTransactions`/`PooledTransactions`) stays the same. `GetReceipts`/`Receipts` are TBD (not sure what best to do but might depend on node type).

State sync using snap stays unchanged using snap/v1 or snap/v2 (account ranges, storage ranges, bytecodes, trie nodes and/or BALs), so a fresh sync looks like an EL snap sync followed by CL-driven top-up of blocks from pivot+1 onward, and a deep reorg is handled the same way (re-pivot, mark nodes as "dirty", re-top-up - at least for snap/2).

Two open questions:

1) will archive nodes keep using GetReceipts/Receipts on devp2p or re-execute top-up-fed blocks locally to regenerate receipts (bandwidth vs CPU).

2) with snap/v2 + BAL fast-forward path (EL applies BAL state diff without re-executing) is fine but receipts wouldn't be generated if the block isn't executed.

3) snap/2 relies on getting the BALs over devp2p, not only for the final catching-up-to-head stage, but also when advancing the pivot. So, should we keep the `GetBlockAccessLists` message?