Subsubnets v2 BIT draft

Proposals
1

An enhancement to the subsubnet feature is proposed and labeled as subsubnets v2.

Three major features would be added

  • ability of a subnet owner to enable/disable disjoint neuron sets
  • ability of a miner to select a mechid (typically during registration)
  • restriction will be added to allow a validator to only set weights on uids registered in the same mechid as him

What does “disjoint neuron sets” mean

In subsubnets v1 there was only a “common set”, which had the following properties:

  • every miner could mine every mechanism
  • every validator could set weights on every mechanism
  • registration price was the same regardless of what the neuron was meant to do
  • maximum chain storage was max_uids * (max_mechid+1) * (max_validators +3), so a very active subnet could use up to 8x as much chain resources as one which has a single incentive mechanism (actually more because unpressured subnets tend to have little traffic, so a very active subnet)
  • it was only usable with mechanisms which don’t have uid pressure

In subsubnets v2 the uids sets can stay as “common” just as in v1, but they can also be configured to “disjoint”. In disjoint mode:

  • a miner can only mine a single mechanism
  • a validator can only set weights on one mechanism
  • registration price may be different in different mechanisms / uid sets
  • during neuron registration user has to specify the mechid which the neuron is for
  • maximum chain storage is actually in practice max_uids_per_mechanism * max_uids_per_mechanism * (max_mechid+1), so even lower than what was possible before subsubnets v1
  • there may be mechanisms with with larger uid pressure and those with smaller uid pressure (or none) in the same subnet and the protocol recognizes that by tracking registration price separately
  • a call such as set_mechanism_id(netuid, coldkey, hotkey, mechanism_id) allows a neuron to pick which mechanism_id it will want to be in in the disjoint world, before the subnet moves from joint mode to disjoint mode
  • the tiny fee for setting or changing the designated mech_id has to be paid by the coldkey, like during neuron registration
  • changing mech_id will only be possible if neuron_can_switch_mech_id is enabled
  • before a new mechanism can be added, the number of the immortal (burn) uids must be > (max_mechid+1)
  • max_mechanisms can be increased by up to 1 at a time
  • during increasing max_mechid the mechanisms will see their uids_per_mechanism decrease (should it be like a read-only hyperparameter? doesn’t need to be stored btw)
  • the neurons to be pruned from their preferred subnet will be assigned to a “random” mechanism unless their preference may be respected

Hyperparameters

can_neuron_switch_mechanism = False  #  costs as much as a difference between source registration fee and destination registration fee
disjoint_neurons = False  # disjoint neuron sets or not
min_mortal_uids_per_uid_set = 10  # (non-immune, non-immortal - in practice this reduces the maximum numer of immune uids)

How is it going to work

Every uid set needs to have at least 1 burn uid, which will be stolen by the chain from another mechanism if necessary. If you have 7 mechanisms, 7 burn uids and you want to start the 8th mechanism, then it’ll only be allowed after you register another burn uid (which will land in some other uid set temporarily and then it will be switched to mechanism 8 when max_mechanisms limit will be increased).

When disjoint_neurons = True, validators will need to have separate uids in each mechanism.

When disjoint_neurons = True, the emission for the new mechanism may only be increased above zero a week after the mechanism number is increased to create it, to give the validators time to procure hardware and licenses, register a neuron, set things up etc.

When a subnet is in disjoint mode, trimming down becomes pretty complicated, so it won’t be available in the first version.

There should be a 2 month rate limit for changing the value of disjoint_neurons.

Extrinsics

  • a new registration endpoint needs to be added so that neurons can pick their mechid during registration
  • another one for checking the registration price
  • get_mechanism_assignments(netuid) -> {uid: mechanism_id}
  • set_neuron_mechanism_id(netuid, coldkey, hotkey, mechanism_id) (fee has to be paid by the coldkey like during neuron registration, allows to pick which mechanism_id they will want to be in in the disjoint world, or to switch if that’s allowed).
    )
BIT-0017 - Revamping neuron UID registration
2

Can the SN owner determine UID breakdowns?

Say a SN has 2 mechs with UID distribution of [50,50] - thats 128, 128 ids.

Then could the SN owner decide to switch to [80, 20] - 205, 51 ids?

If so, i would suggest that on registration, there is a check to see if the mechanisms are at equilibrium:

If at equilibrium- then deregistration on chosen mech occurs.
if not at equilibrium - deregistration occrus on an oversubscribed mech.

The same could happen when you go from 2→3 mechs:

[50,50] → [33,33,33]
if mechs 0, 1 are > 84 we prune from these mechs until we are at 84/85 in all mechs.

3

Not in v2. Maybe in a future version, but perhaps we don’t really need it.