# 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](https://tools.ietf.org/html/rfc2119).

## Motivation

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

### Message structure

An Eth 2.0 message consists of an envelope that defines the message's compression, encoding, and length followed by the body itself.

Visually, a message looks like this:

```
+--------------------------+
|    compression nibble    |
+--------------------------+
|    encoding nibble       |
+--------------------------+
|  body length (uint64)    |
+--------------------------+
|                          |
|           body           |
|                          |
+--------------------------+
```

Clients MUST ignore messages with malformed bodies. The compression/encoding nibbles MUST be one of the following values:

### Compression nibble values

- `0x0`: no compression

### Encoding nibble values

- `0x1`: SSZ