status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #3334 from ethereum/docs-toc 

Fix p2p-interface.md ToC
This commit is contained in:
Danny Ryan 2023-04-19 09:50:32 -06:00 committed by GitHub
parent 4a8fa9de8a 03a3e4082a
commit 6b38cd77fe
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
6 changed files with 199 additions and 266 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
docs/README.md
View File

@ -1,70 +0,0 @@
# Ethereum Proof-of-Stake Consensus Specifications
[![Join the chat at https://discord.gg/qGpsxSA](https://img.shields.io/badge/chat-on%20discord-blue.svg)](https://discord.gg/qGpsxSA) [![Join the chat at https://gitter.im/ethereum/sharding](https://badges.gitter.im/ethereum/sharding.svg)](https://gitter.im/ethereum/sharding?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
To learn more about proof-of-stake and sharding, see the [PoS documentation](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/), [sharding documentation](https://ethereum.org/en/upgrades/sharding/) and the [research compendium](https://notes.ethereum.org/s/H1PGqDhpm).
This repository hosts the current Ethereum proof-of-stake specifications. Discussions about design rationale and proposed changes can be brought up and discussed as issues. Solidified, agreed-upon changes to the spec can be made through pull requests.
## Specs
[![GitHub release](https://img.shields.io/github/v/release/ethereum/eth2.0-specs)](https://github.com/ethereum/eth2.0-specs/releases/) [![PyPI version](https://badge.fury.io/py/eth2spec.svg)](https://badge.fury.io/py/eth2spec)
Core specifications for Ethereum proof-of-stake clients can be found in [specs](specs/). These are divided into features.
Features are researched and developed in parallel, and then consolidated into sequential upgrades when ready.
### Stable Specifications
| Seq. | Code Name | Fork Epoch | Specs |
| - | - | - | - |
| 0 | **Phase0** |`0` | <ul><li>Core</li><ul><li>[The beacon chain](specs/phase0/beacon-chain.md)</li><li>[Deposit contract](specs/phase0/deposit-contract.md)</li><li>[Beacon chain fork choice](specs/phase0/fork-choice.md)</li></ul><li>Additions</li><ul><li>[Honest validator guide](specs/phase0/validator.md)</li><li>[P2P networking](specs/phase0/p2p-interface.md)</li><li>[Weak subjectivity](specs/phase0/weak-subjectivity.md)</li></ul></ul> |
| 1 | **Altair** | `74240` | <ul><li>Core</li><ul><li>[Beacon chain changes](specs/altair/beacon-chain.md)</li><li>[Altair fork](specs/altair/fork.md)</li></ul><li>Additions</li><ul><li>[Light client sync protocol](specs/altair/light-client/sync-protocol.md) ([full node](specs/altair/light-client/full-node.md), [light client](specs/altair/light-client/light-client.md), [networking](specs/altair/light-client/p2p-interface.md))</li><li>[Honest validator guide changes](specs/altair/validator.md)</li><li>[P2P networking](specs/altair/p2p-interface.md)</li></ul></ul> |
| 2 | **Bellatrix** <br/> (["The Merge"](https://ethereum.org/en/upgrades/merge/)) | `144896` | <ul><li>Core</li><ul><li>[Beacon Chain changes](specs/bellatrix/beacon-chain.md)</li><li>[Bellatrix fork](specs/bellatrix/fork.md)</li><li>[Fork choice changes](specs/bellatrix/fork-choice.md)</li></ul><li>Additions</li><ul><li>[Honest validator guide changes](specs/bellatrix/validator.md)</li><li>[P2P networking](specs/bellatrix/p2p-interface.md)</li></ul></ul> |
| 3 | **Capella** | `194048` | <ul><li>Core</li><ul><li>[Beacon chain changes](specs/capella/beacon-chain.md)</li><li>[Capella fork](specs/capella/fork.md)</li></ul><li>Additions</li><ul><li>[Light client sync protocol changes](specs/capella/light-client/sync-protocol.md) ([fork](specs/capella/light-client/fork.md), [full node](specs/capella/light-client/full-node.md), [networking](specs/capella/light-client/p2p-interface.md))</li></ul><ul><li>[Validator additions](specs/capella/validator.md)</li><li>[P2P networking](specs/capella/p2p-interface.md)</li></ul></ul> |
### In-development Specifications
| Code Name or Topic | Specs | Notes |
| - | - | - |
| Deneb (tentative) | <ul><li>Core</li><ul><li>[Beacon Chain changes](specs/deneb/beacon-chain.md)</li><li>[Deneb fork](specs/deneb/fork.md)</li><li>[Polynomial commitments](specs/deneb/polynomial-commitments.md)</li><li>[Fork choice changes](specs/deneb/fork-choice.md)</li></ul><li>Additions</li><ul><li>[Light client sync protocol changes](specs/deneb/light-client/sync-protocol.md) ([fork](specs/deneb/light-client/fork.md), [full node](specs/deneb/light-client/full-node.md), [networking](specs/deneb/light-client/p2p-interface.md))</li></ul><ul><li>[Honest validator guide changes](specs/deneb/validator.md)</li><li>[P2P networking](specs/deneb/p2p-interface.md)</li></ul></ul> |
| Sharding (outdated) | <ul><li>Core</li><ul><li>[Beacon Chain changes](specs/_features/sharding/beacon-chain.md)</li></ul><li>Additions</li><ul><li>[P2P networking](specs/_features/sharding/p2p-interface.md)</li></ul></ul> |
| Custody Game (outdated) | <ul><li>Core</li><ul><li>[Beacon Chain changes](specs/_features/custody_game/beacon-chain.md)</li></ul><li>Additions</li><ul><li>[Honest validator guide changes](specs/_features/custody_game/validator.md)</li></ul></ul> | Dependent on sharding |
| Data Availability Sampling (outdated) | <ul><li>Core</li><ul><li>[Core types and functions](specs/_features/das/das-core.md)</li><li>[Fork choice changes](specs/_features/das/fork-choice.md)</li></ul><li>Additions</li><ul><li>[P2P Networking](specs/_features/das/p2p-interface.md)</li><li>[Sampling process](specs/_features/das/sampling.md)</li></ul></ul> | <ul><li> Dependent on sharding</li><li>[Technical explainer](https://hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/B1YJPGkpD)</li></ul> |
| EIP-6110 | <ul><li>Core</li><ul><li>[Beacon Chain changes](specs/_features/eip6110//beacon-chain.md)</li><li>[EIP-6110 fork](specs/_features/eip6110/fork.md)</li></ul><li>Additions</li><ul><li>[Honest validator guide changes](specs/_features/eip6110/validator.md)</li></ul></ul> |
### Accompanying documents can be found in [specs](specs) and include:
* [SimpleSerialize (SSZ) spec](ssz/simple-serialize.md)
* [Merkle proof formats](ssz/merkle-proofs.md)
* [General test format](tests/formats/README.md)
## Additional specifications for client implementers
Additional specifications and standards outside of requisite client functionality can be found in the following repos:
* [Beacon APIs](https://github.com/ethereum/beacon-apis)
* [Beacon Metrics](https://github.com/ethereum/beacon-metrics/)
## Design goals
The following are the broad design goals for the Ethereum proof-of-stake consensus specifications:
* to minimize complexity, even at the cost of some losses in efficiency
* to remain live through major network partitions and when very large portions of nodes go offline
* to select all components such that they are either quantum secure or can be easily swapped out for quantum secure counterparts when available
* to utilize crypto and design techniques that allow for a large participation of validators in total and per unit time
* to allow for a typical consumer laptop with `O(C)` resources to process/validate `O(1)` shards (including any system level validation such as the beacon chain)
## Useful external resources
* [Design Rationale](https://notes.ethereum.org/s/rkhCgQteN#)
* [Phase 0 Onboarding Document](https://notes.ethereum.org/s/Bkn3zpwxB)
* [Combining GHOST and Casper paper](https://arxiv.org/abs/2003.03052)
## For spec contributors
Documentation on the different components used during spec writing can be found here:
* [YAML Test Generators](tests/generators/README.md)
* [Executable Python Spec, with Py-tests](tests/core/pyspec/README.md)
## Consensus spec tests
Conformance tests built from the executable python spec are available in the [Ethereum Proof-of-Stake Consensus Spec Tests](https://github.com/ethereum/consensus-spec-tests) repo. Compressed tarballs are available in [releases](https://github.com/ethereum/consensus-spec-tests/releases).

42
specs/altair/p2p-interface.md
View File

@ -13,7 +13,7 @@ Altair adds new messages, topics and data to the Req-Resp, Gossip and Discovery
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
- [Warning](#warning)
- [Warning](#warning)
- [Modifications in Altair](#modifications-in-altair)
- [MetaData](#metadata)
- [The gossip domain: gossipsub](#the-gossip-domain-gossipsub)
@ -43,9 +43,9 @@ Altair adds new messages, topics and data to the Req-Resp, Gossip and Discovery
This document is currently illustrative for early Altair testnets and some parts are subject to change.
Refer to the note in the [validator guide](./validator.md) for further details.
# Modifications in Altair
## Modifications in Altair
## MetaData
### MetaData
The `MetaData` stored locally by clients is updated with an additional field to communicate the sync committee subnet subscriptions:
@ -62,12 +62,12 @@ Where
- `seq_number` and `attnets` have the same meaning defined in the Phase 0 document.
- `syncnets` is a `Bitvector` representing the node's sync committee subnet subscriptions. This field should mirror the data in the node's ENR as outlined in the [validator guide](./validator.md#sync-committee-subnet-stability).
## The gossip domain: gossipsub
### The gossip domain: gossipsub
Gossip meshes are added in Altair to support the consensus activities of the sync committees.
Validators use an aggregation scheme to balance the processing and networking load across all of the relevant actors.
### Topics and messages
#### Topics and messages
Topics follow the same specification as in the Phase 0 document.
New topics are added in Altair to support the sync committees and the beacon block topic is updated with the modified type.
@ -103,11 +103,11 @@ Definitions of these new types can be found in the [Altair validator guide](./va
Note that the `ForkDigestValue` path segment of the topic separates the old and the new `beacon_block` topics.
#### Global topics
##### Global topics
Altair changes the type of the global beacon block topic and adds one global topic to propagate partially aggregated sync committee messages to all potential proposers of beacon blocks.
##### `beacon_block`
###### `beacon_block`
The existing specification for this topic does not change from the Phase 0 document,
but the type of the payload does change to the (modified) `SignedBeaconBlock`.
@ -115,7 +115,7 @@ This type changes due to the inclusion of the inner `BeaconBlockBody` that is mo
See the [state transition document](./beacon-chain.md#beaconblockbody) for Altair for further details.
##### `sync_committee_contribution_and_proof`
###### `sync_committee_contribution_and_proof`
This topic is used to propagate partially aggregated sync committee messages to be included in future blocks.
@ -152,11 +152,11 @@ def get_sync_subcommittee_pubkeys(state: BeaconState, subcommittee_index: uint64
- _[REJECT]_ The aggregator signature, `signed_contribution_and_proof.signature`, is valid.
- _[REJECT]_ The aggregate signature is valid for the message `beacon_block_root` and aggregate pubkey derived from the participation info in `aggregation_bits` for the subcommittee specified by the `contribution.subcommittee_index`.
#### Sync committee subnets
##### Sync committee subnets
Sync committee subnets are used to propagate unaggregated sync committee messages to subsections of the network.
##### `sync_committee_{subnet_id}`
###### `sync_committee_{subnet_id}`
The `sync_committee_{subnet_id}` topics are used to propagate unaggregated sync committee messages to the subnet `subnet_id` to be aggregated before being gossiped to the global `sync_committee_contribution_and_proof` topic.
@ -170,7 +170,7 @@ The following validations MUST pass before forwarding the `sync_committee_messag
Note this validation is _per topic_ so that for a given `slot`, multiple messages could be forwarded with the same `validator_index` as long as the `subnet_id`s are distinct.
- _[REJECT]_ The `signature` is valid for the message `beacon_block_root` for the validator referenced by `validator_index`.
#### Sync committees and aggregation
##### Sync committees and aggregation
The aggregation scheme closely follows the design of the attestation aggregation scheme.
Sync committee messages are broadcast into "subnets" defined by a topic.
@ -182,7 +182,7 @@ Unaggregated messages (along with metadata) are sent as `SyncCommitteeMessage`s
Aggregated sync committee messages are packaged into (signed) `SyncCommitteeContribution` along with proofs and gossiped to the `sync_committee_contribution_and_proof` topic.
### Transitioning the gossip
#### Transitioning the gossip
With any fork, the fork version, and thus the `ForkDigestValue`, change.
Message types are unique per topic, and so for a smooth transition a node must temporarily subscribe to both the old and new topics.
@ -205,9 +205,9 @@ Post-fork:
E.g. an attestation on the both the old and new topic is ignored like any duplicate.
- Two epochs after the fork, pre-fork topics SHOULD be unsubscribed from. This is well after the configured `seen_ttl`.
## The Req/Resp domain
### The Req/Resp domain
### Req-Resp interaction
#### Req-Resp interaction
An additional `<context-bytes>` field is introduced to the `response_chunk` as defined in the Phase 0 document:
@ -221,7 +221,7 @@ On a non-zero `<result>` with `ErrorMessage` payload, the `<context-bytes>` is a
In Altair and later forks, `<context-bytes>` functions as a short meta-data,
defined per req-resp method, and can parametrize the payload decoder.
#### `ForkDigest`-context
##### `ForkDigest`-context
Starting with Altair, and in future forks, SSZ type definitions may change.
For this common case, we define the `ForkDigest`-context:
@ -229,9 +229,9 @@ For this common case, we define the `ForkDigest`-context:
A fixed-width 4 byte `<context-bytes>`, set to the `ForkDigest` matching the chunk:
`compute_fork_digest(fork_version, genesis_validators_root)`.
### Messages
#### Messages
#### BeaconBlocksByRange v2
##### BeaconBlocksByRange v2
**Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_range/2/`
@ -246,7 +246,7 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:
| `GENESIS_FORK_VERSION` | `phase0.SignedBeaconBlock` |
| `ALTAIR_FORK_VERSION` | `altair.SignedBeaconBlock` |
#### BeaconBlocksByRoot v2
##### BeaconBlocksByRoot v2
**Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_root/2/`
@ -261,7 +261,7 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:
| `GENESIS_FORK_VERSION` | `phase0.SignedBeaconBlock` |
| `ALTAIR_FORK_VERSION` | `altair.SignedBeaconBlock` |
#### GetMetaData v2
##### GetMetaData v2
**Protocol ID:** `/eth2/beacon_chain/req/metadata/2/`
@ -279,7 +279,7 @@ Requests the MetaData of a peer, using the new `MetaData` definition given above
that is extended from phase 0 in Altair. Other conditions for the `GetMetaData`
protocol are unchanged from the phase 0 p2p networking document.
### Transitioning from v1 to v2
#### Transitioning from v1 to v2
In advance of the fork, implementations can opt in to both run the v1 and v2 for a smooth transition.
This is non-breaking, and is recommended as soon as the fork specification is stable.
@ -291,7 +291,7 @@ The v1 method MAY be unregistered at the fork boundary.
In the event of a request on v1 for an Altair specific payload,
the responder MUST return the **InvalidRequest** response code.
## The discovery domain: discv5
### The discovery domain: discv5
The `attnets` key of the ENR is used as defined in the Phase 0 document.

64
specs/bellatrix/p2p-interface.md
View File

@ -13,23 +13,23 @@ Readers should understand the Phase 0 and Altair documents and use them as a bas
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
- [Warning](#warning)
- [Modifications in Bellatrix](#modifications-in-bellatrix)
- [Configuration](#configuration)
- [The gossip domain: gossipsub](#the-gossip-domain-gossipsub)
- [Topics and messages](#topics-and-messages)
- [Global topics](#global-topics)
- [`beacon_block`](#beacon_block)
- [Transitioning the gossip](#transitioning-the-gossip)
- [The Req/Resp domain](#the-reqresp-domain)
- [Messages](#messages)
- [BeaconBlocksByRange v2](#beaconblocksbyrange-v2)
- [BeaconBlocksByRoot v2](#beaconblocksbyroot-v2)
- [Modifications in Bellatrix](#modifications-in-bellatrix)
- [Configuration](#configuration)
- [The gossip domain: gossipsub](#the-gossip-domain-gossipsub)
- [Topics and messages](#topics-and-messages)
- [Global topics](#global-topics)
- [`beacon_block`](#beacon_block)
- [Transitioning the gossip](#transitioning-the-gossip)
- [The Req/Resp domain](#the-reqresp-domain)
- [Messages](#messages)
- [BeaconBlocksByRange v2](#beaconblocksbyrange-v2)
- [BeaconBlocksByRoot v2](#beaconblocksbyroot-v2)
- [Design decision rationale](#design-decision-rationale)
- [Gossipsub](#gossipsub)
- [Why was the max gossip message size increased at Bellatrix?](#why-was-the-max-gossip-message-size-increased-at-bellatrix)
- [Req/Resp](#reqresp)
- [Why was the max chunk response size increased at Bellatrix?](#why-was-the-max-chunk-response-size-increased-at-bellatrix)
- [Why allow invalid payloads on the P2P network?](#why-allow-invalid-payloads-on-the-p2p-network)
- [Gossipsub](#gossipsub)
- [Why was the max gossip message size increased at Bellatrix?](#why-was-the-max-gossip-message-size-increased-at-bellatrix)
- [Req/Resp](#reqresp)
- [Why was the max chunk response size increased at Bellatrix?](#why-was-the-max-chunk-response-size-increased-at-bellatrix)
- [Why allow invalid payloads on the P2P network?](#why-allow-invalid-payloads-on-the-p2p-network)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
<!-- /TOC -->
@ -39,9 +39,9 @@ Readers should understand the Phase 0 and Altair documents and use them as a bas
This document is currently illustrative for early Bellatrix testnets and some parts are subject to change.
Refer to the note in the [validator guide](./validator.md) for further details.
# Modifications in Bellatrix
## Modifications in Bellatrix
## Configuration
### Configuration
This section outlines modifications constants that are used in this spec.
@ -50,11 +50,11 @@ This section outlines modifications constants that are used in this spec.
| `GOSSIP_MAX_SIZE_BELLATRIX` | `10 * 2**20` (= 10,485,760, 10 MiB) | The maximum allowed size of uncompressed gossip messages starting at Bellatrix upgrade. |
| `MAX_CHUNK_SIZE_BELLATRIX` | `10 * 2**20` (= 10,485,760, 10 MiB) | The maximum allowed size of uncompressed req/resp chunked responses starting at Bellatrix upgrade. |
## The gossip domain: gossipsub
### The gossip domain: gossipsub
Some gossip meshes are upgraded in Bellatrix to support upgraded types.
### Topics and messages
#### 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.
@ -76,11 +76,11 @@ The new topics along with the type of the `data` field of a gossipsub message ar
Note that the `ForkDigestValue` path segment of the topic separates the old and the new `beacon_block` topics.
#### Global topics
##### Global topics
Bellatrix changes the type of the global beacon block topic.
##### `beacon_block`
###### `beacon_block`
The *type* of the payload of this topic changes to the (modified) `SignedBeaconBlock` found in Bellatrix.
Specifically, this type changes with the addition of `execution_payload` to the inner `BeaconBlockBody`.
@ -107,12 +107,12 @@ Alias `block = signed_beacon_block.message`, `execution_payload = block.body.exe
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
#### Transitioning the gossip
See gossip transition details found in the [Altair document](../altair/p2p-interface.md#transitioning-the-gossip) for
details on how to handle transitioning gossip topics.
## The Req/Resp domain
### 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
@ -122,9 +122,9 @@ down-scored or disconnected. Transmission of a block which is invalid due to
any consensus layer rules (i.e., *not* execution layer rules) MAY result in
down-scoring or disconnection.
### Messages
#### Messages
#### BeaconBlocksByRange v2
##### BeaconBlocksByRange v2
**Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_range/2/`
@ -146,7 +146,7 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:
| `ALTAIR_FORK_VERSION` | `altair.SignedBeaconBlock` |
| `BELLATRIX_FORK_VERSION` | `bellatrix.SignedBeaconBlock` |
#### BeaconBlocksByRoot v2
##### BeaconBlocksByRoot v2
**Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_root/2/`
@ -165,9 +165,9 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:
# Design decision rationale
## Gossipsub
### Gossipsub
### Why was the max gossip message size increased at Bellatrix?
#### Why was the max gossip message size increased at Bellatrix?
With the addition of `ExecutionPayload` to `BeaconBlock`s, there is a dynamic
field -- `transactions` -- which can validly exceed the `GOSSIP_MAX_SIZE` limit (1 MiB) put in
@ -190,9 +190,9 @@ order of 128 KiB in the worst case and the current gas limit (~30M) bounds max b
than 2 MiB today, this marginal difference in theoretical bounds will have zero
impact on network functionality and security.
## Req/Resp
### Req/Resp
### Why was the max chunk response size increased at Bellatrix?
#### Why was the max chunk response size increased at Bellatrix?
Similar to the discussion about the maximum gossip size increase, the
`ExecutionPayload` type can cause `BeaconBlock`s to exceed the 1 MiB bounds put
@ -204,7 +204,7 @@ valid block sizes in the range of gas limits expected in the medium term.
As with both gossip and req/rsp maximum values, type-specific limits should
always by simultaneously respected.
### Why allow invalid payloads on the P2P network?
#### Why allow invalid payloads on the P2P network?
The specification allows blocks with invalid execution payloads to propagate across
gossip and via RPC calls. The reasoning for this is as follows:

24
specs/capella/p2p-interface.md
View File

@ -4,7 +4,7 @@ This document contains the networking specification for Capella.
The specification of these changes continues in the same format as the network specifications of previous upgrades, and assumes them as pre-requisite.
## Table of contents
### Table of contents
<!-- TOC -->
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
@ -26,13 +26,13 @@ The specification of these changes continues in the same format as the network s
<!-- /TOC -->
# Modifications in Capella
## Modifications in Capella
## The gossip domain: gossipsub
### The gossip domain: gossipsub
A new topic is added to support the gossip of withdrawal credential change messages. And an existing topic is upgraded for updated types in Capella.
### Topics and messages
#### Topics and messages
Topics follow the same specification as in prior upgrades. All existing topics remain stable except the beacon block topic which is updated with the modified type.
@ -45,17 +45,17 @@ The new topics along with the type of the `data` field of a gossipsub message ar
Note that the `ForkDigestValue` path segment of the topic separates the old and the new `beacon_block` topics.
#### Global topics
##### Global topics
Capella changes the type of the global beacon block topic and adds one global topic to propagate withdrawal credential change messages to all potential proposers of beacon blocks.
##### `beacon_block`
###### `beacon_block`
The *type* of the payload of this topic changes to the (modified) `SignedBeaconBlock` found in Capella.
Specifically, this type changes with the addition of `bls_to_execution_changes` to the inner `BeaconBlockBody`.
See Capella [state transition document](./beacon-chain.md#beaconblockbody) for further details.
##### `bls_to_execution_change`
###### `bls_to_execution_change`
This topic is used to propagate signed bls to execution change messages to be included in future blocks.
@ -67,16 +67,16 @@ The following validations MUST pass before forwarding the `signed_bls_to_executi
for the validator with index `signed_bls_to_execution_change.message.validator_index`.
- _[REJECT]_ All of the conditions within `process_bls_to_execution_change` pass validation.
### Transitioning the gossip
#### Transitioning the gossip
See gossip transition details found in the [Altair document](../altair/p2p-interface.md#transitioning-the-gossip) for
details on how to handle transitioning gossip topics for Capella.
## The Req/Resp domain
### The Req/Resp domain
### Messages
#### Messages
#### BeaconBlocksByRange v2
##### BeaconBlocksByRange v2
**Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_range/2/`
@ -93,7 +93,7 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:
| `BELLATRIX_FORK_VERSION` | `bellatrix.SignedBeaconBlock` |
| `CAPELLA_FORK_VERSION` | `capella.SignedBeaconBlock` |
#### BeaconBlocksByRoot v2
##### BeaconBlocksByRoot v2
**Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_root/2/`

79
specs/deneb/p2p-interface.md
View File

@ -10,32 +10,35 @@ The specification of these changes continues in the same format as the network s
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
- [Configuration](#configuration)
- [Containers](#containers)
- [`BlobSidecar`](#blobsidecar)
- [`SignedBlobSidecar`](#signedblobsidecar)
- [`BlobIdentifier`](#blobidentifier)
- [Helpers](#helpers)
- [`verify_blob_sidecar_signature`](#verify_blob_sidecar_signature)
- [The gossip domain: gossipsub](#the-gossip-domain-gossipsub)
- [Topics and messages](#topics-and-messages)
- [Global topics](#global-topics)
- [`beacon_block`](#beacon_block)
- [`blob_sidecar_{index}`](#blob_sidecar_index)
- [Transitioning the gossip](#transitioning-the-gossip)
- [The Req/Resp domain](#the-reqresp-domain)
- [Messages](#messages)
- [BeaconBlocksByRange v2](#beaconblocksbyrange-v2)
- [BeaconBlocksByRoot v2](#beaconblocksbyroot-v2)
- [BlobSidecarsByRoot v1](#blobsidecarsbyroot-v1)
- [BlobSidecarsByRange v1](#blobsidecarsbyrange-v1)
- [Modifications in Deneb](#modifications-in-deneb)
- [Configuration](#configuration)
- [Containers](#containers)
- [`BlobSidecar`](#blobsidecar)
- [`SignedBlobSidecar`](#signedblobsidecar)
- [`BlobIdentifier`](#blobidentifier)
- [Helpers](#helpers)
- [`verify_blob_sidecar_signature`](#verify_blob_sidecar_signature)
- [The gossip domain: gossipsub](#the-gossip-domain-gossipsub)
- [Topics and messages](#topics-and-messages)
- [Global topics](#global-topics)
- [`beacon_block`](#beacon_block)
- [`blob_sidecar_{index}`](#blob_sidecar_index)
- [Transitioning the gossip](#transitioning-the-gossip)
- [The Req/Resp domain](#the-reqresp-domain)
- [Messages](#messages)
- [BeaconBlocksByRange v2](#beaconblocksbyrange-v2)
- [BeaconBlocksByRoot v2](#beaconblocksbyroot-v2)
- [BlobSidecarsByRoot v1](#blobsidecarsbyroot-v1)
- [BlobSidecarsByRange v1](#blobsidecarsbyrange-v1)
- [Design decision rationale](#design-decision-rationale)
- [Why are blobs relayed as a sidecar, separate from beacon blocks?](#why-are-blobs-relayed-as-a-sidecar-separate-from-beacon-blocks)
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
<!-- /TOC -->
## Configuration
## Modifications in Deneb
### Configuration
| Name | Value | Description |
|------------------------------------------|-----------------------------------|---------------------------------------------------------------------|
@ -43,9 +46,9 @@ The specification of these changes continues in the same format as the network s
| `MAX_REQUEST_BLOB_SIDECARS` | `MAX_REQUEST_BLOCKS_DENEB * MAX_BLOBS_PER_BLOCK` | Maximum number of blob sidecars in a single request |
| `MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS` | `2**12` (= 4096 epochs, ~18 days) | The minimum epoch range over which a node must serve blob sidecars |
## Containers
### Containers
### `BlobSidecar`
#### `BlobSidecar`
```python
class BlobSidecar(Container):
@ -59,7 +62,7 @@ class BlobSidecar(Container):
kzg_proof: KZGProof # Allows for quick verification of kzg_commitment
```
### `SignedBlobSidecar`
#### `SignedBlobSidecar`
```python
class SignedBlobSidecar(Container):
@ -67,7 +70,7 @@ class SignedBlobSidecar(Container):
signature: BLSSignature
```
### `BlobIdentifier`
#### `BlobIdentifier`
```python
class BlobIdentifier(Container):
@ -75,9 +78,9 @@ class BlobIdentifier(Container):
index: BlobIndex
```
### Helpers
#### Helpers
#### `verify_blob_sidecar_signature`
##### `verify_blob_sidecar_signature`
```python
def verify_blob_sidecar_signature(state: BeaconState, signed_blob_sidecar: SignedBlobSidecar) -> bool:
@ -86,11 +89,11 @@ def verify_blob_sidecar_signature(state: BeaconState, signed_blob_sidecar: Signe
return bls.Verify(proposer.pubkey, signing_root, signed_blob_sidecar.signature)
```
## The gossip domain: gossipsub
### The gossip domain: gossipsub
Some gossip meshes are upgraded in the fork of Deneb to support upgraded types.
### Topics and messages
#### Topics and messages
Topics follow the same specification as in prior upgrades.
@ -106,15 +109,15 @@ The new topics along with the type of the `data` field of a gossipsub message ar
| - | - |
| `blob_sidecar_{index}` | `SignedBlobSidecar` (new) |
#### Global topics
##### Global topics
Deneb introduces new global topics for blob sidecars.
##### `beacon_block`
###### `beacon_block`
The *type* of the payload of this topic changes to the (modified) `SignedBeaconBlock` found in deneb.
##### `blob_sidecar_{index}`
###### `blob_sidecar_{index}`
This topic is used to propagate signed blob sidecars, one for each sidecar index. The number of indices is defined by `MAX_BLOBS_PER_BLOCK`.
@ -132,16 +135,16 @@ The following validations MUST pass before forwarding the `signed_blob_sidecar`
If the `proposer_index` cannot immediately be verified against the expected shuffling, the sidecar MAY be queued for later processing while proposers for the block's branch are calculated -- in such a case _do not_ `REJECT`, instead `IGNORE` this message.
### Transitioning the gossip
#### Transitioning the gossip
See gossip transition details found in the [Altair document](../altair/p2p-interface.md#transitioning-the-gossip) for
details on how to handle transitioning gossip topics for this upgrade.
## The Req/Resp domain
### The Req/Resp domain
### Messages
#### Messages
#### BeaconBlocksByRange v2
##### BeaconBlocksByRange v2
**Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_range/2/`
@ -161,7 +164,7 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:
No more than `MAX_REQUEST_BLOCKS_DENEB` may be requested at a time.
#### BeaconBlocksByRoot v2
##### BeaconBlocksByRoot v2
**Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_root/2/`
@ -179,7 +182,7 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:
No more than `MAX_REQUEST_BLOCKS_DENEB` may be requested at a time.
#### BlobSidecarsByRoot v1
##### BlobSidecarsByRoot v1
**Protocol ID:** `/eth2/beacon_chain/req/blob_sidecars_by_root/1/`
@ -228,7 +231,7 @@ Clients MUST support requesting sidecars since `minimum_request_epoch`, where `m
Clients MUST respond with at least one sidecar, if they have it.
Clients MAY limit the number of blocks and sidecars in the response.
#### BlobSidecarsByRange v1
##### BlobSidecarsByRange v1
**Protocol ID:** `/eth2/beacon_chain/req/blob_sidecars_by_range/1/`

186
specs/phase0/p2p-interface.md
View File

@ -111,11 +111,11 @@ It consists of four main sections:
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
<!-- /TOC -->
# Network fundamentals
## Network fundamentals
This section outlines the specification for the networking stack in Ethereum consensus-layer clients.
## Transport
### Transport
Even though libp2p is a multi-transport stack (designed to listen on multiple simultaneous transports and endpoints transparently),
we hereby define a profile for basic interoperability.
@ -133,14 +133,14 @@ All listening endpoints must be publicly dialable, and thus not rely on libp2p c
Nodes operating behind a NAT, or otherwise undialable by default (e.g. container runtime, firewall, etc.),
MUST have their infrastructure configured to enable inbound traffic on the announced public listening endpoint.
## Encryption and identification
### Encryption and identification
The [Libp2p-noise](https://github.com/libp2p/specs/tree/master/noise) secure
channel handshake with `secp256k1` identities will be used for encryption.
As specified in the libp2p specification, clients MUST support the `XX` handshake pattern.
## Protocol Negotiation
### Protocol Negotiation
Clients MUST use exact equality when negotiating protocol versions to use and MAY use the version to give priority to higher version numbers.
@ -148,7 +148,7 @@ Clients MUST support [multistream-select 1.0](https://github.com/multiformats/mu
and MAY support [multiselect 2.0](https://github.com/libp2p/specs/pull/95) when the spec solidifies.
Once all clients have implementations for multiselect 2.0, multistream-select 1.0 MAY be phased out.
## Multiplexing
### Multiplexing
During connection bootstrapping, libp2p dynamically negotiates a mutually supported multiplexing method to conduct parallel conversations.
This applies to transports that are natively incapable of multiplexing (e.g. TCP, WebSockets, WebRTC),
@ -163,9 +163,9 @@ and MAY support [yamux](https://github.com/hashicorp/yamux/blob/master/spec.md).
If both are supported by the client, yamux MUST take precedence during negotiation.
See the [Rationale](#design-decision-rationale) section below for tradeoffs.
# Consensus-layer network interaction domains
## Consensus-layer network interaction domains
## Configuration
### Configuration
This section outlines constants that are used in this spec.
@ -182,7 +182,7 @@ This section outlines constants that are used in this spec.
| `MESSAGE_DOMAIN_INVALID_SNAPPY` | `0x00000000` | 4-byte domain for gossip message-id isolation of *invalid* snappy messages |
| `MESSAGE_DOMAIN_VALID_SNAPPY` | `0x01000000` | 4-byte domain for gossip message-id isolation of *valid* snappy messages |
## MetaData
### MetaData
Clients MUST locally store the following `MetaData`:
@ -203,7 +203,7 @@ Where
is entirely independent of the ENR sequence number,
and will in most cases be out of sync with the ENR sequence number.
## The gossip domain: gossipsub
### The gossip domain: gossipsub
Clients MUST support the [gossipsub v1](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md) libp2p Protocol
including the [gossipsub v1.1](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md) extension.
@ -229,7 +229,7 @@ The following gossipsub [parameters](https://github.com/libp2p/specs/blob/master
for peer scoring and other attack mitigations.
These are currently under investigation and will be spec'd and released to mainnet when they are ready.
### Topics and messages
#### Topics and messages
Topics are plain UTF-8 strings and are encoded on the wire as determined by protobuf (gossipsub messages are enveloped in protobuf messages).
Topic strings have form: `/eth2/ForkDigestValue/Name/Encoding`.
@ -289,7 +289,7 @@ We utilize `ACCEPT`, `REJECT`, and `IGNORE`. For each gossipsub topic, there are
If all validations pass, return `ACCEPT`.
If one or more validations fail while processing the items in order, return either `REJECT` or `IGNORE` as specified in the prefix of the particular condition.
#### Global topics
##### Global topics
There are two primary global topics used to propagate beacon blocks (`beacon_block`)
and aggregate attestations (`beacon_aggregate_and_proof`) to all nodes on the network.
@ -297,7 +297,7 @@ and aggregate attestations (`beacon_aggregate_and_proof`) to all nodes on the ne
There are three additional global topics that are used to propagate lower frequency validator messages
(`voluntary_exit`, `proposer_slashing`, and `attester_slashing`).
##### `beacon_block`
###### `beacon_block`
The `beacon_block` topic is used solely for propagating new signed beacon blocks to all nodes on the networks.
Signed blocks are sent in their entirety.
@ -325,7 +325,7 @@ The following validations MUST pass before forwarding the `signed_beacon_block`
the block MAY be queued for later processing while proposers for the block's branch are calculated --
in such a case _do not_ `REJECT`, instead `IGNORE` this message.
##### `beacon_aggregate_and_proof`
###### `beacon_aggregate_and_proof`
The `beacon_aggregate_and_proof` topic is used to propagate aggregated attestations (as `SignedAggregateAndProof`s)
to subscribing nodes (typically validators) to be included in future blocks.
@ -360,7 +360,7 @@ The following validations MUST pass before forwarding the `signed_aggregate_and_
== store.finalized_checkpoint.root`
##### `voluntary_exit`
###### `voluntary_exit`
The `voluntary_exit` topic is used solely for propagating signed voluntary validator exits to proposers on the network.
Signed voluntary exits are sent in their entirety.
@ -370,7 +370,7 @@ The following validations MUST pass before forwarding the `signed_voluntary_exit
for the validator with index `signed_voluntary_exit.message.validator_index`.
- _[REJECT]_ All of the conditions within `process_voluntary_exit` pass validation.
##### `proposer_slashing`
###### `proposer_slashing`
The `proposer_slashing` topic is used solely for propagating proposer slashings to proposers on the network.
Proposer slashings are sent in their entirety.
@ -380,7 +380,7 @@ The following validations MUST pass before forwarding the `proposer_slashing` on
for the proposer with index `proposer_slashing.signed_header_1.message.proposer_index`.
- _[REJECT]_ All of the conditions within `process_proposer_slashing` pass validation.
##### `attester_slashing`
###### `attester_slashing`
The `attester_slashing` topic is used solely for propagating attester slashings to proposers on the network.
Attester slashings are sent in their entirety.
@ -392,11 +392,11 @@ Clients who receive an attester slashing on this topic MUST validate the conditi
verify if `any(attester_slashed_indices.difference(prior_seen_attester_slashed_indices))`).
- _[REJECT]_ All of the conditions within `process_attester_slashing` pass validation.
#### Attestation subnets
##### Attestation subnets
Attestation subnets are used to propagate unaggregated attestations to subsections of the network.
##### `beacon_attestation_{subnet_id}`
###### `beacon_attestation_{subnet_id}`
The `beacon_attestation_{subnet_id}` topics are used to propagate unaggregated attestations
to the subnet `subnet_id` (typically beacon and persistent committees) to be aggregated before being gossiped to `beacon_aggregate_and_proof`.
@ -432,7 +432,7 @@ The following validations MUST pass before forwarding the `attestation` on the s
#### Attestations and Aggregation
##### Attestations and Aggregation
Attestation broadcasting is grouped into subnets defined by a topic.
The number of subnets is defined via `ATTESTATION_SUBNET_COUNT`.
@ -445,7 +445,7 @@ Unaggregated attestations are sent as `Attestation`s to the subnet topic,
Aggregated attestations are sent to the `beacon_aggregate_and_proof` topic as `AggregateAndProof`s.
### Encodings
#### Encodings
Topics are post-fixed with an encoding. Encodings define how the payload of a gossipsub message is encoded.
@ -461,9 +461,9 @@ so [basic snappy block compression](https://github.com/google/snappy/blob/master
Implementations MUST use a single encoding for gossip.
Changing an encoding will require coordination between participating implementations.
## The Req/Resp domain
### The Req/Resp domain
### Protocol identification
#### Protocol identification
Each message type is segregated into its own libp2p protocol ID, which is a case-sensitive UTF-8 string of the form:
@ -485,7 +485,7 @@ With:
This protocol segregation allows libp2p `multistream-select 1.0` / `multiselect 2.0`
to handle the request type, version, and encoding negotiation before establishing the underlying streams.
### Req/Resp interaction
#### Req/Resp interaction
We use ONE stream PER request/response interaction.
Streams are closed when the interaction finishes, whether in success or in error.
@ -515,7 +515,7 @@ Regardless of these type specific bounds, a global maximum uncompressed byte siz
Clients MUST ensure that lengths are within these bounds; if not, they SHOULD reset the stream immediately.
Clients tracking peer reputation MAY decrement the score of the misbehaving peer under this circumstance.
#### Requesting side
##### Requesting side
Once a new stream with the protocol ID for the request type has been negotiated, the full request message SHOULD be sent immediately.
The request MUST be encoded according to the encoding strategy.
@ -537,7 +537,7 @@ A requester SHOULD read from the stream until either:
For requests consisting of a single valid `response_chunk`,
the requester SHOULD read the chunk fully, as defined by the `encoding-dependent-header`, before closing the stream.
#### Responding side
##### Responding side
Once a new stream with the protocol ID for the request type has been negotiated,
the responder SHOULD process the incoming request and MUST validate it before processing it.
@ -588,7 +588,7 @@ The `ErrorMessage` schema is:
*Note*: By convention, the `error_message` is a sequence of bytes that MAY be interpreted as a UTF-8 string (for debugging purposes).
Clients MUST treat as valid any byte sequences.
### Encoding strategies
#### Encoding strategies
The token of the negotiated protocol ID specifies the type of encoding to be used for the req/resp interaction.
Only one value is possible at this time:
@ -599,7 +599,7 @@ Only one value is possible at this time:
For example, the `BeaconBlocksByRoot` request is an SSZ-encoded list of `Root`'s.
This encoding type MUST be supported by all clients.
#### SSZ-snappy encoding strategy
##### SSZ-snappy encoding strategy
The [SimpleSerialize (SSZ) specification](../../ssz/simple-serialize.md) outlines how objects are SSZ-encoded.
@ -646,9 +646,9 @@ constituents individually as `response_chunk`s. For example, the
`List[SignedBeaconBlock, ...]` response type sends zero or more `response_chunk`s.
Each _successful_ `response_chunk` contains a single `SignedBeaconBlock` payload.
### Messages
#### Messages
#### Status
##### Status
**Protocol ID:** ``/eth2/beacon_chain/req/status/1/``
@ -694,7 +694,7 @@ SHOULD request beacon blocks from its counterparty via the `BeaconBlocksByRange`
the client might need to send `Status` request again to learn if the peer has a higher head.
Implementers are free to implement such behavior in their own way.
#### Goodbye
##### Goodbye
**Protocol ID:** ``/eth2/beacon_chain/req/goodbye/1/``
@ -718,7 +718,7 @@ The request/response MUST be encoded as a single SSZ-field.
The response MUST consist of a single `response_chunk`.
#### BeaconBlocksByRange
##### BeaconBlocksByRange
**Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_range/1/`
@ -795,7 +795,7 @@ In particular when `step == 1`, each `parent_root` MUST match the `hash_tree_roo
After the initial block, clients MAY stop in the process of responding
if their fork choice changes the view of the chain in the context of the request.
#### BeaconBlocksByRoot
##### BeaconBlocksByRoot
**Protocol ID:** `/eth2/beacon_chain/req/beacon_blocks_by_root/1/`
@ -835,7 +835,7 @@ Clients MAY limit the number of blocks in the response.
`/eth2/beacon_chain/req/beacon_blocks_by_root/1/` is deprecated. Clients MAY respond with an empty list during the deprecation transition period.
#### Ping
##### Ping
**Protocol ID:** `/eth2/beacon_chain/req/ping/1/`
@ -867,7 +867,7 @@ The request MUST be encoded as an SSZ-field.
The response MUST consist of a single `response_chunk`.
#### GetMetaData
##### GetMetaData
**Protocol ID:** `/eth2/beacon_chain/req/metadata/1/`
@ -890,14 +890,14 @@ The response MUST be encoded as an SSZ-container.
The response MUST consist of a single `response_chunk`.
## The discovery domain: discv5
### The discovery domain: discv5
Discovery Version 5 ([discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md)) (Protocol version v5.1) is used for peer discovery.
`discv5` is a standalone protocol, running on UDP on a dedicated port, meant for peer discovery only.
`discv5` supports self-certified, flexible peer records (ENRs) and topic-based advertisement, both of which are (or will be) requirements in this context.
### Integration into libp2p stacks
#### Integration into libp2p stacks
`discv5` SHOULD be integrated into the client’s libp2p stack by implementing an adaptor
to make it conform to the [service discovery](https://github.com/libp2p/go-libp2p-core/blob/master/discovery/discovery.go)
@ -908,7 +908,7 @@ and the outputs will be multiaddrs converted from the ENR records returned by th
This integration enables the libp2p stack to subsequently form connections and streams with discovered peers.
### ENR structure
#### ENR structure
The Ethereum Node Record (ENR) for an Ethereum consensus client MUST contain the following entries
(exclusive of the sequence number and signature, which MUST be present in an ENR):
@ -923,7 +923,7 @@ The ENR MAY contain the following entries:
Specifications of these parameters can be found in the [ENR Specification](http://eips.ethereum.org/EIPS/eip-778).
#### Attestation subnet bitfield
##### Attestation subnet bitfield
The ENR `attnets` entry signifies the attestation subnet bitfield with the following form
to more easily discover peers participating in particular attestation gossip subnets.
@ -936,7 +936,7 @@ If a node's `MetaData.attnets` has any non-zero bit, the ENR MUST include the `a
If a node's `MetaData.attnets` is composed of all zeros, the ENR MAY optionally include the `attnets` entry or leave it out entirely.
#### `eth2` field
##### `eth2` field
ENRs MUST carry a generic `eth2` key with an 16-byte value of the node's current fork digest, next fork version,
and next fork epoch to ensure connections are made with peers on the intended Ethereum network.
@ -979,11 +979,11 @@ Clients MAY connect to peers with the same `fork_digest` but a different `next_f
Unless `ENRForkID` is manually updated to matching prior to the earlier `next_fork_epoch` of the two clients,
these connecting clients will be unable to successfully interact starting at the earlier `next_fork_epoch`.
# Design decision rationale
## Design decision rationale
## Transport
### Transport
### Why are we defining specific transports?
#### Why are we defining specific transports?
libp2p peers can listen on multiple transports concurrently, and these can change over time.
Multiaddrs encode not only the address but also the transport to be used to dial.
@ -992,7 +992,7 @@ Due to this dynamic nature, agreeing on specific transports like TCP, QUIC, or W
However, it is useful to define a minimum baseline for interoperability purposes.
### Can clients support other transports/handshakes than the ones mandated by the spec?
#### Can clients support other transports/handshakes than the ones mandated by the spec?
Clients may support other transports such as libp2p QUIC, WebSockets, and WebRTC transports, if available in the language of choice.
While interoperability shall not be harmed by lack of such support, the advantages are desirable:
@ -1007,7 +1007,7 @@ and the accompanying [QUIC-TLS document](https://tools.ietf.org/html/draft-ietf-
The usage of one handshake procedure or the other shall be transparent to the application layer,
once the libp2p Host/Node object has been configured appropriately.
### What are the advantages of using TCP/QUIC/Websockets?
#### What are the advantages of using TCP/QUIC/Websockets?
TCP is a reliable, ordered, full-duplex, congestion-controlled network protocol that powers much of the Internet as we know it today.
HTTP/1.1 and HTTP/2 run atop TCP.
@ -1027,7 +1027,7 @@ and we may only become subject to standard IP-based firewall filtering—somethi
WebSockets and/or WebRTC transports are necessary for interaction with browsers,
and will become increasingly important as we incorporate browser-based light clients to the Ethereum network.
### Why do we not just support a single transport?
#### Why do we not just support a single transport?
Networks evolve.
Hardcoding design decisions leads to ossification, preventing the evolution of networks alongside the state of the art.
@ -1039,7 +1039,7 @@ Clients can adopt new transports without breaking old ones, and the multi-transp
(e.g. browsers, embedded devices) to interact with the network as first-class citizens via suitable/native transports (e.g. WSS),
without the need for proxying or trust delegation to servers.
### Why are we not using QUIC from the start?
#### Why are we not using QUIC from the start?
The QUIC standard is still not finalized (at working draft 22 at the time of writing),
and not all mainstream runtimes/languages have mature, standard, and/or fully-interoperable [QUIC support](https://github.com/quicwg/base-drafts/wiki/Implementations).
@ -1052,9 +1052,9 @@ On the other hand, TLS 1.3 is the newest, simplified iteration of TLS.
Old, insecure, obsolete ciphers and algorithms have been removed, adopting Ed25519 as the sole ECDH key agreement function.
Handshakes are faster, 1-RTT data is supported, and session resumption is a reality, amongst other features.
## Multiplexing
### Multiplexing
### Why are we using mplex/yamux?
#### Why are we using mplex/yamux?
[Yamux](https://github.com/hashicorp/yamux/blob/master/spec.md) is a multiplexer invented by Hashicorp that supports stream-level congestion control.
Implementations exist in a limited set of languages, and it’s not a trivial piece to develop.
@ -1066,9 +1066,9 @@ It does not support stream-level congestion control and is subject to head-of-li
Overlay multiplexers are not necessary with QUIC since the protocol provides native multiplexing,
but they need to be layered atop TCP, WebSockets, and other transports that lack such support.
## Protocol Negotiation
### Protocol Negotiation
### When is multiselect 2.0 due and why do we plan to migrate to it?
#### When is multiselect 2.0 due and why do we plan to migrate to it?
multiselect 2.0 is currently being conceptualized.
The debate started [on this issue](https://github.com/libp2p/specs/pull/95),
@ -1084,7 +1084,7 @@ We plan to eventually migrate to multiselect 2.0 because it will:
3. Leverage *push data* mechanisms of underlying protocols to expedite negotiation.
4. Provide the building blocks for enhanced censorship resistance.
### What is the difference between connection-level and stream-level protocol negotiation?
#### What is the difference between connection-level and stream-level protocol negotiation?
All libp2p connections must be authenticated, encrypted, and multiplexed.
Connections using network transports unsupportive of native authentication/encryption and multiplexing (e.g. TCP) need to undergo protocol negotiation to agree on a mutually supported:
@ -1101,9 +1101,9 @@ When opening streams, peers pin a protocol to that stream, by conducting *stream
At present, multistream-select 1.0 is used for both types of negotiation,
but multiselect 2.0 will use dedicated mechanisms for connection bootstrapping process and stream protocol negotiation.
## Encryption
### Encryption
### Why are we not supporting SecIO?
#### Why are we not supporting SecIO?
SecIO has been the default encryption layer for libp2p for years.
It is used in IPFS and Filecoin. And although it will be superseded shortly, it is proven to work at scale.
@ -1114,7 +1114,7 @@ a mechanism that multiselect 2.0 will leverage to reduce round trips during conn
SecIO is not considered secure for the purposes of this spec.
### Why are we using Noise?
#### Why are we using Noise?
Copied from the Noise Protocol Framework [website](http://www.noiseprotocol.org):
@ -1129,7 +1129,7 @@ and are used in major cryptographic-centric projects like WireGuard, I2P, and Li
[Various](https://www.wireguard.com/papers/kobeissi-bhargavan-noise-explorer-2018.pdf) [studies](https://eprint.iacr.org/2019/436.pdf)
have assessed the stated security goals of several Noise handshakes with positive results.
### Why are we using encryption at all?
#### Why are we using encryption at all?
Transport level encryption secures message exchange and provides properties that are useful for privacy, safety, and censorship resistance.
These properties are derived from the following security guarantees that apply to the entire communication between two peers:
@ -1146,9 +1146,9 @@ Note that transport-level encryption is not exclusive of application-level encry
Transport-level encryption secures the communication itself,
while application-level cryptography is necessary for the application’s use cases (e.g. signatures, randomness, etc.).
## Gossipsub
### Gossipsub
### Why are we using a pub/sub algorithm for block and attestation propagation?
#### Why are we using a pub/sub algorithm for block and attestation propagation?
Pubsub is a technique to broadcast/disseminate data across a network rapidly.
Such data is packaged in fire-and-forget messages that do not require a response from every recipient.
@ -1156,18 +1156,18 @@ Peers subscribed to a topic participate in the propagation of messages in that t
The alternative is to maintain a fully connected mesh (all peers connected to each other 1:1), which scales poorly (O(n^2)).
### Why are we using topics to segregate encodings, yet only support one encoding?
#### Why are we using topics to segregate encodings, yet only support one encoding?
For future extensibility with almost zero overhead now (besides the extra bytes in the topic name).
### How do we upgrade gossip channels (e.g. changes in encoding, compression)?
#### How do we upgrade gossip channels (e.g. changes in encoding, compression)?
Changing gossipsub/broadcasts requires a coordinated upgrade where all clients start publishing to the new topic together, during a hard fork.
When a node is preparing for upcoming tasks (e.g. validator duty lookahead) on a gossipsub topic,
the node should join the topic of the future epoch in which the task is to occur in addition to listening to the topics for the current epoch.
### Why must all clients use the same gossip topic instead of one negotiated between each peer pair?
#### Why must all clients use the same gossip topic instead of one negotiated between each peer pair?
Supporting multiple topics/encodings would require the presence of relayers to translate between encodings
and topics so as to avoid network fragmentation where participants have diverging views on the gossiped state,
@ -1182,7 +1182,7 @@ but the price here is pretty high in terms of overhead -- both computational and
It is permitted for clients to publish data on alternative topics as long as they also publish on the network-wide mandatory topic.
### Why are the topics strings and not hashes?
#### Why are the topics strings and not hashes?
Topic names have a hierarchical structure.
In the future, gossipsub may support wildcard subscriptions
@ -1195,14 +1195,14 @@ since the domain is finite anyway, and calculating a digest's preimage would be
Furthermore, the topic names are shorter than their digest equivalents (assuming SHA-256 hash),
so hashing topics would bloat messages unnecessarily.
### Why are we using the `StrictNoSign` signature policy?
#### Why are we using the `StrictNoSign` signature policy?
The policy omits the `from` (1), `seqno` (3), `signature` (5) and `key` (6) fields. These fields would:
- Expose origin of sender (`from`), type of sender (based on `seqno`)
- Add extra unused data to the gossip, since message IDs are based on `data`, not on the `from` and `seqno`.
- Introduce more message validation than necessary, e.g. no `signature`.
### Why are we overriding the default libp2p pubsub `message-id`?
#### Why are we overriding the default libp2p pubsub `message-id`?
For our current purposes, there is no need to address messages based on source peer, or track a message `seqno`.
By overriding the default `message-id` to use content-addressing we can filter unnecessary duplicates before hitting the application layer.
@ -1214,7 +1214,7 @@ Some examples of where messages could be duplicated:
Partial aggregates could be duplicated
* Clients re-publishing seen messages
### Why are these specific gossip parameters chosen?
#### Why are these specific gossip parameters chosen?
- `D`, `D_low`, `D_high`, `D_lazy`: recommended defaults.
- `heartbeat_interval`: 0.7 seconds, recommended for the beacon chain in the [GossipSub evaluation report by Protocol Labs](https://gateway.ipfs.io/ipfs/QmRAFP5DBnvNjdYSbWhEhVRJJDFCLpPyvew5GwCCB4VxM4).
@ -1233,7 +1233,7 @@ Some examples of where messages could be duplicated:
Attestation gossip validity is bounded by an epoch, so this is the safe max bound.
### Why is there `MAXIMUM_GOSSIP_CLOCK_DISPARITY` when validating slot ranges of messages in gossip subnets?
#### Why is there `MAXIMUM_GOSSIP_CLOCK_DISPARITY` when validating slot ranges of messages in gossip subnets?
For some gossip channels (e.g. those for Attestations and BeaconBlocks),
there are designated ranges of slots during which particular messages can be sent,
@ -1247,14 +1247,14 @@ For minimum and maximum allowable slot broadcast times,
Although messages can at times be eagerly gossiped to the network,
the node's fork choice prevents integration of these messages into the actual consensus until the _actual local start_ of the designated slot.
### Why are there `ATTESTATION_SUBNET_COUNT` attestation subnets?
#### Why are there `ATTESTATION_SUBNET_COUNT` attestation subnets?
Depending on the number of validators, it may be more efficient to group shard subnets and might provide better stability for the gossipsub channel.
The exact grouping will be dependent on more involved network tests.
This constant allows for more flexibility in setting up the network topology for attestation aggregation (as aggregation should happen on each subnet).
The value is currently set to be equal to `MAX_COMMITTEES_PER_SLOT` if/until network tests indicate otherwise.
### Why are attestations limited to be broadcast on gossip channels within `SLOTS_PER_EPOCH` slots?
#### Why are attestations limited to be broadcast on gossip channels within `SLOTS_PER_EPOCH` slots?
Attestations can only be included on chain within an epoch's worth of slots so this is the natural cutoff.
There is no utility to the chain to broadcast attestations older than one epoch,
@ -1265,7 +1265,7 @@ In addition to this, relaying attestations requires validating the attestation i
Thus, validating arbitrarily old attestations would put additional requirements on which states need to be readily available to the node.
This would result in a higher resource burden and could serve as a DoS vector.
### Why are aggregate attestations broadcast to the global topic as `AggregateAndProof`s rather than just as `Attestation`s?
#### Why are aggregate attestations broadcast to the global topic as `AggregateAndProof`s rather than just as `Attestation`s?
The dominant strategy for an individual validator is to always broadcast an aggregate containing their own attestation
to the global channel to ensure that proposers see their attestation for inclusion.
@ -1275,19 +1275,19 @@ the gossiped aggregate ensures that this dominant strategy will not flood the gl
Also, an attacker can create any number of honest-looking aggregates and broadcast them to the global pubsub channel.
Thus without some sort of proof of selection as an aggregator, the global channel can trivially be spammed.
### Why are we sending entire objects in the pubsub and not just hashes?
#### Why are we sending entire objects in the pubsub and not just hashes?
Entire objects should be sent to get the greatest propagation speeds.
If only hashes are sent, then block and attestation propagation is dependent on recursive requests from each peer.
In a hash-only scenario, peers could receive hashes without knowing who to download the actual contents from.
Sending entire objects ensures that they get propagated through the entire network.
### Should clients gossip blocks if they *cannot* validate the proposer signature due to not yet being synced, not knowing the head block, etc?
#### Should clients gossip blocks if they *cannot* validate the proposer signature due to not yet being synced, not knowing the head block, etc?
The prohibition of unverified-block-gossiping extends to nodes that cannot verify a signature
due to not being fully synced to ensure that such (amplified) DOS attacks are not possible.
### How are we going to discover peers in a gossipsub topic?
#### How are we going to discover peers in a gossipsub topic?
In Phase 0, peers for attestation subnets will be found using the `attnets` entry in the ENR.
@ -1295,7 +1295,7 @@ Although this method will be sufficient for early upgrade of the beacon chain, w
ENRs should ultimately not be used for this purpose.
They are best suited to store identity, location, and capability information, rather than more volatile advertisements.
### How should fork version be used in practice?
#### How should fork version be used in practice?
Fork versions are to be manually updated (likely via incrementing) at each hard fork.
This is to provide native domain separation for signatures as well as to aid in usefulness for identitying peers (via ENRs)
@ -1308,9 +1308,9 @@ In these cases, extra care should be taken to isolate fork versions (e.g. flip a
A node locally stores all previous and future planned fork versions along with the each fork epoch.
This allows for handling sync and processing messages starting from past forks/epochs.
## Req/Resp
### Req/Resp
### Why segregate requests into dedicated protocol IDs?
#### Why segregate requests into dedicated protocol IDs?
Requests are segregated by protocol ID to:
@ -1343,7 +1343,7 @@ Multiselect 2.0 will eventually remove this overhead by memoizing previously sel
Fortunately, this req/resp protocol is not the expected network bottleneck in the protocol
so the additional overhead is not expected to significantly hinder this domain.
### Why are messages length-prefixed with a protobuf varint in the SSZ-encoding?
#### Why are messages length-prefixed with a protobuf varint in the SSZ-encoding?
We are using single-use streams where each stream is closed at the end of the message.
Thus, libp2p transparently handles message delimiting in the underlying stream.
@ -1361,7 +1361,7 @@ Nevertheless, in the case of `ssz_snappy`, messages are still length-prefixed wi
[Protobuf varint](https://developers.google.com/protocol-buffers/docs/encoding#varints) is an efficient technique to encode variable-length (unsigned here) ints.
Instead of reserving a fixed-size field of as many bytes as necessary to convey the maximum possible value, this field is elastic in exchange for 1-bit overhead per byte.
### Why do we version protocol strings with ordinals instead of semver?
#### Why do we version protocol strings with ordinals instead of semver?
Using semver for network protocols is confusing.
It is never clear what a change in a field, even if backwards compatible on deserialization, actually implies.
@ -1382,11 +1382,11 @@ because it's unclear if "backwards compatibility" and "breaking change" apply on
For this reason, we remove and replace semver with ordinals that require explicit agreement and do not mandate a specific policy for changes.
### Why is it called Req/Resp and not RPC?
#### Why is it called Req/Resp and not RPC?
Req/Resp is used to avoid confusion with JSON-RPC and similar user-client interaction mechanisms.
### Why do we allow empty responses in block requests?
#### Why do we allow empty responses in block requests?
When requesting blocks by range or root, it may happen that there are no blocks in the selected range or the responding node does not have the requested blocks.
@ -1413,7 +1413,7 @@ Failing to provide blocks that nodes "should" have is reason to trust a peer les
-- for example, if a particular peer gossips a block, it should have access to its parent.
If a request for the parent fails, it's indicative of poor peer quality since peers should validate blocks before gossiping them.
### Why does `BeaconBlocksByRange` let the server choose which branch to send blocks from?
#### Why does `BeaconBlocksByRange` let the server choose which branch to send blocks from?
When connecting, the `Status` message gives an idea about the sync status of a particular peer, but this changes over time.
By the time a subsequent `BeaconBlockByRange` request is processed, the information may be stale,
@ -1423,7 +1423,7 @@ To avoid this race condition, we allow the responding side to choose which branc
The requesting client then goes on to validate the blocks and incorporate them in their own database
-- because they follow the same rules, they should at this point arrive at the same canonical chain.
### Why are `BlocksByRange` requests only required to be served for the latest `MIN_EPOCHS_FOR_BLOCK_REQUESTS` epochs?
#### Why are `BlocksByRange` requests only required to be served for the latest `MIN_EPOCHS_FOR_BLOCK_REQUESTS` epochs?
Due to economic finality and weak subjectivity requirements of a proof-of-stake blockchain, for a new node to safely join the network
the node must provide a recent checkpoint found out-of-band. This checkpoint can be in the form of a `root` & `epoch` or it can be the entire
@ -1447,7 +1447,7 @@ MIN_EPOCHS_FOR_BLOCK_REQUESTS = (
Where `MAX_SAFETY_DECAY = 100` and thus `MIN_EPOCHS_FOR_BLOCK_REQUESTS = 33024` (~5 months).
### Why must the proposer signature be checked when backfilling blocks in the database?
#### Why must the proposer signature be checked when backfilling blocks in the database?
When backfilling blocks in a database from a know safe block/state (e.g. when starting from a weak subjectivity state),
the node not only must ensure the `BeaconBlock`s form a chain to the known safe block,
@ -1462,7 +1462,7 @@ Although in this particular use case this does not represent a decay in safety
would represent invalid historic data and could be unwittingly transmitted to
additional nodes.
### What's the effect of empty slots on the sync algorithm?
#### What's the effect of empty slots on the sync algorithm?
When syncing one can only tell that a slot has been skipped on a particular branch
by examining subsequent blocks and analyzing the graph formed by the parent root.
@ -1472,9 +1472,9 @@ For example, if a peer responds with blocks [2, 3] when asked for [2, 3, 4], cli
-- it merely means that the responding peer did not send it (they may not have it yet or may maliciously be trying to hide it)
and successive blocks will be needed to determine if there exists a block at slot 4 in this particular branch.
## Discovery
### Discovery
### Why are we using discv5 and not libp2p Kademlia DHT?
#### Why are we using discv5 and not libp2p Kademlia DHT?
discv5 is a standalone protocol, running on UDP on a dedicated port, meant for peer and service discovery only.
discv5 supports self-certified, flexible peer records (ENRs) and topic-based advertisement, both of which are, or will be, requirements in this context.
@ -1490,7 +1490,7 @@ It should also help light clients of both networks find nodes with specific capa
discv5 is in the process of being audited.
### What is the difference between an ENR and a multiaddr, and why are we using ENRs?
#### What is the difference between an ENR and a multiaddr, and why are we using ENRs?
Ethereum Node Records are self-certified node records.
Nodes craft and disseminate ENRs for themselves, proving authorship via a cryptographic signature.
@ -1510,7 +1510,7 @@ discv5 uses ENRs and we will presumably need to:
2. Define a bi-directional conversion function between multiaddrs and the corresponding denormalized fields in an ENR
(ip, ip6, tcp, tcp6, etc.), for compatibility with nodes that do not support multiaddr natively (e.g. Ethereum execution-layer nodes).
### Why do we not form ENRs and find peers until genesis block/state is known?
#### Why do we not form ENRs and find peers until genesis block/state is known?
Although client software might very well be running locally prior to the solidification of the beacon chain genesis state and block,
clients cannot form valid ENRs prior to this point.
@ -1521,9 +1521,9 @@ Once genesis data is known, we can then form ENRs and safely find peers.
When using a proof-of-work deposit contract for deposits, `fork_digest` will be known `GENESIS_DELAY` (7 days in mainnet configuration) before `genesis_time`,
providing ample time to find peers and form initial connections and gossip subnets prior to genesis.
## Compression/Encoding
### Compression/Encoding
### Why are we using SSZ for encoding?
#### Why are we using SSZ for encoding?
SSZ is used at the consensus layer, and all implementations should have support for SSZ-encoding/decoding,
requiring no further dependencies to be added to client implementations.
@ -1533,7 +1533,7 @@ The actual data in most protocols will be further compressed for efficiency.
SSZ has well-defined schemas for consensus objects (typically sent across the wire) reducing any serialization schema data that needs to be sent.
It also has defined all required types that are required for this network specification.
### Why are we compressing, and at which layers?
#### Why are we compressing, and at which layers?
We compress on the wire to achieve smaller payloads per-message, which, in aggregate,
result in higher efficiency, better utilization of available bandwidth, and overall reduction in network-wide traffic overhead.
@ -1563,13 +1563,13 @@ This looks different depending on the interaction layer:
implementers are encouraged to encapsulate the encoding and compression logic behind
MessageReader and MessageWriter components/strategies that can be layered on top of the raw byte streams.
### Why are we using Snappy for compression?
#### Why are we using Snappy for compression?
Snappy is used in Ethereum 1.0. It is well maintained by Google, has good benchmarks,
and can calculate the size of the uncompressed object without inflating it in memory.
This prevents DOS vectors where large uncompressed data is sent.
### Can I get access to unencrypted bytes on the wire for debugging purposes?
#### Can I get access to unencrypted bytes on the wire for debugging purposes?
Yes, you can add loggers in your libp2p protocol handlers to log incoming and outgoing messages.
It is recommended to use programming design patterns to encapsulate the logging logic cleanly.
@ -1580,7 +1580,7 @@ you can use logging facilities in those frameworks/runtimes to enable message tr
For specific ad-hoc testing scenarios, you can use the [plaintext/2.0.0 secure channel](https://github.com/libp2p/specs/blob/master/plaintext/README.md)
(which is essentially no-op encryption or message authentication), in combination with tcpdump or Wireshark to inspect the wire.
### What are SSZ type size bounds?
#### What are SSZ type size bounds?
The SSZ encoding outputs of each type have size bounds: each dynamic type, such as a list, has a "limit", which can be used to compute the maximum valid output size.
Note that for some more complex dynamic-length objects, element offsets (4 bytes each) may need to be included.
@ -1589,7 +1589,7 @@ Other types are static, they have a fixed size: no dynamic-length content is inv
For reference, the type bounds can be computed ahead of time, [as per this example](https://gist.github.com/protolambda/db75c7faa1e94f2464787a480e5d613e).
It is advisable to derive these lengths from the SSZ type definitions in use, to ensure that version changes do not cause out-of-sync type bounds.
# libp2p implementations matrix
## libp2p implementations matrix
This section will soon contain a matrix showing the maturity/state of the libp2p features required
by this spec across the languages in which clients are being developed.