-
Notifications
You must be signed in to change notification settings - Fork 22
BIT-0017: Neuron UID registration #30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Attack vectors
- 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
- 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
- Owner increasing the NeuronIncreaseMult above 16 so the price remains high for a very long time
- make this parameter a sudo call
- 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
- 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
- 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
- Miner blocking anyone else from registering
- the price doubling each registration makes it economically cost prohibitive
Mitigation - limits and formulas
- range limit the NeuronIncreaseMult from 1 to 5 with up to 3 decimal points
- range limit NeuronReductionInterval from 1 to x where x is a small multiple of days
There was a problem hiding this comment.
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
Current issues:
Proposed fixes: