Child Hotkeys

This article describes child hotkeys, a new Bittensor feature. With this feature, a hotkey can delegate a portion or all of its stake TAO to one or more hotkeys. The hotkey that is the source of the stake is called parent hotkey and the hotkey that receives stake is called child hotkey. There can be more than one child hotkey for a parent hotkey. Similarly, a child hotkey can have more than one parent hotkey.

Motivation

The child hotkey feature is motivated by the following two problems:

1. Delegate hotkeys are quite often stored on computers that can be hacked. When a delegate hotkey belonging to a subnet validator is compromised, then this exposes this compromised delegate hotkey in all the subnets. In fact, an attacker can get hold of the delegate hotkey from any one subnet in order to take over all the validation operations with this hotkey, thereby crippling this subnet validator in all their subnets across the entire Bittensor network.
2. A subnet validator may want to validate on several subnets but may run into practical limitations. Properly setting weights on all these subnets can be time-consuming and may not be scalable, hence some validators might resort to weight copying.

To address the above problems, the child hotkeys feature represents a further level of decentralization: Decentralization of the responsibilities of a single hotkey into a group of hotkeys composed of parent and child hotkeys. We decentralize the responsibility of subnet validation by spreading stake TAO to multiple child hotkeys. A separate child hotkey is used to validate on each subnet.

This new level of decentralization builds upon the current decentralization of digital commodity production centers into subnets, decentralization of production tasks into subnet miners, decentralization of task verification into subnet validators, and decentralization of governance through tokens.

Example

• Consider a parent hotkey that assigns its stake to two child hotkeys, and each child hotkey is controlled by a distinct decision maker.
• The parent hotkey is stored securely on a different machine, and the child hotkeys can exist on machines where the subnet validation operations on different subnets are performed.
• In this example, decision-making is decentralized because validation decisions on a given child hotkey are made solely by the child hotkey operator, not by the operator of the parent hotkey nor by the operator of the other child hotkeys.
• Furthermore, security is improved because if one child hotkey is compromised, it does not automatically lead to the other child hotkey being compromised (the parent hotkey is stored on a different machine).

New child hotkey delegation operation

Previously, there was only one way to assign stake TAO to another hotkey: A nominator delegates their own TAO to a subnet validator. With the child hotkeys decentralization, we introduce the following new child hotkey delegation operation:

1. A hotkey p can delegate a portion or all of its stake TAO to another hotkey c. The hotkey p is called parent hotkey and the hotkey c is called the child hotkey. An on-chain record is maintained that the hotkey p is the parent of the hotkey c.
2. The child hotkey c cannot again delegate any stake TAO that came from its parent hotkey p. However, the child hotkey c can delegate the stake TAO that came from its nominator(s).
3. The parent hotkey p can take back (revoke) the stake TAO it delegated to its child hotkey c.
4. A parameter C sets the maximum number of child hotkeys for a given parent hotkey. Currently C is set to 5.

Note that despite the name, a child hotkey is not cryptographically derived from the parent hotkey.

Child hotkey delegation vs. delegation

This new child hotkey delegation feature can be used along with the current delegation operation. However, the new child hotkey delegation operation differs from the delegation operation in the following important ways:

1. The new child hotkey delegation operation is delegation from a hotkey to another hotkey, whereas the current delegation operation is delegation from a coldkey to a hotkey (i.e., from a nominator’s coldkey to a delegate’s hotkey).
2. The new child hotkey delegation applies to a hotkey’s own stake TAO and the stake TAO received through delegation, whereas the current delegation operation only works with a coldkey’s own TAO.
3. A child hotkey c that receives stake TAO from its parent hotkey p cannot send this stake TAO to its own child hotkey gc. On the other hand, a hotkey p that received x stake TAO through delegation can thereafter give this x stake TAO to its child hotkey c.
4. A child hotkey c can also receive delegated TAO from its own nominator. The child hotkey c can set different take fractions for TAO received from these two different operations: A delegate-take fraction on TAO received through delegation, and a child-take fraction on TAO received through child hotkey delegation.
5. Note that a hotkey’s delegate-take fraction applies across all the subnets where this hotkey is validating, because this same hotkey performs subnet validation across these subnets. On the other hand, a parent hotkey can use separate child hotkeys for each subnet and can set a different child-take fraction for each of these child hotkeys.
6. Lastly, the parent to child hotkey delegation graph can differ from subnet to subnet. For example, a parent hotkey can delegate to a child hotkey in Subnet 1 and to a different child hotkey in Subnet 2, and so on.

Rewards and emissions

Rewards and emissions with the child hotkey delegation work as below:

Without the child hotkey feature

Without the child hotkey feature, a coldkey-hotkey pair could receive five types of rewards:

1. A hotkey’s dividend from its own stake.
2. A hotkey’s delegate take rate from the stake delegated to it.
3. A hotkey’s incentive for subnet miner work.
4. A coldkey’s subnet owner’s reward.
5. A coldkey’s dividend from delegating to a validator’s hotkey.

With the child hotkey feature

With the child hotkey feature, we have two additional types of rewards:

1. A parent hotkey p’s dividend for the stake TAO that p gives to a child hotkey c, after the child hotkey c retains the child-take fraction.
2. A child hotkey c’s child-take fraction for performing the subnet validation work on behalf of the parent hotkey p.

Child hotkey feature schedule

See the announcement channel of Bittensor Discord for further details on the schedule for the btcli support for the child hotkey feature.

The Opentensor Team