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 #1828 from ethereum/gossipv1.1-id 

Bump gossipsub protocol id to /meshsub/1.1.0
This commit is contained in:
Danny Ryan 2020-05-19 10:49:04 -06:00 committed by GitHub
parent 095b87c2a2 fdc7e846df
commit dbb1ee60b4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -178,7 +178,7 @@ Where
Clients MUST support the [gossipsub v1](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) libp2p protocol including the [gossipsub v1.1](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md) extension.
**Protocol ID:** `/meshsub/1.0.0`
**Protocol ID:** `/meshsub/1.1.0`
**Gossipsub Parameters**
@ -218,8 +218,6 @@ where `base64` is the [URL-safe base64 alphabet](https://tools.ietf.org/html/rfc
The payload is carried in the `data` field of a gossipsub message, and varies depending on the topic:
| Name | Message Type |
|------------------------------------------------|-------------------------|
| Name | Message Type |
|----------------------------------|---------------------------|
| `beacon_block` | `SignedBeaconBlock` |
@ -552,7 +550,7 @@ Clients MUST order blocks by increasing slot number.
Clients MUST respond with blocks from their view of the current fork choice -- that is, blocks from the single chain defined by the current head. Of note, blocks from slots before the finalization MUST lead to the finalized block reported in the `Status` handshake.
Clients MUST respond with blocks that are consistent from a single chain within the context of the request. 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.
Clients MUST respond with blocks that are consistent from a single chain within the context of the request. 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