Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

• Auto
• Light
• Dark

Algorand Specifications

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

Let’s define NPNP as an object that models a working Peer-to-Peer Network P2PP2P.

A minimal NPNP 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 tagtag to use with GossipSub, mapped to topic names1.

• A set of primitives taken or adapted from the Relay Network WSWS and PeerPeer, to support WSWS messages:

  • The generic MessageHandler to route WSWS messages to the appropriate message handler,
  • PeerPeer connectivity monitoring utilities,
  • A mapping of PeerID to WSWS peers, and a mapping of WSWS peers to PeerID (this is to get O(1)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 P2PP2P network implements the GossipNode interface to manage peer-to-peer communication.

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.

The following sketch represents a typical topology of a Peer-to-Peer Network NPNP, where:

• PP represents a peer node,
• PpPp represents a peer node connected to PP,
• A PpPp is connected on average to 4P4P.

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.

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 tagtag (TX in this case) followed by the 2-byte version identifier (01 in this case).

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 queue2.

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.

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.

With direct P2PP2P network support, the notion of node capabilities acquires importance.

The capabilities of a P2PP2P 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.

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.