Gloas -- Networking¶
Note: This document is a work-in-progress for researchers and implementers.
- Introduction
- Modification in Gloas
- Configuration
- Containers
- Helpers
- The gossip domain: gossipsub
- The Req/Resp domain
Introduction¶
This document contains the consensus-layer networking specifications for Gloas.
The specification of these changes continues in the same format as the network specifications of previous upgrades, and assumes them as pre-requisite.
Modification in Gloas¶
Configuration¶
| Name | Value | Description |
|---|---|---|
MAX_REQUEST_PAYLOADS |
2**7 (= 128) |
Maximum number of execution payload envelopes in a single request |
Containers¶
Modified DataColumnSidecar¶
Note: The signed_block_header, kzg_commitments, and
kzg_commitments_inclusion_proof fields have been removed from
DataColumnSidecar in Gloas as header and inclusion proof verifications are no
longer required in Gloas. The KZG commitments are now located at
block.body.signed_execution_payload_bid.message.blob_kzg_commitments where
block is the BeaconBlock associated with beacon_block_root.
New ProposerPreferences¶
[New in Gloas:EIP7732]
New SignedProposerPreferences¶
[New in Gloas:EIP7732]
Helpers¶
Modified compute_fork_version¶
Modified verify_data_column_sidecar_kzg_proofs¶
Modified verify_data_column_sidecar¶
The gossip domain: gossipsub¶
Some gossip meshes are upgraded in Gloas to support upgraded types.
Topics and messages¶
Topics follow the same specification as in prior upgrades.
The beacon_block topic is updated to support the modified type
| Name | Message Type |
|---|---|
beacon_block |
SignedBeaconBlock |
The new topics along with the type of the data field of a gossipsub message
are given in this table:
| Name | Message Type |
|---|---|
execution_payload_bid |
SignedExecutionPayloadBid |
execution_payload |
SignedExecutionPayloadEnvelope |
payload_attestation_message |
PayloadAttestationMessage |
proposer_preferences |
SignedProposerPreferences |
Global topics¶
Gloas introduces new global topics for execution bid, execution payload and payload attestation.
beacon_aggregate_and_proof¶
Let block be the beacon block corresponding to
aggregate.data.beacon_block_root.
The following validations are added:
- [REJECT]
aggregate.data.index < 2. - [REJECT]
aggregate.data.index == 0ifblock.slot == aggregate.data.slot.
The following validations are removed:
- [REJECT]
aggregate.data.index == 0.
beacon_block¶
[Modified in Gloas:EIP7732]
The type of the payload of this topic changes to the (modified)
SignedBeaconBlock found in the beacon-chain changes.
There are no new validations for this topic. However, all validations with
regards to the ExecutionPayload are removed:
- [REJECT] The length of KZG commitments is less than or equal to the
limitation defined in the consensus layer -- i.e. validate that
len(signed_beacon_block.message.body.blob_kzg_commitments) <= get_blob_parameters(get_current_epoch(state)).max_blobs_per_block - [REJECT] The block's execution payload timestamp is correct with respect to
the slot -- i.e.
execution_payload.timestamp == compute_time_at_slot(state, block.slot). - If
execution_payloadverification of block's parent by an execution node is not complete: - [REJECT] The block's parent (defined by
block.parent_root) passes all validation (excluding execution node verification of theblock.body.execution_payload). - otherwise:
- [IGNORE] The block's parent (defined by
block.parent_root) passes all validation (including execution node verification of theblock.body.execution_payload).
And instead the following validations are set in place with the alias
bid = signed_execution_payload_bid.message:
- [REJECT] The length of KZG commitments is less than or equal to the
limitation defined in the consensus layer -- i.e. validate that
len(bid.blob_kzg_commitments) <= get_blob_parameters(get_current_epoch(state)).max_blobs_per_block - If
execution_payloadverification of block's execution payload parent by an execution node is complete: - [REJECT] The block's execution payload parent (defined by
bid.parent_block_hash) passes all validation. - [REJECT] The bid's parent (defined by
bid.parent_block_root) equals the block's parent (defined byblock.parent_root).
execution_payload¶
This topic is used to propagate execution payload messages as
SignedExecutionPayloadEnvelope.
The following validations MUST pass before forwarding the
signed_execution_payload_envelope on the network, assuming the alias
envelope = signed_execution_payload_envelope.message,
payload = envelope.payload:
- [IGNORE] The envelope's block root
envelope.block_roothas been seen (via gossip or non-gossip sources) (a client MAY queue payload for processing once the block is retrieved). - [IGNORE] The node has not seen another valid
SignedExecutionPayloadEnvelopefor this block root from this builder. - [IGNORE] The envelope is from a slot greater than or equal to the latest
finalized slot -- i.e. validate that
envelope.slot >= compute_start_slot_at_epoch(store.finalized_checkpoint.epoch)
Let block be the block with envelope.beacon_block_root. Let bid alias
block.body.signed_execution_payload_bid.message (notice that this can be
obtained from the state.latest_execution_payload_bid)
- [REJECT]
blockpasses validation. - [REJECT]
block.slotequalsenvelope.slot. - [REJECT]
envelope.builder_index == bid.builder_index - [REJECT]
payload.block_hash == bid.block_hash - [REJECT]
signed_execution_payload_envelope.signatureis valid with respect to the builder's public key.
payload_attestation_message¶
This topic is used to propagate signed payload attestation message.
The following validations MUST pass before forwarding the
payload_attestation_message on the network, assuming the alias
data = payload_attestation_message.data:
- [IGNORE] The message's slot is for the current slot (with a
MAXIMUM_GOSSIP_CLOCK_DISPARITYallowance), i.e.data.slot == current_slot. - [IGNORE] The
payload_attestation_messageis the first valid message received from the validator with indexpayload_attestation_message.validator_index. - [IGNORE] The message's block
data.beacon_block_roothas been seen (via gossip or non-gossip sources) (a client MAY queue attestation for processing once the block is retrieved. Note a client might want to request payload after). - [REJECT] The message's block
data.beacon_block_rootpasses validation. - [REJECT] The message's validator index is within the payload committee in
get_ptc(state, data.slot). Thestateis the head state corresponding to processing the block up to the current slot as determined by the fork choice. - [REJECT]
payload_attestation_message.signatureis valid with respect to the validator's public key.
execution_payload_bid¶
This topic is used to propagate signed bids as SignedExecutionPayloadBid.
The following validations MUST pass before forwarding the
signed_execution_payload_bid on the network, assuming the alias
bid = signed_execution_payload_bid.message:
- [IGNORE]
bid.slotis the current slot or the next slot. - [IGNORE] the
SignedProposerPreferenceswherepreferences.proposal_slotis equal tobid.slothas been seen. - [REJECT]
bid.builder_indexis a valid/active builder index -- i.e.is_active_builder(state, bid.builder_index)returnsTrue. - [REJECT]
bid.execution_paymentis zero. - [REJECT]
bid.fee_recipientmatches thefee_recipientfrom the proposer'sSignedProposerPreferencesassociated withbid.slot. - [REJECT]
bid.gas_limitmatches thegas_limitfrom the proposer'sSignedProposerPreferencesassociated withbid.slot. - [IGNORE] this is the first signed bid seen with a valid signature from the given builder for this slot.
- [IGNORE] this bid is the highest value bid seen for the corresponding slot and the given parent block hash.
- [IGNORE]
bid.valueis less or equal than the builder's excess balance -- i.e.can_builder_cover_bid(state, builder_index, amount)returnsTrue. - [IGNORE]
bid.parent_block_hashis the block hash of a known execution payload in fork choice. - [IGNORE]
bid.parent_block_rootis the hash tree root of a known beacon block in fork choice. - [REJECT]
signed_execution_payload_bid.signatureis valid with respect to thebid.builder_index.
Note: Implementations SHOULD include DoS prevention measures to mitigate spam from malicious builders submitting numerous bids with minimal value increments. Possible strategies include: (1) only forwarding bids that exceed the current highest bid by a minimum threshold, or (2) forwarding only the highest observed bid at regular time intervals.
proposer_preferences¶
[New in Gloas:EIP7732]
This topic is used to propagate signed proposer preferences as
SignedProposerPreferences. These messages allow validators to communicate
their preferred fee_recipient and gas_limit to builders.
The following validations MUST pass before forwarding the
signed_proposer_preferences on the network, assuming the alias
preferences = signed_proposer_preferences.message:
- [IGNORE]
preferences.proposal_slotis in the next epoch -- i.e.compute_epoch_at_slot(preferences.proposal_slot) == get_current_epoch(state) + 1. - [REJECT]
preferences.validator_indexis present at the correct slot in the next epoch's portion ofstate.proposer_lookahead-- i.e.is_valid_proposal_slot(state, preferences)returnsTrue. - [IGNORE] The
signed_proposer_preferencesis the first valid message received from the validator with indexpreferences.validator_indexand the given slotpreferences.slot. - [REJECT]
signed_proposer_preferences.signatureis valid with respect to the validator's public key.
Blob subnets¶
data_column_sidecar_{subnet_id}¶
[Modified in Gloas:EIP7732]
The following validations MUST pass before forwarding the
sidecar: DataColumnSidecar on the network, assuming the alias
bid = block.body.signed_execution_payload_bid.message where block is the
BeaconBlock associated with sidecar.beacon_block_root:
- [IGNORE] A valid block for the sidecar's
slothas been seen (via gossip or non-gossip sources). If not yet seen, a client MUST queue the sidecar for deferred validation and possible processing once the block is received or retrieved. - [REJECT] The sidecar's
slotmatches the slot of the block with rootbeacon_block_root. - [REJECT] The sidecar is valid as verified by
verify_data_column_sidecar(sidecar, bid.blob_kzg_commitments). - [REJECT] The sidecar is for the correct subnet -- i.e.
compute_subnet_for_data_column_sidecar(sidecar.index) == subnet_id. - [REJECT] The sidecar's column data is valid as verified by
verify_data_column_sidecar_kzg_proofs(sidecar, bid.blob_kzg_commitments). - [IGNORE] The sidecar is the first sidecar for the tuple
(sidecar.beacon_block_root, sidecar.index)with valid kzg proof.
Note: If the sidecar fails deferred validation, its forwarding peers MUST be downscored retroactively. If validation succeeds, the client MUST re-broadcast the sidecar.
Attestation subnets¶
beacon_attestation_{subnet_id}¶
Let block be the beacon block corresponding to
attestation.data.beacon_block_root.
The following validations are added:
- [REJECT]
attestation.data.index < 2. - [REJECT]
attestation.data.index == 0ifblock.slot == attestation.data.slot.
The following validations are removed:
- [REJECT]
attestation.data.index == 0.
The Req/Resp domain¶
Messages¶
BeaconBlocksByRange v2¶
Protocol ID: /eth2/beacon_chain/req/beacon_blocks_by_range/2/
fork_version |
Chunk SSZ type |
|---|---|
GENESIS_FORK_VERSION |
phase0.SignedBeaconBlock |
ALTAIR_FORK_VERSION |
altair.SignedBeaconBlock |
BELLATRIX_FORK_VERSION |
bellatrix.SignedBeaconBlock |
CAPELLA_FORK_VERSION |
capella.SignedBeaconBlock |
DENEB_FORK_VERSION |
deneb.SignedBeaconBlock |
ELECTRA_FORK_VERSION |
electra.SignedBeaconBlock |
FULU_FORK_VERSION |
fulu.SignedBeaconBlock |
GLOAS_FORK_VERSION |
gloas.SignedBeaconBlock |
BeaconBlocksByRoot v2¶
Protocol ID: /eth2/beacon_chain/req/beacon_blocks_by_root/2/
fork_version |
Chunk SSZ type |
|---|---|
GENESIS_FORK_VERSION |
phase0.SignedBeaconBlock |
ALTAIR_FORK_VERSION |
altair.SignedBeaconBlock |
BELLATRIX_FORK_VERSION |
bellatrix.SignedBeaconBlock |
CAPELLA_FORK_VERSION |
capella.SignedBeaconBlock |
DENEB_FORK_VERSION |
deneb.SignedBeaconBlock |
ELECTRA_FORK_VERSION |
electra.SignedBeaconBlock |
FULU_FORK_VERSION |
fulu.SignedBeaconBlock |
GLOAS_FORK_VERSION |
gloas.SignedBeaconBlock |
ExecutionPayloadEnvelopesByRange v1¶
Protocol ID:
/eth2/beacon_chain/req/execution_payload_envelopes_by_range/1/
Request Content:
Response Content:
Specifications of req\response methods are equivalent to BeaconBlocksByRange v2, with the only difference being the response content type.
For each successful response_chunk, the ForkDigest context epoch is
determined by compute_epoch_at_slot(beacon_block.slot) based on the
beacon_block referred to by
signed_execution_payload_envelope.message.beacon_block_root.
Per fork_version = compute_fork_version(epoch):
fork_version |
Chunk SSZ type |
|---|---|
GLOAS_FORK_VERSION |
gloas.SignedExecutionPayloadEnvelope |
ExecutionPayloadEnvelopesByRoot v1¶
Protocol ID: /eth2/beacon_chain/req/execution_payload_envelopes_by_root/1/
For each successful response_chunk, the ForkDigest context epoch is
determined by compute_epoch_at_slot(beacon_block.slot) based on the
beacon_block referred to by
signed_execution_payload_envelope.message.beacon_block_root.
Per fork_version = compute_fork_version(epoch):
fork_version |
Chunk SSZ type |
|---|---|
GLOAS_FORK_VERSION |
gloas.SignedExecutionPayloadEnvelope |
Request Content:
Response Content:
Requests execution payload envelopes by
signed_execution_payload_envelope.message.block_root. The response is a list
of SignedExecutionPayloadEnvelope whose length is less than or equal to the
number of requested execution payload envelopes. It may be less in the case that
the responding peer is missing payload envelopes.
No more than MAX_REQUEST_PAYLOADS may be requested at a time.
ExecutionPayloadEnvelopesByRoot is primarily used to recover recent execution payload envelopes (e.g. when receiving a payload attestation with revealed status as true but never received a payload).
The request MUST be encoded as an SSZ-field.
The response MUST consist of zero or more response_chunk. Each successful
response_chunk MUST contain a single SignedExecutionPayloadEnvelope payload.
Clients MUST support requesting payload envelopes since the latest finalized epoch.
Clients MUST respond with at least one payload envelope, if they have it. Clients MAY limit the number of payload envelopes in the response.