libp2p is the ultimate Web3.0 library of choice for decentralised process addressing. In this module, you will hear about all of libp2p’s modular and composable building blocks for P2P networking, which include:
- Transport protocols, pubsub protocols and multiplexers
- Secure channels and NAT Traversal
- Peer discovery, content- and peer-routing
2. ➔ Why libp2p? Decentralized Process Addressing
➔ libp2p: From modules to innovation
➔ libp2p modules
◆ Transports
◆ Multiplexers
◆ Secure Channels
◆ Peer Discovery
◆ Content and Peer Routing
◆ NAT Traversal
◆ PubSub
➔ Pluggable modules
Agenda
3. Composable building blocks to assemble future-proof p2p networking layers
Runs on many runtimes: browser, mobile, embedded.
Substrate for innovation on new protocols (composable modules)
Implemented in 7+ languages
A modular peer-to-peer networking stack
4. Decentralized Process Addressing
Why?
● Ability to locate, connect, authenticate, negotiate and interact
efficiently with any process in the world
○ Independent of the runtime
○ In a seamless manner (NAT-traversal, heterogeneous networks,
relays).
○ Fully operational even in a case of mobility, relocation, roam, etc.
○ Every peer is uniquely identified.
● Network- and topology-independent alternative to endpoint addressing
(e.g. IP networks)
5. Where does libp2p live?
Where?
Data-link Layer
Physical Layer
Transport
6. Networking
Innovation
● libp2p’s modular protocol stack
fosters innovation through the design
of new protocols and layers.
● It provides all the interfaces required
for fast implementation.
● The substrate for new applications
and protocols.
● Recent example: Compression in
libp2p
From modules to innovation
(and back)
libp2p protocol layers
Security (Noise / TLS)
Transport (TCP / UDP /
QUIC)
Muxer (yamux / multiplex)
Application protocols
https://github.com/adlrocha/go-libp2p-c
ompression-examples
Security (Noise / TLS)
Transport (TCP / UDP /
QUIC)
Muxer (yamux / multiplex)
Application protocols
Compression (gzip)
7. Decentralized Process Addressing
Peer Identity
● Uniquely identifies peers
● IDs derived from their public key
○ Four key types: RSA, Ed25519, SEC256k1, ECDSA
○ Multihash representation
■ Identity multihash (i.e. no hash) if public key < 48 bytes
■ SHA-256 of multihash if > 48 bytes
Multiaddress
/ip4/1.2.3.4/tcp/5001/p2p/<peer_id>
● Network processes are named as filepaths.
● Specify available processes in a peer in a single address
● Used for dialing peer
Hash code Hash bytes
QmSoLPppuBtQSGwKDZT2M73ULpjvfd3aZ6ha4oFGL1KrGM
10. Transports
● Transports are core abstractions of libp2p
○ Connection factories for communication
between peers (i.e. establish new connections
over specific protocol)
○ Dialing and listening
○ They produce raw connections, socket,
sessions - the “L4” of libp2p
● Current transports:
○ TCP, QUIC, WebSockets, WebRTC
11. ● Connection bootstrapping takes a raw connection, created by a
transport, and “upgrades it” to use a secure channel and multiplexer.
○ The secure channel and multiplexer are negotiated dynamically
to create a capable connection between two peers.
● Some transports don’t need upgrading.
○ QUIC handles multiplexing and encryption itself.
● All of this negotiation is done to bootstrap a connection using a
protocol called multistream-select.
Connection Bootstrapping
14. Multiplexing
● Establishing a P2P connection may not be cheap or easy (e.g. hole punching,
negotiation, handshake, etc.)
● Re-use established connections for several protocols.
○ Applications can leverage already established connections.
● Streams are uniquely identified based on its multiplexer specification.
● Several implementations of multiplexers available:
○ Language specific libraries for stream multiplex (Yamux, Mplex)
○ Transport protocol native multiplexing capabilities (QUIC)
15. Protocol Negotiation
● Multistream-select is the protocol negotiation scheme. Blind
scheme used for connection upgrade.
● We can also identify the protocols other peers are running with:
○ Identify protocol which is run after connection upgrade.
Returns list of supported protocols
○ Multistream list (ls) protocol
>>> /multistream/1.0.0 (1)
<<< /multistream/1.0.0 (2)
>>> /foo/A (3)
<<< na (4)
>>> /foo/B (5)
<<< /foo/B (6)
>>> /ls
● Protocol IDs
○ Analogous to REST endpoints. Serve for routing and handling
○ As simple as mounting handlers for additional protocols
• /floodsub/1.0.0
•/ipfs/bitswap/1.0.0
•/eth2/beacon_chain/req/..
17. Secure Channels
● Peer authentication and transport encryption.
● Transmission integrity. Non repudiation.
Message authentication
○ Does not preclude from
encrypting/signing application data
● Several security protocols supported:
○ Noise: Security framework. Handshake
and negotiate primitives.
○ TLS 1.3
19. Peer Discovery
● Two discovery interfaces:
○ Advertiser to announce services
to other peers
○ Discoverer to find peers
supporting certain services
● Implementations
○ MDNS
○ Kademlia DHT
// Advertiser is an interface for advertising services
type Advertiser interface {
// Advertise advertises a service
Advertise(ns string, opts ...Option) (time.Duration, error)
}
// Discoverer is an interface for peer discovery
type Discoverer interface {
// FindPeers discovers peers providing a service
FindPeers(ns string, opts ...Option) (peer.AddrInfo, error)
}
// Discovery is an interface that combines service advertisement
and peer discovery
type Discovery interface {
Advertiser
Discoverer
}
20. Content and Peer Routing
● Interfaces to find and advertise
○ Content-addressed chunks of data in a p2p network
○ Peer multiaddrs: libp2p-kad-dht
● This interface could implement other protocols:
○ DNS
○ BitTorrent trackers
○ Any other providing subsystems
22. NAT Traversal
● Goal: Achieve global connectivity in heterogeneous networks.
● AutoNAT
○ Request information from other peers to identify how is my network
observed from the outside.
○ It determines if we’re actually reachable and reports a routability:
PUBLIC, PRIVATE, UNKNOWN.
● AutoRelay
○ If a peer is not reachable from a public network:
■ It tries to discover relay peers automatically
■ It connects to them, and advertises the relays addresses as part
of their own address (so others know how to reach it)
■ From there on other know how to contact me through the relay
○ Doesn’t scale well.
23. ● Hole punching
○ Use relay servers as a conduit for hole punching signalling and
sync.
○ Find close peers to our target to create temporary relayed
connections.
○ Detect NAT type and use hole punching to try to upgrade to direct
connection
NAT Traversal
25. ● PubSub is a message-oriented communication pattern.
● M:N interaction model. Asynchronous communication.
● Peers congregate around topics. Some processes publish messages and
others listen to them. Common in enterprise software with decentralized
brokers.
PubSub Interface
26. PubSub Interface
● Decentralized P2P PubSub.
○ Brokerless, self-regulating, no global knowledge
○ Constructed as overlay networks collaborating for message deliverability
● Several available protocols
○ GossipSub
○ FloodSub
● Use cases: IPNS, content-addressing, blockchain consensus, message
dissemination, etc.
28. ● libp2p modules are “plug and play”, they can be easily be added in an
application with a few lines of code.
○ Create libp2p node is simple
■ Supported transports, muxer, security channel
Pluggable modules
● If my application needs additional capabilities like peer discovery, routing, etc. we
don’t have to implement it from scratch:
host, err := libp2p.New(
context.Background(),
libp2p.ListenAddrs(sourceMultiAddr),
libp2p.Identity(prvKey),
)
// Instantiate DHT protocol (analogous for other modules).
newDHT, _ := kaddht.New(host)
host, err := libp2p.New(
context.Background(),
libp2p.ListenAddrs(sourceMultiAddr),
libp2p.Identity(prvKey),
libp2p.Routing(newDHT)
)
29. Thank you for watching
Reach out in case you have questions or comments!
