Hotkey Splitting (Per-Subnet Hotkey Swap)

[CapriciousSage]

Is your feature request related to a problem? Please describe.

Due to a ratelimits, validators can only set weights from one hotkey on one subnet in any given block. As subnets increase, it becomes more pressing for validators to split out to multiple hotkeys (under the same cold key) to validate on all subnets, then CHK to themselves to avoid this limitation. Validating from multiple hotkeys also has security benefits.

However, the cost of re-registering 80+ subnets is considerable, while co-ordinating the changes in CHK targets would be significant and result in significant disruption/yield impact for many validators.

An ideal solution would be to allow partial hotkey swap on a subnet-by-subnet basis, with free hotkey swaps within the same cold key, with a flag to automatically/instantly CHK to the new hotkey on the subnet that was just split.

Describe the solution you'd like

• Within the same cold key, the validator specifies both the old and new hotkey they want to swap to/from, as well as the specific subnet(s) they want to swap, with an optional flag to automatically CHK to this new hotkey upon the completion of the swap (ideally bypassing the 24 hour chk window). I.e. "swap only registrations/chks from hotkey-x to hotkey-y for Subnet 1, then chk hotkey-x to hotkey-y on Subnet 1"
• These hotkey swaps within the same cold key would ideally be free/near-free (ie. only gas fees) without additional penalty costs as they're for security and compatibility purposes
• A bulk command would be a 'nice to have', but is not vital

Describe alternatives you've considered

The alternative is manually setting up new hotkeys, registering on the new subnets, transitioning the validator to the new key (or running a second vali to avoid disruption for chk users), telling people to migrate across their CHKs, updating your own CHK, keeping both running until the switch is complete, phasing out the redundant vali and waiting for the old key to de-register. Given the complexity, time, and cost of this process, it is avoided.

Additional context

No response

[ppolewicz]

There are some issues with the 24h timer that can lead to exploits but the cost of implementing this can be tiny if we think about it a bit differently. To iterate on the proposed design:

We already have a hotkey swap feature which moves stakers, CHKers, uids, weights, bonds, axons, encryption certificates, h160 key associations and so on, but this happens on all subnets while an enhancement of the feature could allow the caller to optionally specify a single subnet on which the operation would be performed.

Swap cost can be significant for the chain so we don't want people doing that a whole lot and the high hotkey swap cost is a deterrent, but in this case we are talking about a single subnet, no thousands of root stakers and a miniscule number of direct alpha stakers if any.

I propose that the feature is reworded in two points:

1. Add a netuid parameter (which defaults to zero) to the hotkey swap extrinsic to indicate a subnet on which a hotkey needs to be swapped
2. Change the hotkey swap fee to be essentially free under the following conditions:

• the "to" hotkey is not registered on the given netuid
• the "from" hotkey and the "to" hotkey are registered under the same coldkey
• the subnet on which the swap is being requested is not sn0
• the hotkey swapped is a validator with vpermit
• the last swap of the "to" key on that netuid and on the "to" key on that netuid was less than a month (worth of blocks) ago

3. In order to track the last prong of point 2 we'll introduce

• a new table that will track this information
• an autopurger that will periodically (weekly?) try to delete all entries older than a month (worth of blocks) from that collection

[camfairchild]

We can maybe clear the old entries each time someone calls it. Just clear any that are past the rate limit. That way we charge the weight to the caller.

[CapriciousSage]

One of the major roadblocks for validators splitting from a single hotkey to multiple hotkeys is the performance hit during the transition period. If splitting my hotkey, I need my validator's root weight to follow it immediatly.

Unless I'm missing something here... If I have to wait 24 hours for my chk to apply to my own hotkey that I just split, then not only am I likely to lose delegates during that transition period, but I'm also likely to be deregistered anyway for not having enough stake (as my root netwok stake will not be there yet), rendering the entire process moot.