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

Updates from review

This commit is contained in:
Matthew Slipper 2019-03-19 15:32:38 -07:00
parent 2dce326310
commit 472d9c5c20
2 changed files with 19 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
specs/networking/messaging.md
View File

@ -11,6 +11,8 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
This specification seeks to define a messaging protocol that is flexible enough to be changed easily as the ETH 2.0 specification evolves. This specification seeks to define a messaging protocol that is flexible enough to be changed easily as the ETH 2.0 specification evolves.
Note that while `libp2p` is the chosen networking stack for Ethereum 2.0, as of this writing some clients do not have workable `libp2p` implementations. To allow those clients to communicate, we define a message envelope that includes the body's compression, encoding, and body length. Once `libp2p` is available across all implementations, this message envelope will be removed because `libp2p` will negotiate the values defined in the envelope upfront.
# Specification # Specification
## Message Structure ## Message Structure

24
specs/networking/rpc-interface.md
View File

@ -34,7 +34,9 @@ A "Protocol ID" in `libp2p` parlance refers to a human-readable identifier `libp
## RPC-Over-`libp2p` ## RPC-Over-`libp2p`
To facilitate RPC-over-`libp2p`, a single protocol path is used: `/eth/serenity/beacon/rpc/1.0.0`. Remote method calls are wrapped in a "request" structure: To facilitate RPC-over-`libp2p`, a single protocol name is used: `/eth/serenity/beacon/rpc/1`. The version number in the protocol name is neither backwards or forwards compatible, and will be incremented whenever changes to the below structures are required.
Remote method calls are wrapped in a "request" structure:
``` ```
( (
@ -88,6 +90,10 @@ The first 1,000 values in `error.code` are reserved for system use. The followin
3. `20`: Method not found. 3. `20`: Method not found.
4. `30`: Server error. 4. `30`: Server error.
### Alternative for Non-`libp2p` Clients
Since some clients are waiting for `libp2p` implementations in their respective languages. As such, they MAY listen for raw TCP messages on port `9000`. To distinguish RPC messages from other messages on that port, a byte prefix of `ETH` (`0x455448`) MUST be prepended to all messages. This option will be removed once `libp2p` is ready in all supported languages.
## Messages ## Messages
### Hello ### Hello
@ -154,12 +160,13 @@ Once the handshake completes, the client with the higher `latest_finalized_epoch
) )
``` ```
Client MAY send `goodbye` messages upon disconnection. The reason field MUST be one of the following values: Client MAY send `goodbye` messages upon disconnection. The reason field MAY be one of the following values:
- `1`: Client shut down. - `1`: Client shut down.
- `2`: Irrelevant network. - `2`: Irrelevant network.
- `3`: Too many peers. - `3`: Fault/error.
- `4`: Fault/error.
Clients MAY define custom goodbye reasons as long as the value is larger than `1000`.
### Request Beacon Block Roots ### Request Beacon Block Roots
@ -168,7 +175,10 @@ Client MAY send `goodbye` messages upon disconnection. The reason field MUST be
**Request Body** **Request Body**
``` ```
() (
start_slot: uint64
count: uint64
)
``` ```
**Response Body:** **Response Body:**
@ -185,7 +195,7 @@ Client MAY send `goodbye` messages upon disconnection. The reason field MUST be
) )
``` ```
Send a list of block roots and slots to the requesting peer. Requests a list of block roots and slots from the peer. The `count` parameter MUST be less than or equal to `32768`.
### Beacon Block Headers ### Beacon Block Headers
@ -210,7 +220,7 @@ Send a list of block roots and slots to the requesting peer.
) )
``` ```
Requests beacon block headers from the peer starting from `(start_root, start_slot)`. The response MUST contain no more than `max_headers` headers. `skip_slots` defines the maximum number of slots to skip between blocks. For example, requesting blocks starting at slots `2` a `skip_slots` value of `2` would return the blocks at `[2, 4, 6, 8, 10]`. In cases where a slot is empty for a given slot number, the closest previous block MUST be returned. For example, if slot `4` were empty in the previous example, the returned array would contain `[2, 3, 6, 8, 10]`. If slot three were further empty, the array would contain `[2, 6, 8, 10]` - i.e., duplicate blocks MUST be collapsed. Requests beacon block headers from the peer starting from `(start_root, start_slot)`. The response MUST contain no more than `max_headers` headers. `skip_slots` defines the maximum number of slots to skip between blocks. For example, requesting blocks starting at slots `2` a `skip_slots` value of `1` would return the blocks at `[2, 4, 6, 8, 10]`. In cases where a slot is empty for a given slot number, the closest previous block MUST be returned. For example, if slot `4` were empty in the previous example, the returned array would contain `[2, 3, 6, 8, 10]`. If slot three were further empty, the array would contain `[2, 6, 8, 10]` - i.e., duplicate blocks MUST be collapsed. A `skip_slots` value of `0` returns all blocks.
The function of the `skip_slots` parameter helps facilitate light client sync - for example, in [#459](https://github.com/ethereum/eth2.0-specs/issues/459) - and allows clients to balance the peers from whom they request headers. Clients could, for instance, request every 10th block from a set of peers where each per has a different starting block in order to populate block data. The function of the `skip_slots` parameter helps facilitate light client sync - for example, in [#459](https://github.com/ethereum/eth2.0-specs/issues/459) - and allows clients to balance the peers from whom they request headers. Clients could, for instance, request every 10th block from a set of peers where each per has a different starting block in order to populate block data.