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 #1459 from status-im/more-roots 

hash cleanups
This commit is contained in:
Danny Ryan 2019-11-04 04:01:05 +08:00 committed by GitHub
parent 26715877c6 af5238ad9a
commit 6a90949856
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
specs/networking/p2p-interface.md
View File

@ -320,7 +320,7 @@ Here, `result` represents the 1-byte response code.
The token of the negotiated protocol ID specifies the type of encoding to be used for the req/resp interaction. Two values are possible at this time: The token of the negotiated protocol ID specifies the type of encoding to be used for the req/resp interaction. Two values are possible at this time:
- `ssz`: the contents are [SSZ-encoded](../simple-serialize.md). This encoding type MUST be supported by all clients. For objects containing a single field, only the field is SSZ-encoded not a container with a single field. For example, the `BeaconBlocksByRoot` request is an SSZ-encoded list of `Hash`'s. - `ssz`: the contents are [SSZ-encoded](../simple-serialize.md). This encoding type MUST be supported by all clients. For objects containing a single field, only the field is SSZ-encoded not a container with a single field. For example, the `BeaconBlocksByRoot` request is an SSZ-encoded list of `Bytes32`'s.
- `ssz_snappy`: The contents are SSZ-encoded and then compressed with [Snappy](https://github.com/google/snappy). MAY be supported in the interoperability testnet; MUST be supported in mainnet. - `ssz_snappy`: The contents are SSZ-encoded and then compressed with [Snappy](https://github.com/google/snappy). MAY be supported in the interoperability testnet; MUST be supported in mainnet.
#### SSZ-encoding strategy (with or without Snappy) #### SSZ-encoding strategy (with or without Snappy)
@ -344,20 +344,20 @@ constituents individually as `response_chunk`s. For example, the
Request, Response Content: Request, Response Content:
``` ```
( (
head_fork_version: bytes4 head_fork_version: Bytes4
finalized_root: bytes32 finalized_root: Bytes32
finalized_epoch: uint64 finalized_epoch: uint64
head_root: bytes32 head_root: Bytes32
head_slot: uint64 head_slot: uint64
) )
``` ```
The fields are: The fields are, as seen by the client at the time of sending the message:
- `head_fork_version`: The beacon_state `Fork` version. - `head_fork_version`: The beacon_state `Fork` version.
- `finalized_root`: The latest finalized root the node knows about. - `finalized_root`: `state.finalized_checkpoint.root` for the state corresponding to the head block.
- `finalized_epoch`: The latest finalized epoch the node knows about. - `finalized_epoch`: `state.finalized_checkpoint.epoch` for the state corresponding to the head block.
- `head_root`: The block hash tree root corresponding to the head of the chain as seen by the sending node. - `head_root`: The signing root of the current head block.
- `head_slot`: The slot corresponding to the `head_root`. - `head_slot`: The slot of the block corresponding to the `head_root`.
The dialing client MUST send a `Status` request upon connection. The dialing client MUST send a `Status` request upon connection.
@ -403,7 +403,7 @@ The response MUST consist of a single `response_chunk`.
Request Content: Request Content:
``` ```
( (
head_block_root: Hash head_block_root: Bytes32
start_slot: uint64 start_slot: uint64
count: uint64 count: uint64
step: uint64 step: uint64
@ -441,7 +441,7 @@ Request Content:
``` ```
( (
[]Hash []Bytes32
) )
``` ```