Networking

Overview of the Othentic P2P protocol and components

Intro

Othentic P2P networking layer is based on the libp2p open-source library.

The protocol provides peer-to-peer networking primitives such as peer discovery, connection management, and secure messaging. The network relies on signature-based authentication to manage peer connectivity and handshaking, ensuring only valid peers can use the network.

Networks that are using the Othentic stack can be either permissionless—anyone that re-stakes tokens can register as an Operator for the network—or whitelisted.

Peer discovery is currently implemented using bootstrap nodes. While libp2p also supports a discovery layer using a distributed hash table (DHT) based on the Kademlia algorithm, the DHT provides a mechanism for storing information about other peers in the network, including their addresses and availability. Currently, Operator nodes do not support DHT; however, support is planned for future updates.

Messages are propagated to the network using Gossipsub, a Gossip protocol which abstracts the details of network communication, encryption, handshakes and serialization/deserialization of data.

Learn more about libp2p

Node identifiers

Libp2p generates a unique "PeerId" when a node starts up. These PeerIds—along with other transport information—are used to identify nodes on the network. Each node has its own identifiers in the form of Multiaddr strings. These identifiers are mainly used for bootstrapping connections to predefined peers when a node starts up.

A node identifier could look like so:

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

When a node starts up, it will log its identifiers.

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:

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

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.

It's usually recommended to use the Aggregator node (see Node Operators) as a bootstrap node, but this is not strictly necessary.

Transports

While libp2p supports different transport types, Othentic stack currently support only TCP transport.

Persistency

PeerStore

Nodes can opt to keep a persistent record of peers for caching purposes. Enabling this feature means nodes will attempt to reconnect to previously discovered peers on 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 is facilitated by a pub-sub protocol composed of several messages, namely the othentic.p2p.task and othentic.p2p.attestation messages. These messages are passed and propagated using Gossipsub as the underlying protocol. Other messages might be propagated on the network for different purposes, as described below.

All messages on the P2P network are serialized using Protobuf. Proto definitions are provided for each message type below.

othentic.p2p.task

This message encodes a signed task along with its 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;
  string performer = 2;
  string proofOfTask = 3;
  string data = 4;
  uint32 definitionId = 5;
}

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 encodes the details of a submitted task. An aggregator publishes this message once a task submission is confirmed onchain. Its main use is to signal to other nodes they can clear this task from their memory, but can also be used for monitoring.

message AttestationProto {
  string taskId = 1;
  string txHash = 2;
  string performerAddress = 3;
  repeated uint32 operatorIds = 4;
  uint32 definitionId = 5;
  bool isApproved = 6;
}

othentic.p2p.custom_message

This message encodes a string of arbitrary bytes. It can be published by anyone on the P2P network and its contained data will be forwarded to the AVS Validation Service.

This feature needs to be specifically enabled by the AVS network

message CustomMessageProto {
  string data = 1;
}