Also allow to increase take, add tests

[gztensor]

Added:

• Extrinsic increase_take in subtensor pallet
• Extrinsic sudo_set_tx_rate_limit_delegate_take in admin-utils pallet
• Separate rate limit logic for increasing delegate take (decreasing is not rate limited)
• Unit tests for decreasing and increasing take in misc. corner cases

For the code review, please check if this check is needed in do_decrease_take, I removed it because I think it should not be there:

subtensor/pallets/subtensor/src/staking.rs

Line 141 in c174374

// --- 4. Ensure we are not already a delegate (dont allow changing delegate take.)

This PR closes #314

[distributedstatemachine]

Looks good! The only thing we need to do with is PR is either rebase off development , or merge into stao branch. v1.0.0 has alot of changes and we would need to capture them here. I think it would also be nice to test the delegate take rate limits

[distributedstatemachine]

Looks good! The only thing we need to do with is PR is either rebase off development , or merge into stao branch. v1.0.0 has alot of changes and we would need to capture them here. I think it would also be nice to test the delegate take rate limits

[distributedstatemachine]

Looks good! The only thing we need to do with is PR is either rebase off development , or merge into stao branch. v1.0.0 has alot of changes and we would need to capture them here. I think it would also be nice to test the delegate take rate limits

I also think it might make sense , so rate limit at the signed extension level , so people dont bombard the chain with these calls

[gztensor]

1. I think the best approach is to create a feature with lowered rate limits and test it in integration tests.
2. We need to know the transaction is successful in order to enforce the rate limit. Do we know that in chain extensions?

[distributedstatemachine]

1. I think the best approach is to create a feature with lowered rate limits and test it in integration tests.

Ok

2. We need to know the transaction is successful in order to enforce the rate limit. Do we know that in chain extensions?

You can use pre_dispatch hooks on the signed extensions to filter this out . Here is an example of how we use them to filter out some transactions

[gztensor]

@distributedstatemachine , I made changes you requested, and also I rebased the branch to stao (with Polkadot 1.0). Would it make sense to close this PR and open a new one to stao branch instead?

[gztensor]

Also, we could probably close decrease_take branch because this branch incorporates all changes from there.

[distributedstatemachine]

@distributedstatemachine , I made changes you requested, and also I rebased the branch to stao (with Polkadot 1.0). Would it make sense to close this PR and open a new one to stao branch instead?

Yes this makes sense

Also, we could probably close decrease_take branch because this branch incorporates all changes from there.

Sounds good to me!