$$ \newcommand \WS {\mathrm{WS}} \newcommand \PtoP {\mathrm{P2P}} \newcommand \PtoPNet {\mathcal{N}_P} \newcommand \Peer {\mathrm{Peer}} \newcommand \Tag {\mathrm{tag}} \newcommand \PeerNode {\mathcal{P}} $$

P2P Network Definition

The Peer-to-Peer Network is currently in experimental mode!

Let’s define \( \PtoPNet \) as an object that models a working Peer-to-Peer Network \( \PtoP \).

A minimal \( \PtoPNet \) should have:

• A GenesisID identifying which network it is a part of (see Ledger specifications),

• A PeerStore container to keep peer data and expose relevant connection metadata (see Peer management section),

• A Broadcaster to send messages to the network,

• A topicTags mapping of the form (protocolTag -> string), which represents which \( \Tag \) to use with GossipSub, mapped to topic names¹.

• A set of primitives taken or adapted from the Relay Network \( \WS \) and \( \Peer \), to support \( \WS \) messages:

  • The generic MessageHandler to route \( \WS \) messages to the appropriate message handler,
  • \( \Peer \) connectivity monitoring utilities,
  • A mapping of PeerID to \( \WS \) peers, and a mapping of \( \WS \) peers to PeerID (this is to get \( \mathcal{O}(1) \) lookup in both ways),

• A flag indicating if the node wants to receive TX tagged messages (transactions) or not,

• A capabilitiesDiscovery structure abstracting all functionalities to advertise nd discover peers for specific capabilities (see section below).

A \( \PtoP \) network implements the GossipNode interface to manage peer-to-peer communication.

⚙️ IMPLEMENTATION

\( \PtoP \) network reference implementation.

Currently, transactions are distributed using the GossipSub protocol (/meshsub/1.1.0). All other messages are forwarded over a stream /algorand-ws/1.0.0 that uses the same message serialization as the existing Relay Network implementation. These two streams are multiplexed over a single connection.

For more information on GossipSub, refer to the libp2p specifications.

P2P Network Topology

The following sketch represents a typical topology of a Peer-to-Peer Network \( \PtoPNet \), where:

• \( \PeerNode \) represents a peer node,
• \( \PeerNode_p \) represents a peer node connected to \( \PeerNode \),
• A \( \PeerNode_p \) is connected on average to \( 4 \PeerNode \).

pubsub for Transaction Dissemination

The publishing/subscribing (pubsub) protocol is a system where peers congregate around topics they are interested in.

Peers interested in a topic (identified by a simple string) are said to be subscribed to that topic.

Functionally, topics can be thought of as generators of sub-networks: peers subscribed to a topic are discoverable and addressable by other peers capable of serving data about that topic.

For more information on pubsub protocol, refer to the libp2p specifications.

The topic used to subscribe to transaction gossiping is algotx01.

The naming convention used for the topics is: the word algo, followed by a 2-byte protocol \( \Tag \) (TX in this case) followed by the 2-byte version identifier (01 in this case).

⚙️ IMPLEMENTATION

Pubsub protocol reference implementation.

The makePubSub(.) function initializes the pubsub protocol with a list of options that set parameters for peer scoring, topic filters, message validation, and subscription handling.

• Peer Scoring: sets peer score parameters, like the FirstMessageDeliveriesWeight, which scores peers based on the promptness of message delivery,

• Subscription Filters: limits subscriptions to the algotx01 topic,

• Validation Queue Size: configures the validation queue².

The pubsub protocol makes use of the following functions:

• Publish(topic string, data []byte): Sends data to a specific topic’s subscribers. After verifying that the topic exists, the data is propagated across the network.

• ListPeersForTopic(topic string) -> []PeerID: Retrieves a list of peers currently subscribed to a given topic, making it accessible to other parts of the network layer.

• Subscribe(topic string): Subscribes to a topic, advertising the network about peer’s intention of sending and receiving data on the topic.

• getOrCreateTopic(topicName string): Attempts to fetch the topic if already mapped, otherwise it creates a local register of it and joins its subscribers.

pubsub Message Validation

The following is an enumeration of pubsub message validation results (where ValidationResult is an alias for a signed integer):

• ValidationAccept(0) indicates a valid message that should be accepted, delivered to the application, and forwarded to the network.

• ValidationReject(1) indicates an invalid message that should not be delivered to the application or forwarded to the network. Furthermore, the peer that forwarded the message should be penalized by peer-scoring routers.

• ValidationIgnore(2) and validationThrottled(-1) are libp2p internals that should not be exposed.

⚙️ IMPLEMENTATION

Pubsub protocol message validation libp2p extrenal implementation.

Node Capabilities

With direct \( \PtoP \) network support, the notion of node capabilities acquires importance.

The capabilities of a \( \PtoP \) node are:

• Archival: holds the entire history of the blockchain,

• Catchpoint Storing: stores catch-point files and provides catch-point labels to node synchronizing with the network using a fast catch-up.

• Gossip: act as a permissionless relay node, able to perform network-level validation of messages and efficiently route them to peers.

Each node advertises its capabilities and keeps track of peers in a distributed hash table.

⚙️ IMPLEMENTATION

\( \PtoP \) node capabilities reference implementation.

Distributed Hash Table (DHT)

Peer-to-Peer networks, such as IPFS, use distributed hash tables (DHT) to look up files in the network. A DHT is a distributed system for mapping keys to values, storing resource locations throughout the network.

IPFS DHT is based on the Kadmelia algorithm, as a fundamental component for the content routing system, and acts like a cross between a catalog and a navigation system. It maps what users want to the peers storing the matching content.

The Algorand node reference implementation (go-algorand) uses Kadmelia DHT, to keep track of the peers’ capabilities.

⚙️ IMPLEMENTATION

DHT reference implementation.

1. Currently, TX tagged messages go into the algotx01 topic name. ↩

2. The current implementation allows up to \( 256 \) messages awaiting validation. ↩