Low-level transport protocol based on TLS+yamux

The current devp2p stack provides an inefficient interface to protocol applications that end up having to use a fixed message format to communicate. This is due to the fact that the layers that compose the stack are not independent from each other. This document proposes a different modular stack based on the abstraction layers mechanism followed in the OSI network protocol stack.

In the OSI model [[1]](https://en.wikipedia.org/wiki/OSI_model), different protocols are built one under another, each layer designed with a single purpose in mind. This modularization makes design and evaluation easier. Upper layers are unaware about the logic of lower layers and communicate with a specific interface. This transparency makes it possible to build FTP, DNS or TLS under the same TCP interface.

The new proposed stack has two layers. First, the security layer establishes a secure connection with a remote peer, it is based on TLS. Second, once the connection is established the signal is multiplexed in different streams. Both of this layers take as input a batch of binary data without any specific format. Thus, it is possible to change any layer at any time. Application protocols can use this flexible input format to build any type of communication protocol: FTP, SSH, RPC or [[2]](https://github.com/ethereum/devp2p/issues/70).

## Objectives

- The transport protocol should care exclusively about securing a connection with the other peer and providing different streams for the protocols. It should not introduce any other logic like flow control, congestion avoidance... It should be up to the higher layers to introduce this logic if they require it on their application protocols.

- The transport protocol should be application protocol independent. Higher-level protocols can layer on top of it transparently.

## DevP2P

A small recap on the workings of devp2p. First, both peers start a handshake process to agree on a set of mac and cipher stream keys. Second, a secure transport connection is established with the former keys. Messages are sent with the format (code int, data bytes), each message is compressed, hashed with a mac and encrypted before being written to the insecure channel (RLPX protocol). Third, the peers agree on a set of protocols (i.e. eth64) and for each one start an independent stream on the secure channel (multiplexing). The protocols send messages to the stream also with the format (code, data). The code in the message is used to send the data to the correct stream.

### Limitations:

- Rlpx macs and encrypts all the message at the same time. This may be a burden for big messages.

- The upper protocols that use the transport (i.e. eth64) end up having to use a fixed message format (code, message). This limits their flexibility and the type of communication they can use.

## Proposal

This new transport proposal follows the same methodology as devp2p but applies a different set of protocols for each layer.

Handshake is still TBD. It is assumed that the peers agree on a set of mac and cipher stream keys. Next, the TLS record protocol [[3]](https://docs.microsoft.com/en-us/windows/desktop/secauthn/tls-record-protocol) secures the application data. It behaves similar to RLPX, it macs and encrypts the data and then writes it to the insecure connection. However, the main benefit is that it divides the outgoing message into manageable blocks and reassembles incoming messages. Thus, it consumes less memory. The only input the record protocol takes is a message (bytes) to be transmitted.

We then use the yamux protocol [[4]](https://github.com/hashicorp/yamux/blob/master/spec.md) to multiplex the secure signal into different streams. Those streams are the ones exposed to the upper layers (protocols). Again, the created streams only take bytes as input.

### Benefits

- It provides a flexible interface for the protocol backends to implement any type of exchange mechanism (i.e. rpc, pub/sub).

- It uses well known and production hardened protocols (TLS record and yamux).

- Encrypting and sending data in blocks makes it more performant in terms of speed and memory. Benchmarks show that TLS is 10x faster than RLPX.

- Every major language has already optimal implementations of TLS and the record protocol.

- It would be faster and easier to build new protocols [[5]](https://github.com/yperbasis/silkworm/blob/master/doc/sync_protocol.pdf).

### References

[1]. https://en.wikipedia.org/wiki/OSI_model
[2]. https://github.com/ethereum/devp2p/issues/70
[3]. https://docs.microsoft.com/en-us/windows/desktop/secauthn/tls-record-protocol
[4]. https://github.com/hashicorp/yamux/blob/master/spec.md
[5]. https://github.com/yperbasis/silkworm/blob/master/doc/sync_protocol.pdf