Introduction

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

We expect to have a detailed walkthrough on how to build a subnet for mainnet, and a template for building a subnet.

A subnet template is being developed. This will be a boilerplate for generating peer IDs, interfacing with the blockchain, and abstract logic to abide by the SCP (Subnet Consensus Protocol).

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.

Decentralized Subnet Standard

The DSN standard 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.

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
- Scoring
- Accounting (under active development)
- Proposals

P2P

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 scoring mechanisms.

You have the ability to 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.

On-Chain 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.

Generate an Ed25519 private key file with:

python -m subnet.cli.crypto.keygen

Subnets can generate Peer IDs with any encryption algorithm. The DSN standard integrates RSA and 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.

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, before having to activate itself on-chain.

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 simply a grace period for the subnet to perform its validation mechanisms on the new subnet node before it can be included in the consensus.

After one successful 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.

For each epoch included, its penalty score will decrease by one point.

Permissions:

All of the previous permissions
Consensus inclusion

Submittable

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

Submittable subnet nodes can be randomly chosen to be validators on epochs to submit consensus data, as well can attest consensus data.

Permissions:

All of the previous permissions
Consensus attesting
Consensus validator

Note:

When subnets themselves are registered on-chain before being activated, every subnet node that registers before subnet activation automatically becomes classified as Submittable 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.

PreviousRemove NextDSN Standard

Last updated 3 days ago