Requirements

Each subnet has logical requirements that are verified by Overwatch Nodes:

  • Public bootnodes

  • PoS (proof-of-stake)

  • Signature Authorizers

  • "node" key used with the public key subkey of the node stored in the database

Bootnodes

Each subnet must maintain at least one publicly registered bootnode on-chain. Bootnodes, also known as bootstrap nodes, facilitate peer discovery and help new nodes join the network; a familiar concept for those who have operated validator nodes on Ethereum or other blockchains.

On-chain ootnode registration is managed by the subnet owner and any whitelisted coldkeys the owner gives access to manage the main bootnodes. Individual subnet nodes may also optionally register and update their own bootnode.

Bootnodes are part of the Overwatch Node validation mechanism. Overwatch Nodes will query the on-chain bootnodes and use them to attempt joining the subnet to run its validation mechanisms. If an Overwatch Node cannot connect by the end of the overwatch epoch, the subnet will receive a low score, thus decreasing the subnet's overall emissions weight.

PoS

Each subnet must utilize a proof-of-stake consensus mechanism to ensure every node that joins and communicates in the network is always staked on-chain.

The proof-of-stake mechanism is accomplished through an Authorizer and has a built in signature authorizer.

Learn how to implement PoS

Signature Authorizers

In the built-in PoS authorizer, signature authorization is implemented natively; however, all other Protocols must also implement signature authorization between all nodes.

Integrating signature authorization between all node communications allows each peer-to-peer request and response, for example, for inference or training, to verify and authenticate who is requesting and responding to whom via a cryptographic handshake.

By knowing each peer ID, protocols can integrate fully customizable logic like rate limiting, role access, etc.

Signature Authorizers are accomplished through an Authorizer.

Learn how to integrate signature authorizers into protocols

Learn more about protocols

"node" key: public key subkey, and Heartbeat

Each node that joins the sub-network must be stored in the DHT records under the "node" key, with the public key of the node, so its peer ID can be derived from the subkey's public key.

This is accomplished via the record validator's signature validator.

Notes

  • See the mesh template server.py to see how to utilize the record validator's signature validator

  • See the heartbeat to learn how node data should be stored in the subnet

This is used by both the Overwatch Nodes and for public consumption of data. See our future plans.

If a subnet wants to store nodes in another fashion, the subnet must maintain the above requirements in addition to its storage architecture.


Overwatch Validation

Each Overwatch Node will utilize the above requirements to verify and score each subnet.

Last updated