Registering

Fee and Registration Period

[ ]

The fee is non-refundable.

Length of Registration

Once a subnet is registered, it begins its registration period that lasts for 1 week. Within the time, users can delegate stake to the subnet, and can activate subnet nodes under the subnet based on the initial coldkeys.

Registration Variables

Each registrar must supply a few variables to register (see RegistrationSubnetData).

pub struct RegistrationSubnetData<AccountId> {
	pub name: Vec<u8>,
	pub repo: Vec<u8>,
	pub description: Vec<u8>,
	pub misc: Vec<u8>,
	pub churn_limit: u32,
	pub min_stake: u128,
	pub max_stake: u128,
	pub delegate_stake_percentage: u128,
	pub registration_queue_epochs: u32,
	pub activation_grace_epochs: u32,
	pub queue_classification_epochs: u32,
	pub included_classification_epochs: u32,
	pub max_node_penalties: u32,
	pub initial_coldkeys: BTreeSet<AccountId>,
	pub max_registered_nodes: u32,
	pub node_removal_system: NodeRemovalSystem,
	pub key_types: BTreeSet<KeyType>,
}

Name

  • The unique name of the subnet.

Repo

  • The unique GitHub or similar link to the source code of the subnet for nodes to run.

Description

  • A description of the subnet.

Misc

  • Miscellaneous information.

Churn Limit

  • Number of subnet activations per epoch.

Grace period epochs

  • The grace period from the node queue epochs during which it can activate itself. For example, if a node registers on epoch 1,000 with 10 node queue epochs, it can register in between epoch 1,010, plus the grace period.

The queue epochs and churn limit are used together to calculate each subnet node's start epoch (the epoch they can activate) when they register.

Min Stake

  • Minimum required stake balance to register a node.

Max Stake

  • The maximum allowable stake balance for a subnet node.

Delegate Stake Percentage

  • The percentage ratio of emissions given to delegate stakers.

Registration Queue Epochs

  • Number of epochs for registered nodes to be in the queue before activation.

    • This is the queue a node must be in after registration before the node can activate itself.

Node queue epochs

  • Number of epochs a registered node is in the queue before it can activate itself.

Max node penalties

The maximum penalties a node can have on any epoch without being automatically removed.

  • A node can acquire penalties if:

    • It is a validator and doesn't achieve a minimum of a 66% attestation ratio.

    • The validator doesn't include the node in its consensus data and receives a 66% attestation ratio or greater.

  • A node will decrease its penalties if:

    • It is a validator and achieves above a 66% attestation ratio.

    • The validator includes the node in its consensus data and receives greater than a 66% attestation ratio.

A node will be removed from the blockchain if the max node penalties are reached. If a subnet employs a proof-of-stake consensus mechanism, the DHT Records validator should remove it from the current records, and the authenticator should remove the node from routing tables.

Nodes decrease penalties for every successfully attested epoch they are included in the data. Therefore, to be removed, penalties must be consecutive.

Initial coldkeys

A list of whitelisted coldkeys that can register nodes while the subnet is in the registration phase.

  • Each subnet should be decentralized and is treated as such. Similar to starting a blockchain, trusted nodes should always be the initial nodes in the system to set the standard of trust. Therefore, the registrar must register with a list of coldkeys that are allowed to register nodes. These nodes are automatically classified as a Validator (See subnet node classifications).

  • These coldkeys are removed once a subnet is activated.

Max Registered Nodes

The maximum number of nodes that can be in the registration queue at any given time.

Node Removal System

The removal system is utilized when a subnet has the maximum number of nodes allowable (see Handling Max Nodes).

Key Types

The key types the subnet utilizes for signature authentication. The key types parameter allows subnet and overwatch nodes to know which key types are available to generate their peer IDs to communicate with other nodes. Subnets can choose from the 4 available key types.

See libp2p documentation for more information.

Four key types are supported:

  • RSA

  • Ed25519

  • Secp256k1

  • ECDSA

Note

The mesh template currently supports RSA and Ed25519.

Extrinsic

pub fn register_subnet(
    origin: OriginFor<T>, 
    subnet_data: RegistrationSubnetData<T::AccountId>,
)
PreviousCostNextActivating

Last updated