2

What exactly is the content of blocks on the beacon chain? partially answers the question but still not complete to me.

I understand that since the merge, execution layer info are in beacon chain.

  1. Does the execution layer still corresponds to another "chain" then or are the transactions only written in beacon chain ?

  2. Does that mean that beacon chain block size has increased since the merge (since they bear eth1 info)

  3. When we install a node with geth+prysm, both are syncing. But if prysm is downloading data about consensus AND execution layer, what is geth downloading ?

I've been through the doc and so on but I can't understand what is stored where for exec layer info (between execution layer and beacon chain).

Thanks in advance for your time, you already are amazing <3

Improve this question

1 Answer 1

Reset to default
2

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

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.

Improve this answer
2
  • Thanks a lot for the comprehensive answer ! If I understand well the process: - EL clients share new TX - When the proposer has to build a block, its CL asks the EL to forge it, based on the past TX in mempool. This block is not sent to anyone, only sent from EL to CL of the proposer - The proposer then wraps this EL block in a CL block - The CL block is shared - Everyone receives the block via their CL, CL passes the wrapped EL block to their EL and asks it if the EL block is correct - If accepted by EL, the CL accepts the block by voting for it Does this make sense ?
    – Makubu
    Oct 13, 2022 at 9:36
  • That sounds very good to me! (I do not know enough to say that what you wrote is perfect. In case you get more information, you can also add your own answer.)
    – eth ♦
    Oct 15, 2022 at 5:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.