Introduction

BUILD A SUBNET documentation is still under active development. If you want to help contribute to writing the documentation, message us on Telegram.

Hypertensor is an incentivized intelligence platform for decentralized artificial intelligence applications. Each application operates within its own dedicated subnet, where specialized nodes collaborate to validate the application’s tasks, data, and the integrity of the subnet itself. This architecture ensures robust decentralization, seamless scalability, and a trustless environment for AI innovation.

Subnets

Each subnet is a decentralized incentivized intelligence P2P application where each peer must be staked on-chain and in consensus to receive incentives. The DSN (Decentralized Subnet) standard is in Python, but subnets can be built using a variety of languages.

DSN (Decentralized Subnet Standard)

The DSN can currently support about 90,000 models under the following model types:

• Llama

• Falcon

• Bloom

• Mixtral

Developers can fork the DSN standard to integrate other model types or build their own AI subnets.

---

The following is an overview of the requirements for building a subnet and how it interacts with Hypertensor.

Every subnet must adhere to the blockchain's required interface. There are a few parts that make up a subnet:

• Peer IDs

• Subnet Consensus Protocol

  • Incentives

  • Accounting (under active development)

  • Proposals

---

P2P Technology in Hypertensor Subnets

Why P2P is Necessary for Subnets

Hypertensor employs a validation and attestation consensus model for subnet validation. This model requires 66% attestation from participating subnet nodes to successfully distribute incentives. Due to this design, Hypertensor subnets are susceptible to similar attack vectors as other Proof-of-Stake (PoS) blockchains, making a non-P2P architecture unsuitable for secure and decentralized node onboarding.

Using P2P for Secure Onboarding and Data Distribution

To maintain network integrity, it is strongly recommended that each subnet adopt a P2P architecture using libp2p or similar libraries. This allows:

• Secure entry through Proof-of-Stake (PoS) requirements, preventing Sybil attacks.

• Efficient routing via peer routing tables ensures that all nodes can discover and communicate with each other.

• Scalable data distribution through DHT storage methods, allowing consensus-critical data to be consistently available.

Ensuring Data Consistency and Validator Accuracy

On each epoch, a subnet node is selected to submit incentives data, which all nodes must verify. To ensure a 100% accuracy requirement, all participating nodes must have identical access to the same data. This can be achieved by using:

• Distributed Hash Tables (DHTs) Storage to store and share subnet data efficiently.

• Ledger-based storage methods to ensure data consistency across all nodes.

• Gossip-based subscriptions for real-time data propagation.

These mechanisms ensure that when a validator submits data, other nodes can independently verify it without discrepancies, just like blockchains.

By leveraging P2P networking, Hypertensor subnets can achieve robust decentralization, efficient consensus, and secure incentive distribution, making them resilient to attacks and ensuring trustless validation.

---

P2P Peer ID Generation

Each subnet must generate Peer IDs for each subnet node, and each of these peers must stake on-chain to generate rewards.

It's suggested to use libp2p.

You can use libraries like libp2p, and the format must adhere to the following examples:

Examples:

• bafzbeie5745rpv2m6tjyuugywy4d5ewrqgqqhfnf445he3omzpjbx5xqxe -- Peer ID (sha256) encoded as a CID (inspect).
• QmYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx5N -- Peer ID (sha256) encoded as a raw base58btc multihash.

• 12D3KooWD3eckifWpRn9wQpMG9R9hX3sD158z7EqHWmweQAJU5SA -- Peer ID (ed25519, using the "identity" multihash) encoded as a raw base58btc multihash.

This is qualified on-chain by the following logic:

pub fn validate_peer_id(peer_id: PeerId) -> bool {
  let peer_id_0 = peer_id.0;
  let len = peer_id_0.len();

  // PeerId must be equal to or greater than 32 chars
  // PeerId must be equal to or less than 128 chars
  if len < 32 || len > 128 {
    return false
  };

  let first_char = peer_id_0[0];
  let second_char = peer_id_0[1];
  if first_char == 49 {
    // Node ID (ed25519, using the "identity" multihash) encoded as a raw base58btc multihash
    return len <= 128
  } else if first_char == 81 && second_char == 109 {
    // Node ID (sha256) encoded as a raw base58btc multihash
    return len <= 128;
  } else if first_char == 102 || first_char == 98 || first_char == 122 || first_char == 109 {
    // Node ID (sha256) encoded as a CID
    return len <= 128;
  }
  
  false
}

---

The DSN standard uses only one category of subnet nodes known as validators, but subnets are not restricted to this structure. Subnets can employ any classification strategies, models, or roles they would like, such as coordinators, accountants, reputation-based roles, etc. These roles can be used to customize the subnet incentive mechanisms.

You can fully customize your decentralized AI application.

Each subnet should require a proof of stake before other peers allow them to enter its routing tables. You can see how the DSN standard does this in the auth.pyfile within the Hypermind repository.

---

Subnet Node Classifications

Each subnet node is classified on-chain by its permissions and capabilities. These permissions are based on the on-chain capabilities, not within subnets. To make these roles permission-based within subnets, subnet developers can develop such roles.

Registered

Before registering, each subnet node must have its private key to generate its deterministic Peer ID and sign messages in the subnet with its public key.

Subnets can generate Peer IDs with any encryption algorithm. The DSN standard integrates RSA and Ed25519 and defaults to Ed25519, but developers can use other key types.

Registering a subnet node on-chain claims its slot by staking the required minimum TENSOR.

Subnet nodes classified as Registered are not included in the consensus and do not have to be in the subnet yet.

By first registering on-chain before entering the subnet, it can be used as a POS (Proof of Stake) for other subnet nodes to allow its entry into the subnet within other subnet node routing tables. Subnets can require any form of security measurement requirements, such as higher staking minimums.

Depending on the subnet's requirements, the registration classification acts as an interim period to handle the subnet's computing requirements, such as loading a large model, tasks, etc., before the node activates themselves on-chain (nodes should only activate once adopted into the subnet).

Permissions:

• Staking

Idle

Once registered, a subnet node can then manually or automatically activate its node on-chain, or it can register and activate by using the register_and_activate_subnet_nodefunction.

The idle period is a grace period, this period can be used for the subnet to perform its validation mechanisms on the new subnet node before it can be included in the consensus.

After one successfully validated epoch, the Idle classification will automatically upgrade to Included.

Permissions:

• All of the previous permissions

Included

All Included subnet nodes must be included in consensus data.

Any subnet node classified as Included or above and is not included in consensus data, will increase its penalty score until it reaches the maximum penalties allowable. If this is reached, they are removed by the blockchain validators.

For each epoch included, its penalty score will decrease by one point if greater than zero.

Permissions:

• All of the previous permissions

• Consensus inclusion

Validator

Once a subnet node is included in consensus data within a successfully validated epoch, they are automatically upgraded to Submittable by the blockchain validators.

Validator-classified subnet nodes can be randomly chosen to be validators on epochs to submit consensus data and attest consensus data.

Permissions:

• All of the previous permissions

• Consensus attesting

• Consensus validator

Note:

When subnets are in the registration period on-chain, every node that registers will automatically become classified as Validator to begin the validation mechanisms of the subnet once the subnet is activated. Once the subnet is activated, newly registered subnet nodes begin at the Registration classification. See Registration for more information on the registration period.