7.8 KiB
The Merge -- Networking
This document contains the networking specification for the Merge.
The specification of these changes continues in the same format as the network specifications of previous upgrades, and assumes them as pre-requisite. This document should be viewed as additive to the documents from Phase 0 and from Altair and will be referred to as the "Phase 0 document" and "Altair document" respectively, hereafter. Readers should understand the Phase 0 and Altair documents and use them as a basis to understand the changes outlined in this document.
Table of contents
Warning
This document is currently illustrative for early Merge testnets and some parts are subject to change. Refer to the note in the validator guide for further details.
Modifications in the Merge
Configuration
This section outlines modifications constants that are used in this spec.
| Name | Value | Description |
|---|---|---|
GOSSIP_MAX_SIZE_MERGE |
10 * 2**20 (= 10485760, 10 MiB) |
The maximum allowed size of uncompressed gossip messages starting at the Merge upgrade |
The gossip domain: gossipsub
Some gossip meshes are upgraded in the Merge to support upgraded types.
Topics and messages
Topics follow the same specification as in prior upgrades. All topics remain stable except the beacon block topic which is updated with the modified type.
The specification around the creation, validation, and dissemination of messages has not changed from the Phase 0 and Altair documents unless explicitly noted here.
Starting at the Merge upgrade, each gossipsub message
has a maximum size of GOSSIP_MAX_SIZE_MERGE.
Clients MUST reject (fail validation) messages that are over this size limit.
Likewise, clients MUST NOT emit or propagate messages larger than this limit.
The derivation of the message-id remains stable.
The new topics along with the type of the data field of a gossipsub message are given in this table:
| Name | Message Type |
|---|---|
beacon_block |
SignedBeaconBlock (modified) |
Note that the ForkDigestValue path segment of the topic separates the old and the new beacon_block topics.
Global topics
The Merge changes the type of the global beacon block topic.
beacon_block
The type of the payload of this topic changes to the (modified) SignedBeaconBlock found in the Merge.
Specifically, this type changes with the addition of execution_payload to the inner BeaconBlockBody.
See the Merge state transition document for further details.
In addition to the gossip validations for this topic from prior specifications,
the following validations MUST pass before forwarding the signed_beacon_block on the network.
Alias block = signed_beacon_block.message, execution_payload = block.body.execution_payload.
- If the execution is enabled for the block -- i.e.
is_execution_enabled(state, block.body)then validate the following:- [REJECT] The block's execution payload timestamp is correct with respect to the slot
-- i.e.
execution_payload.timestamp == compute_timestamp_at_slot(state, block.slot). - [REJECT] Gas used is less than the gas limit --
i.e.
execution_payload.gas_used <= execution_payload.gas_limit. - [REJECT] The execution payload transaction list data is within expected size limits, the data MUST NOT be larger than the SSZ list-limit.
- [REJECT] The block's execution payload timestamp is correct with respect to the slot
-- i.e.
Note: Additional gossip validations (see block "data validity" conditions) that rely more heavily on execution-layer state and logic are currently under consideration.
Transitioning the gossip
See gossip transition details found in the Altair document for details on how to handle transitioning gossip topics for the Merge.
The Req/Resp domain
Messages
BeaconBlocksByRange v2
Protocol ID: /eth2/beacon_chain/req/beacon_blocks_by_range/2/
Request and Response remain unchanged.
The Merge fork-digest is introduced to the context enum to specify the Merge block type.
Per context = compute_fork_digest(fork_version, genesis_validators_root):
fork_version |
Chunk SSZ type |
|---|---|
GENESIS_FORK_VERSION |
phase0.SignedBeaconBlock |
ALTAIR_FORK_VERSION |
altair.SignedBeaconBlock |
MERGE_FORK_VERSION |
merge.SignedBeaconBlock |
BeaconBlocksByRoot v2
Protocol ID: /eth2/beacon_chain/req/beacon_blocks_by_root/2/
Request and Response remain unchanged.
The Merge fork-digest is introduced to the context enum to specify the Merge block type.
Per context = compute_fork_digest(fork_version, genesis_validators_root):
fork_version |
Chunk SSZ type |
|---|---|
GENESIS_FORK_VERSION |
phase0.SignedBeaconBlock |
ALTAIR_FORK_VERSION |
altair.SignedBeaconBlock |
MERGE_FORK_VERSION |
merge.SignedBeaconBlock |
Design decision rationale
Gossipsub
Why was the max gossip message size increased at the Merge?
With the addition of ExecutionPayload to BeaconBlocks, there is a dynamic
field -- transactions -- which can validly exceed the GOSSIP_MAX_SIZE limit (1 MiB) put in place in
place at Phase 0. At the GAS_LIMIT (~30M) currently seen on mainnet in 2021, a single transaction
filled entirely with data at a cost of 16 gas per byte can create a valid
ExecutionPayload of ~2 MiB. Thus we need a size limit to at least account for
current mainnet conditions.
Geth currently has a max gossip message size of 10 MiB.
To support backward compatibility with this previously defined network limit,
we adopt GOSSIP_MAX_SIZE_MERGE of 10 MiB for maximum gossip sizes at the
point of the Merge and beyond. Note, that clients SHOULD still reject objects
that exceed their maximum theoretical bounds which in most cases is less than GOSSIP_MAX_SIZE_MERGE.
Note, that due to additional size induced by the BeaconBlock contents (e.g.
proposer signature, operations lists, etc) this does reduce the
theoretical max valid ExecutionPayload (and transactions list) size as
slightly lower than 10 MiB. Considering that BeaconBlock max size is on the
order of 128 KiB in the worst case and the current gas limit (~30M) bounds max blocksize to less
than 2 MiB today, this marginal difference in theoretical bounds will have zero
impact on network functionality and security.