status-im/eth2.0-specs
2
0
Fork 0
mirror of https://github.com/status-im/eth2.0-specs.git synced 2025-02-02 13:53:27 +00:00
Code Issues Projects Releases Wiki Activity

Update p2p-networking

Browse Source
This commit is contained in:
Paul Hauner 2022-01-12 16:18:53 +11:00
parent 55d92cee34
commit 1228e01883
No known key found for this signature in database
GPG Key ID: 5E2CFF9B75FA63DF
2 changed files with 17 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
specs/merge/p2p-interface.md
View File

@ -85,6 +85,10 @@ The *type* of the payload of this topic changes to the (modified) `SignedBeaconB
Specifically, this type changes with the addition of `execution_payload` to the inner `BeaconBlockBody`.
See the Merge [state transition document](./beacon-chain.md#beaconblockbody) for further details.
Blocks with execution enabled will be permitted to propagate regardless of the
validity of the execution payload. This prevents network segregation between
[optimistic](/sync/optimistic.md) and non-optimistic nodes.
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`.
@ -92,6 +96,13 @@ Alias `block = signed_beacon_block.message`, `execution_payload = block.body.exe
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] The block's parent (defined by `block.parent_root`) passes all
validation, excluding verification of the `block.body.execution_payload`.
- [IGNORE] The block's parent (defined by `block.parent_root`) passes all
validation, including verification of the `block.body.execution_payload`.
The following gossip validation from prior specifications MUST NOT be applied if the execution is enabled for the block -- i.e. `is_execution_enabled(state, block.body)`:
- [REJECT] The block's parent (defined by `block.parent_root`) passes validation.
### Transitioning the gossip
@ -100,6 +111,12 @@ details on how to handle transitioning gossip topics for the Merge.
## The Req/Resp domain
Non-faulty, [optimistic](/sync/optimistic.md) nodes may send blocks which
result in an INVALID response from an execution engine. To prevent network
segregation between optimistic and non-optimistic nodes, transmission of an
INVALID payload via the Req/Resp domain SHOULD NOT cause a node to be
down-scored or disconnected.
### Messages
#### BeaconBlocksByRange v2

46
sync/optimistic.md
View File

@ -218,52 +218,6 @@ An optimistic validator MUST NOT participate in sync committees (i.e., sign acro
`DOMAIN_SYNC_COMMITTEE`, `DOMAIN_SYNC_COMMITTEE_SELECTION_PROOF` or
`DOMAIN_CONTRIBUTION_AND_PROOF` domains).
## P2P Networking
### The Gossip Domain (gossipsub)
#### `beacon_block`
An optimistic validator MAY subscribe to the `beacon_block` topic. Propagation
validation conditions are modified as such:
Do not apply the existing condition:
- [REJECT] The block's parent (defined by `block.parent_root`) passes validation.
Instead, apply the new condition:
- [REJECT] The block's parent (defined by `block.parent_root`) passes all
validation, excluding verification of the `block.body.execution_payload`.
- [IGNORE] The block's parent (defined by `block.parent_root`) passes all
validation, including verification of the `block.body.execution_payload`.
The effect of these modifications is that invalid payloads may be propagated
across the network, but only when contained inside a block that is valid in *all
other aspects*.
#### Other Topics
An optimistic node MUST NOT subscribe to the following topics:
- `beacon_aggregate_and_proof`
- `voluntary_exit`
- `proposer_slashing`
- `attester_slashing`
- `beacon_attestation_{subnet_id}`
- `sync_committee_contribution_and_proof`
- `sync_committee_{subnet_id}`
Once the node ceases to be optimistic, it MAY re-subscribe to the
aforementioned topics.
### The Req/Resp Domain
Non-faulty, optimistic nodes may send blocks which result in an INVALID
response from an execution engine. To prevent network segregation between
optimistic and non-optimistic nodes, transmission of an INVALID payload SHOULD
NOT cause a node to be down-scored or disconnected.
## Ethereum Beacon APIs
Consensus engines which provide an implementation of the [Ethereum Beacon