Minimum libp2p requirements

[djrtwo]

It came to my attention that the best way to proceed for our client implementers is to define the minimum requirements that everyone will need from libp2p. Once we do this, we can create a living document in eth2.0/specs.

@ChihChengLiang pointed me to this document that the python research team created https://notes.ethereum.org/rKL3yiLcRKepNxGHReBsKg

Can anyone confirm that this is the minimum functionality that we need? And if not, what is missing?

[djrtwo]

@mhchia confirmed that this doc represents the components that he thought were necessary for implementations to get started.

@raulk Can you confirm that there is not anything missing that we might require.

[raulk]

@djrtwo From my point of view.

minimal libp2p implementation (very much coherent with what the document outlined):

• multiaddr, multihash.
• protocol muxer: multistream(-select).
• stream muxer: mplex.
• security: SecIO.
• transports: TCP.
• network abstraction: switch/swarm.
• peerstore: local database backed (kv store, or sqlite).
• protocols: ping, identify.
• host abstraction.
• NAT management / hole punching.

high-level protocols required for Serenity:

• pubsub: floodsub and gossipsub, with signed message records.
• content routing (DHT): kad-dht (maybe not a priority if Serenity won't be using it).
• discovery: backed by kad-dht find_node, or whatever is chosen (e.g. passive discovery via periodic gossip).

---

I think the above covers the needs for a basic implementation in the context of Serenity. It's a solid foundation to continue building further modules:

• stream muxer: yamux.
• connection manager: it'll undergo major changes soon.
• more transports: QUIC (definitely worth looking into), UDP, WS.
• local discovery: mDNS.
• crypto: tls 1.3.
• protector (pnet).
• circuit relays.
• autonat, autorelay.

---

EDIT: In my original response, I had forgotten to add the mplex stream muxer as the simplest implementation of a multiplexer. Fixed.