1.4 KiB
ETH 2.0 Networking Spec - Messaging
Abstract
This specification describes how individual Ethereum 2.0 messages are represented on the wire.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL”, NOT", “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
Motivation
This specification seeks to define a messaging protocol that is flexible enough to be changed easily as the ETH 2.0 specification evolves.
Specification
Message Structure
An ETH 2.0 message consists of a single byte representing the message version followed by the encoded, potentially compressed body. We separate the message's version from the version included in the libp2p protocol path in order to allow encoding and compression schemes to be updated independently of the libp2p protocols themselves.
It is unlikely that more than 255 message versions will need to be supported, so a single byte should suffice.
Visually, a message looks like this:
+--------------------------+
| version byte |
+--------------------------+
| |
| body |
| |
+--------------------------+
Clients MUST ignore messages with mal-formed bodies. The version byte MUST be one of the below values:
Version Byte Values
0x01
- Encoding Scheme: SSZ
- Compression Scheme: Snappy