Why is it still required to sync geth after the merge? The beacon chain is now the real Eth chain, and all that's needed should be a snapshot of the network state at the time of the merge?
The Merge – Why Geth Syncing is Still Required After the Merge
the-merge
Related Solutions
The syncing functionality of the geth light node does not currently (Nov 2022) work post-merge, because the historical execution layer blocks are no longer sufficient to light-verify the chain. There is an open PR to add support for standalone beacon chain light syncing in geth here: https://github.com/ethereum/go-ethereum/pull/25901
This is only the first step to restoring the expected functionality of the geth light node. I expect it won't be until early 2023 when the expected functionality is restored.
The Merge was the implementation of the Bellatrix consensus (layer) specs, the Paris execution (layer) specs, and the Engine API.
Bellatrix: https://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix
Paris: https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md
- Paris mainly consists of EIP-3675.
The interaction between the consensus layer and execution layer is specified by the Engine API: https://github.com/ethereum/execution-apis/tree/main/src/engine
Q1
The execution layer has blocks all the way since genesis; beacon blocks only started having transactions in Bellatrix. So each layer can be considered to be a "chain".
On the question of transactions duplicated since the Merge, from the specs alone, EIP-3675 does not specify any removal or optimizations of transactions at the execution layer. As the rationale of EIP-3675 states: "This EIP was designed to minimize the complexity of hot-swapping the live consensus of the Ethereum network. Both the safety of the operation and time to production were taken into consideration." So the answer to Q1 is it depends on the implementation of the execution client. In practice, transactions are probably duplicated.
Q2
Yes, the Bellatrix spec states the extensions and additions. The BeaconBlockBody
and BeaconState
are extended with ExecutionPayload
and ExecutionPayloadHeader
respectively.
Q3
The consensus layer (CL) and execution layer (EL) largely operate as they did before the Merge. For example, the EL manages the mempool and gathering up transactions for a block, and it syncs from genesis.
Engine API test vectors for The Merge based on a discussion of the Engine API is helpful to see how the layers interact. The CL calls engine_forkchoiceUpdatedV1
so that the EL prepares a payload. The CL calls engine_getPayloadV1
to get a payload. The CL then tells the EL to execute the payload by calling engine_newPayloadV1
. Assuming that the payload is valid, the CL then tells the EL that the payload is the head of the chain by calling engine_forkchoiceUpdatedV1
.
Best Answer
The Ethereum state is derived from both the consensus layer (beacon chain) and the execution layer.
From Which client holds the state of the chain? No single client holds the state of the chain.
For example, consensus layer rewards accrue in the validator's balance on the beacon chain, while transaction tips accrue in the fee recipient address on the execution layer.
Additional information that might help: Are transactions duplicated in both beacon chain and execution layer?