Networking

Overview of the Othentic peer-to-peer protocol and components

Overview

Othentic Stack peer-to-peer networking layer utilizes the libp2p open-source library.

The layer provides essential networking primitives, including peer discovery, connection management, and secure messaging. The layer employs signature-based authentication to manage peer connectivity and handshaking and ensure that only valid peers communicate, thereby enhancing security.

Network Types

Networks utilizing the Othentic Stack can be categorized as:

• Permissionless: Any participant who (re)stakes tokens can register as an Operator.

• Whitelisted: Access is restricted to approved participants.

Peer Discovery

Peer discovery in the Othentic Stack is implemented using bootstrap nodes, and supports a discovery layer utilizing a distributed hash table (DHT) based on the Kademlia algorithm. The DHT allows for efficient storage and retrieval of peer information, including addresses and availability.

Message Propagation

Messages within the network are propagated using Gossipsub, a gossip protocol that abstracts complexities related to network communication, encryption, handshakes, and data serialization/deserialization.

Learn more about libp2p

---

Node Identifiers

When a node starts, the layer generates a unique identifier known as PeerId. These PeerIds—along with other transport information—are used to identify nodes in the network. Each node's identifiers are represented as Multiaddr strings, facilitating connections to predefined peers during startup. An example of a node identifier is:

/ip4/99.83.190.102/tcp/9876/p2p/12D3KooWBNFG1QjuF3UKAKvqhdXcxh9iBmj88cM5eU2EK5Pa91KB

Upon startup, nodes log their identifiers for reference.

DNS identifiers

When providing bootstrap peers as part of starting the node, it's possible to provide a DNS name instead of an IP, using the following format:

/dnsaddr/othentic.xyz/tcp/9876/p2p/12D3KooWBNFG1QjuF3UKAKvqhdXcxh9iBmj88cM5eU2EK5Pa91KB

When using /dnsaddr/, we recommend adding an explicit, comma-separated /ip4/ address with the resolved DNS IP. This improves connectivity and ensures compatibility with different discovery mechanisms, as some peers might rely on direct IP resolution while others use DNS-based discovery.

Example:

/dnsaddr/othentic.xyz/tcp/9876/p2p/12D3KooWBNFG1QjuF3UKAKvqhdXcxh9iBmj88cM5eU2EK5Pa91KB,  
/ip4/99.83.190.102/tcp/9876/p2p/12D3KooWBNFG1QjuF3UKAKvqhdXcxh9iBmj88cM5eU2EK5Pa91KB

This approach helps mitigate issues where /dnsaddr/ resolution is not supported or inconsistently handled across different libp2p implementations.

---

Bootstrap nodes

Bootstrap nodes (aka "Bootnodes") are used for discovering initial peers by new participants on the network.

An AVS network must have at least one bootstrap node with high availability so that new nodes / Operators can join the network. Anyone can run a bootnode, but it's recommended to keep at least one operating at high availability with a well-known IP.

Using the Aggregator node (see Node Operators) as a bootstrap node, is usually recommended.

---

Transport and Persistence Store

The Othentic Stack supports TCP transport.

PeerStore

Nodes can opt for a persistent record of peers for caching purposes. Activating this feature enables nodes to reconnect to previously discovered peers upon startup.

Attestations

Aggregator nodes can opt to keep a persistent record of attestations. This is useful in cases where the aggregator might sporadically restart while in the middle of receiving attestations. If not enabled, attestations which were kept in-memory will be discarded. This can prevent tasks from being submitted if the necessary attestations were discarded and will require re-submission of the task.

---

Topics and messages

The Othentic consensus mechanism employs a pub-sub protocol that includes several message types, such as:

• othentic.p2p.task

• othentic.p2p.attestation

• othentic.p2p.task_submitted

• othentic.p2p.custom_message

All messages are serialized using Protobuf, with definitions provided for each message type below.

othentic.p2p.task

This message encodes a signed task along with all the necessary data. Task Performers publish this message either directly to the P2P network or via an RPC node using the sendTask method.

message TaskProto {
  string signature = 1; // The signature of the performer
  string performer = 2; // The address of the performer 
  string proofOfTask = 3; // A proof associated with the task
  string data = 4;
  uint32 definitionId = 5; // An identifier to the specific task definition Id
}

othentic.p2p.attestation

This message encodes a signed attestation for a specific task. Every attester sends this message over the P2P network after validating an incoming task.

message AttestationProto {
  message PerformerProto {
    string address = 1; 
    string signature = 2; 
  }

  message AttesterProto {
    message AttestationSigProto {
      string x = 1;
      string y = 2;
    }

    string address = 1;
    AttestationSigProto signature = 2;
  }

  string proofOfTask = 1;
  string data = 2;
  PerformerProto performer = 3;
  AttesterProto attester = 4;
  bool isApproved = 5;
  uint32 definitionId = 6;
}

othentic.p2p.task_submitted

This message contains the details of a submitted task and is published by an Aggregator once the task submission is confirmed on-chain. Its primary purpose is to notify other nodes that they can remove this task from their memory, but it can also be used for monitoring purposes.

message AttestationProto {
  string taskId = 1;
  string txHash = 2; 
  string performerAddress = 3; // Address of the task performer
  repeated uint32 operatorIds = 4; // List of operator IDs who attested
  uint32 definitionId = 5;
  bool isApproved = 6;
}

othentic.p2p.custom_message

The message encodes a string of arbitrary bytes, allowing anyone on the P2P network to publish it. The data contained within this message is forwarded to the Validation Service for processing. This capability enables customised communication among nodes, facilitating various use cases within the network. For more information about its configuration and usage, refer to Custom P2P Messaging.

This feature needs to be specifically enabled by the AVS network

message CustomMessageProto {
  string data = 1;
}