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.
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:
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:
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.
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.
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.
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
Last updated