Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Apr20] 0.11.1 networking updates #832

Closed
18 tasks done
tersec opened this issue Mar 25, 2020 · 1 comment
Closed
18 tasks done

[Apr20] 0.11.1 networking updates #832

tersec opened this issue Mar 25, 2020 · 1 comment
Labels
:shipit: MVP
Milestone

Comments

@tersec
Copy link
Contributor

@tersec tersec commented Mar 25, 2020

Noise (https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/p2p-interface.md#mainnet-1):

  • The Libp2p-noise secure channel handshake with secp256k1 identities will be used for mainnet.

  • clients MUST support the XX handshake pattern

Snappy support (https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/p2p-interface.md#ssz-encoding-strategy-with-or-without-snappy):

  • If the Snappy variant is selected, we feed the serialized form of the object to the Snappy compressor on encoding. The inverse happens on decoding.

SSZ en/decoding (https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/p2p-interface.md#ssz-encoding-strategy-with-or-without-snappy):

  • A reader SHOULD NOT read more than max_encoded_len(n) bytes after reading the SSZ length prefix n from the header.

  • A reader SHOULD consider the following cases [...] as invalid input ... and "In case of an invalid input, a reader MUST" respond with nothing or InvalidRequest as appropriate.

  • 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.

BeaconBlocksByRange (https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/p2p-interface.md#beaconblocksbyrange):

  • 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.

  • The response MUST contain no more than count blocks.

  • Clients MUST respond with blocks from their view of the current fork choice. In particular, blocks from slots before the finalization MUST lead to the finalized block reported in the Status handshake.

Ping (https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/p2p-interface.md#ping):

  • If the peer does not respond to the Ping request, the client MAY disconnect from the peer.

  • The request MUST be encoded as an SSZ-field.

  • The response MUST consist of a single response_chunk.

GetMetaData (https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/p2p-interface.md#metadata and https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/p2p-interface.md#getmetadata):

  • Clients MUST locally store the [details in first link] MetaData

  • Once established the receiving peer responds with it's local most up-to-date MetaData. The response MUST be encoded as an SSZ-container.

  • The response MUST consist of a single response_chunk.

ENR (https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/p2p-interface.md#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 eth2 network. (Details in link)

  • Clients SHOULD connect to peers with fork_digest, next_fork_version, and next_fork_epoch that match local values.

  • Clients MAY connect to peers with the same fork_digest but a different next_fork_version/next_fork_epoch. 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.

@zah
Copy link
Member

@zah zah commented Mar 25, 2020

I'll take care for "SSZ en/decoding" changes.

@tersec tersec changed the title 0.11.0 networking updates 0.11.1 networking updates Mar 27, 2020
@kdeme kdeme mentioned this issue Apr 2, 2020
9 tasks
@tersec tersec added this to the Apr 2020 milestone Apr 2, 2020
@mratsim mratsim changed the title 0.11.1 networking updates [Apr20 - MVP] 0.11.1 networking updates Apr 3, 2020
@mratsim mratsim added the :shipit: MVP label Apr 7, 2020
@mratsim mratsim changed the title [Apr20 - MVP] 0.11.1 networking updates [Apr20] 0.11.1 networking updates Apr 7, 2020
@zah zah closed this as completed Jun 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:shipit: MVP
Projects
None yet
Development

No branches or pull requests

3 participants