Skip to content

Conversation

surcyf123
Copy link

Current issues:

  • large burn price fluctuations
  • long periods where nobody can register

Proposed fixes:

  • price changes every block not every interval
  • remove all rate limits from registration

@surcyf123
Copy link
Author

the price should decrease every block, not only once per half life. Not sure if that was clear.

BurnHalfLife: This will define the number of blocks until the registration price halves from the current value
BurnIncreaseMult: This will define the multiplier that the registration price increases on a registration

Subnets will have a cost that decays as determined by BurnHalfLife and increases by BurnIncreaseMult the block after a registration. MaxRegrationsPerInterval will still be 1.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Subnets will have a cost that decays as determined by BurnHalfLife and increases by BurnIncreaseMult the block after a registration. MaxRegrationsPerInterval will still be 1.
Subnets will have a cost that decays as determined by `BurnHalfLife` and increases by `BurnIncreaseMult` the block after a registration. `MaxRegrationsPerBlock` will still be 1.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

half life is a exponential reduction similar to halving
I think that the formula a linear reduction in value by block - same as subnet registration
NeuronReductionInterval: Number of blocks until the registration price halves from the current value
NeuronIncreaseMult: registration price Multiplier (default is 2)
formula is:

neuron_burn_price = (burn_at_last_reg * NeuronIncreaseMult) - (burn_at_last_reg / NeuronReductionInterval) * (current_block - last_reg_block)
neuron_burn_price = max (neuron_burn_price, minBurnCost)


## Security Considerations

none
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the new hyperparameters must be limited in such a way that does not in practice allow the subnet owner to prevent the root validators from getting a neuron

No backwards compatibility concerns

## Security Considerations

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Attack vectors

  1. Owner increasing the NeuronReductionInterval so the price remains high for many days (up to 65535 blocks)
    • need to set a high limit to the possible value of NeuronReductionInterval
  2. Owner decreasing the NeuronReductionInterval to 1 or 2 to snipe a cheap registration then resetting the interval to a long value
    • the reset to a high value is blocked by the hyperparameter change rate limit
  3. Owner increasing the NeuronIncreaseMult above 16 so the price remains high for a very long time
    • make this parameter a sudo call
  4. Owner decreasing the NeuronIncreaseMult to less than 1 ... makes it cheap for all miners to be deregistered and forced into immunity
    • make this parameter a sudo call
  5. Miner using a script to register
  • timing is now longer block based, its price based
  • script must pay more for registrations as each registration price increases
  1. Miner using MeV tactics to snipe the cheapest registration
  • FIFO on the Proof of authority nodes
  • the sniping miner must pay more for his registrations as he can no longer batch register at the one price
  1. Miner blocking anyone else from registering
  • the price doubling each registration makes it economically cost prohibitive

Mitigation - limits and formulas

  1. range limit the NeuronIncreaseMult from 1 to 5 with up to 3 decimal points
  2. range limit NeuronReductionInterval from 1 to x where x is a small multiple of days

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NeuronReductionInterval should be controlled by the owner but throttled to like one change a week and capped in a tight range maybe? It only makes sense to change it when uid pressure changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants