Currently when user wants to claim from root they end up going through the liquidity pools 128 times. This costs a lot of CPU and causes many storage changes, shifts alpha prices, emits a bunch of logs etc and it causes the cost of the whole operation to be unnecessarily high.
Feature description (in form of a prompt)
Design a new (validator_hotkey, staker_coldkey) -> amount_of_shares structure called PendingRootClaim which allows coldkeys (as long as they do not have a scheduled coldkey swap) to commit some (all by default, but a certain amount may be requested with an optional argument) of the shares they have with a specified validator for liquidation to TAO at a time which is "convenient" for the chain (consider running it early in the block after epoch/coindbase/etc but before any user transactions to prevent frontrunning by smart contracts). That transaction should only go through after a root-configurable amount of coldkeys (default=100) participates. In order to prevent attacks griefing NPoS nodes it might be necessary to use a queue to maintain order of the staker_coldkey records, only consuming some of them, where the amount of budget may grow automatically from block to block to prevent a stuffing attack. Rather than using
PendingRootClaimRequestAmountPerValidator = StorageMap<Validator -> u64>
stateful counter to avoid a recount of requests for every root validator for every execution opportunity and other handcrafted fields, first using a taskforce of subagents try to find a suitable structure in substrate or other opensource implementation, perhaps one of the other substrate chains. Only implement by yourself if no suitable candidate is found.
The weight of the call to join the claim batch may need to be artificially set to ~2% of the standard claim fee, as during the schedule call it's unknown how many participants will eventually join.
When the amount of participants exceeds the activation threshold, the unstaking will actually take place in a batch, crossing the liquidity pool for every holder at the same time, which reduces the compute cost by ~100x, but in order to prevent frontrunning this event, the chain should only execute it if current block first drand sample randomness % 100 = 0 or something like that. As drand samples become quite important in this case, NPoS validators should not be paid for producing blocks with no drand samples or they might even need to be slashed. In the future MEV Shield v2 will make this temporary condition moot as all blocks will contain reliable randomness sourced from the NPoS nodes.
Optionally also activate when
(validator_hotkey as u64 / current_block.first_drand_sample.randomness) % 14400 = 0
making it so that if there are not enough participants then it'll at some point activate anyway, with a 2 day delay on average).
Before actually implementing this as a PR write out a high level implementation plan and then pass it to a fresh max thinking set of subagent to consider the following points:
- thorough review of security implications of the feature
- specific review for attacks which impact block creator nodes
- specific review for attacks which impact yield share holders, for example by preventing an claim from actually getting executed by stuffing the queue etc
- specific review for attacks which impact alpha holders
Currently when user wants to claim from root they end up going through the liquidity pools 128 times. This costs a lot of CPU and causes many storage changes, shifts alpha prices, emits a bunch of logs etc and it causes the cost of the whole operation to be unnecessarily high.
Feature description (in form of a prompt)
Design a new
(validator_hotkey, staker_coldkey) -> amount_of_sharesstructure calledPendingRootClaimwhich allows coldkeys (as long as they do not have a scheduled coldkey swap) to commit some (all by default, but a certain amount may be requested with an optional argument) of the shares they have with a specified validator for liquidation to TAO at a time which is "convenient" for the chain (consider running it early in the block after epoch/coindbase/etc but before any user transactions to prevent frontrunning by smart contracts). That transaction should only go through after a root-configurable amount of coldkeys (default=100) participates. In order to prevent attacks griefing NPoS nodes it might be necessary to use a queue to maintain order of thestaker_coldkeyrecords, only consuming some of them, where the amount of budget may grow automatically from block to block to prevent a stuffing attack. Rather than usingstateful counter to avoid a recount of requests for every root validator for every execution opportunity and other handcrafted fields, first using a taskforce of subagents try to find a suitable structure in substrate or other opensource implementation, perhaps one of the other substrate chains. Only implement by yourself if no suitable candidate is found.
The weight of the call to join the claim batch may need to be artificially set to ~2% of the standard claim fee, as during the schedule call it's unknown how many participants will eventually join.
When the amount of participants exceeds the activation threshold, the unstaking will actually take place in a batch, crossing the liquidity pool for every holder at the same time, which reduces the compute cost by ~100x, but in order to prevent frontrunning this event, the chain should only execute it if
current block first drand sample randomness % 100 = 0or something like that. As drand samples become quite important in this case, NPoS validators should not be paid for producing blocks with no drand samples or they might even need to be slashed. In the future MEV Shield v2 will make this temporary condition moot as all blocks will contain reliable randomness sourced from the NPoS nodes.Optionally also activate when
making it so that if there are not enough participants then it'll at some point activate anyway, with a 2 day delay on average).
Before actually implementing this as a PR write out a high level implementation plan and then pass it to a fresh max thinking set of subagent to consider the following points: