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

Clean up remaining `[]` List syntax 

..and use List[byte, 256] for error message
This commit is contained in:
Jacek Sieka 2020-05-30 20:59:12 +02:00
parent 56309342c0
commit 33e115f8c6
No known key found for this signature in database
GPG Key ID: A1B09461ABB656B8
1 changed files with 11 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -150,6 +150,7 @@ This section outlines constants that are used in this spec.
| Name | Value | Description |
|---|---|---|
| `GOSSIP_MAX_SIZE` | `2**20` (= 1048576, 1 MiB) | The maximum allowed size of uncompressed gossip messages. |
| `MAX_REQUEST_BLOCKS` | `2**10` (= 1024) | Maximum number of blocks in a single request |
| `MAX_CHUNK_SIZE` | `2**20` (1048576, 1 MiB) | The maximum allowed size of uncompressed req/resp chunked responses. |
| `TTFB_TIMEOUT` | `5s` | The maximum time to wait for first byte of request response (time-to-first-byte). |
| `RESP_TIMEOUT` | `10s` | The maximum time for complete response transfer. |
@ -391,11 +392,11 @@ The `ErrorMessage` schema is:
```
(
error_message: Bytes32
error_message: List[byte, 256]
)
```
*Note*: By convention, the `error_message` is a sequence of bytes that can be interpreted as a UTF-8 string up to 32 bytes - a 0 byte shortens the string in this interpretation. Clients MUST treat as valid any bytes.
*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
@ -443,9 +444,9 @@ In case of an invalid input (header or payload), a reader MUST:
All messages that contain only a single field MUST be encoded directly as the type of that field and MUST NOT be encoded as an SSZ container.
Responses that are SSZ-lists (for example `[]SignedBeaconBlock`) send their
Responses that are SSZ-lists (for example `List[SignedBeaconBlock, ...]`) send their
constituents individually as `response_chunk`s. For example, the
`[]SignedBeaconBlock` response type sends zero or more `response_chunk`s. Each _successful_ `response_chunk` contains a single `SignedBeaconBlock` payload.
`List[SignedBeaconBlock, ...]` response type sends zero or more `response_chunk`s. Each _successful_ `response_chunk` contains a single `SignedBeaconBlock` payload.
### Messages
@ -528,7 +529,7 @@ Request Content:
Response Content:
```
(
[]SignedBeaconBlock
List[SignedBeaconBlock, MAX_REQUEST_BLOCKS]
)
```
@ -545,7 +546,7 @@ The response MUST consist of zero or more `response_chunk`. Each _successful_ `r
Clients MUST keep a record of signed blocks seen since the since the start of the weak subjectivity period and MUST support serving requests of blocks up to their own `head_block_root`.
Clients MUST respond with at least the first block that exists in the range, if they have it.
Clients MUST respond with at least the first block that exists in the range, if they have it, and no more than `MAX_REQUEST_BLOCKS` blocks.
The following blocks, where they exist, MUST be send in consecutive order.
@ -568,7 +569,7 @@ Request Content:
```
(
[]Root
List[Root, MAX_REQUEST_BLOCKS]
)
```
@ -576,12 +577,14 @@ Response Content:
```
(
[]SignedBeaconBlock
List[SignedBeaconBlock, MAX_REQUEST_BLOCKS]
)
```
Requests blocks by block root (= `hash_tree_root(SignedBeaconBlock.message)`). The response is a list of `SignedBeaconBlock` whose length is less than or equal to the number of requested blocks. It may be less in the case that the responding peer is missing blocks.
No more than `MAX_REQUEST_BLOCKS` may be requested at a time.
`BeaconBlocksByRoot` is primarily used to recover recent blocks (e.g. when receiving a block or attestation whose parent is unknown).
The request MUST be encoded as an SSZ-field.