# Ethereum syncing vs gossiping

Currently Ethereum blocks are gossiped on the consensus layer (CL) peer to peer network. These blocks are encoded as objects of the type [SignedBeaconBlock](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#signedbeaconblock). Within them, we find an [ExecutionPayload](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md#executionpayload). This execution payload is validated in the execution layer (EL) and is otherwise useless for the cl.

The high level flow diagram on how Ethereum nodes sync a block received over gossip is as follows:
- Receive a full block on the CL P2P.
- Validate the consensus part.
- Send the execution payload to the EL for validation
- The CL saves the full block **without** the execution payload.
- The EL saves the execution payload.

This leads to the following problem when syncing a node from scratch. Typically the CL will bootstrap syncing from a finalized checkpoint. It will send that blockhash to the EL to sync on the EL P2P network up to that checkpoint. At the same time, the CL requests all the full blocks from peers. This raises two problems:
1. The full payload cannot be verified (the EL is still syncing, this is called *optimistic sync*)
2. The full block is not held by any node, a newly syncing node requests them and peers **assemble** the full nodes

## Optimistic syncing

The node that is syncing from a checkpoint, receives batches of blocks. The CL performs the full consensus validation, but the EL cannot execute the transactions just yet. The following are all the checks that are performed on the execution payload
- The EL checks that the blockhash is correctly computed
- The CL checks that the parenthash is the blockhash of the par
- The CL checks that the withdrawals in the payload agree with the expected ones in the beacon state.

The EL saves the blocks until it can actually execute them later on when it catches up. The question we raise is:
:::info
Can we sync a node by requesting only blinded blocks, that is blocks that instead of the execution payload, have an identifying hash.
:::

We make the following assumption:

:::success
Everything that is needed by the CL to process the block is in the non-blinded part
:::

This means for example that some information would have to be kept twice, like withdrawals, blockhash and parent blockhash. These should be part of the execution payload. How would sync work in this scenario:

- CL requests ranges of blinded blocks.
- These blocks only contain a hash for the execution payload, but the full withdrawals, the blockhash and the parent blockhash.
- The CL sends the blockhash to the EL to get the block on their own P2P network
- The CL processes withdrawals, it can be certain that the withdrawals in the execution payload will match with the withdrawals that it has because the payload hash is committed as part of the block root, which was attested for. We cannot finalize a block with withdrawals in the payload being different than those in the blinded block.
- The CL checks that the parent blockhash corresponds to the blockhash included in the parent block. The CL knows that the blockhash is also committed in the payload root.

## Gossiping

Gossiping continues as-is: that is, blocks are gossiped in the CL layer in full, attesters can only attest to fully validated blocks, so that a blockroot that commits to a payload root gives cryptoeconomic security that the blinded block on the CL has matching withdrawals in the EL payload.