# Week 6 Updates

- Deep dive into the componenets of libp2p and Prysm:-

**multiaddr**
The p2p multiaddr

libp2p defines the `p2p` multiaddr protocol, whose address component is the
[peer id][peer-id-spec] of a libp2p peer. The text representation of a `p2p`
multiaddr looks like this:

/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N

Where `QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N` is the string representation
of a peer's peer ID derived from its public key.

By itself, a `p2p` address does not give you enough addressing information to
locate a peer on the network; it is not a transport address. However, like the
`ws` protocol for WebSockets, a `p2p` address can be [encapsulated
within](#encapsulation) another multiaddr.

For example, the above `p2p` address can be combined with the transport address
on which the node is listening:

/ip4/198.51.100/tcp/1234/p2p/QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N

This combination of transport address plus `p2p` address is the format in which
peers exchange addresses over the wire in the [identify protocol][identify-spec]
and other core libp2p protocols.
### TCP

The libp2p TCP transport is supported in all implementations and can be used
wherever TCP/IP sockets are accessible.

Addresses for the TCP transport are of the form `<ip-multiaddr>/tcp/<tcp-port>`,
where `<ip-multiaddr>` is a multiaddr that resolves to an IP address, as
described in the [IP and Name Resolution section](#ip-and-name-resolution).
The `<tcp-port>` argument must be a 16-bit unsigned integer.
### QUIC

QUIC sessions are encapsulated within UDP datagrams, and the libp2p QUIC
multiaddr format mirrors this arrangement.

A libp2p QUIC multiaddr is of the form `<ip-multiaddr>/udp/<udp-port>/quic`,
where `<ip-multiaddr>` is a multiaddr that resolves to an IP address, as
described in the [IP and Name Resolution section](#ip-and-name-resolution).
The `<udp-port>` argument must be a 16-bit unsigned integer in network byte order.

**WebTransport**
While browsers perform HTTP request using HTTP/3, so far they don’t offer an API to allow applications to gain access to the underlying QUIC stream. WebTransport is a new specification that uses QUIC to offer an alternative to WebSocket.
For a standard WebSocket connection, the roundtrips required are as follows:

1 RTT for TCP handshake
1 RTT for TLS 1.3 handshake
1 RTT for WebSocket upgrade
1 RTT for multistream security negotiation (Noise or TLS 1.3)
1 RTT for security handshake (Noise or TLS 1.3)
1 RTT for multistream muxer negotiation (mplex or yamux)
In total, 6 RTTs.

WebTransport running over QUIC only requires 3 RTTs, as:

1 RTT for QUIC handshake
1 RTT for WebTransport handshake
1 RTT for libp2p handshake; one for multistream and one for authentication (with a Noise handshake)
**Quic**
QUIC is a new transport protocol that provides an always-encrypted, stream-multiplexed connection built on top of UDP
Comparing HTTP/2 and HTTP/3
In addition to defining the QUIC transport, the IETF also standardized a new version of HTTP that runs on top of QUIC: HTTP/3 ( RFC 9114). HTTP/3 combines the advantages of the existing transfer protocols HTTP/2 and HTTP over QUIC in one standard for faster and more stable data transmission.The following diagram illustrates the OSI model for HTTP/2 and HTTP/3:


**Noise in libp2p**
libp2p uses the Noise Protocol Framework to encrypt data between nodes and provide forward secrecy. noise-libp2p is an implementation of the Noise Protocol Framework used to establish a secure channel between two peers by exchanging keys and encrypting traffic during the libp2p handshake process. After a successful Noise handshake, the resulting keys send ciphertext messages back and forth over the secure channel. The wire format for these messages and the cryptographic primitives used for encryption is specified in the libp2p-noise specification.

The noise-libp2p protocol ID is /noise, and future versions may define new protocol IDs using the “/noise” prefix (e.g., /noise/2).

**Early muxer negotiation**
The libp2p project eliminates an unnecessary round trip in the standard negotiation protocol for selecting a stream multiplexer. This is achieved by combining the steps of agreeing on a secure channel and multiplexer. This is called “early” or “inlined” muxer negotiation.

Early muxer negotiation is a feature in libp2p that allows for the simultaneous selection of a stream multiplexer during the cryptographic handshake of the TLS and Noise security protocols. This is achieved by sharing a list of supported muxer protocols as a part of the handshake payload.

For example, if a libp2p node supports mplex and yamux, it will advertise both in the list. This eliminates an extra round trip, improving TTFB (time to first byte) in the libp2p handshake. Currently, this feature is only supported in go-libp2p and for TCP and WebSocket transports that do not have native encryption or multiplexing.

**Stream Multiplexers in libp2p**
Stream muxers are a key component of the libp2p stack, providing pluggable multiplexing capabilities for peers. libp2p hosts can support multiple muxers simultaneously, and the choice of muxer is negotiated between the nodes during the initial connection handshake. This negotiation protocol allows libp2p to adopt new muxers in the future while maintaining backward compatibility with existing muxers
Currently, libp2p supports two stream muxers, mplex and yamux.

### Circuit Relay
Circuit relay is a transport protocol that routes traffic between two peers over a third-party “relay” peer.

In many cases, peers will be unable to traverse their NAT and/or firewall in a way that makes them publicly accessible. Or they may not share common transport protocols that would allow them to communicate directly.

To enable peer-to-peer architectures in the face of connectivity barriers like NAT, libp2p defines a protocol called p2p-circuit. When a peer isn’t able to listen on a public address, it can dial out to a relay peer, which will keep a long-lived connection open. Other peers will be able to dial through the relay peer using a p2p-circuit address, which will forward traffic to its destination.

**Relay addresses**
A relay circuit is identified using a multiaddr that includes the Peer ID of the peer whose traffic is being relayed (the listening peer or “relay target”).
Process
The below sequence diagram depicts a sample relay process:


-Node A is behind a NAT and/or firewall, e.g. detected via the AutoNAT service.
-Node A therefore requests a reservation with relay R. I.e. node A asks relay R to listen for incoming connections on its behalf.
-Node B wants to establish a connection to node A. Given that node A does not advertise any direct addresses but only a relay address, node B connects to relay R, asking relay R to relay a connection to A.
-Relay R forwards the connection request to node A and eventually relays all data send by A and B.

# Prysm Codebase
Started reviewing the Prysm codebase where libP2P is integrated. As of last week, I have covered the following files and directories:

- `beacon-chain/p2p`
- `beacon-chain/sync` and its subdirectories
- `cmd/prysmctl/p2p` and its subdirectories
- `crypto/ecdsa`
- `tools/bootnode`
- `tools/enr-calculator`
- `runtime/messagehandler`