substrate
substrate copied to clipboard
paritytech
nomination-pools: allow pool-ids to be reused
Currently, pool ids only ever increase. While generally we suggest using a MaxPools limits, this allows one to spam the pool ids and consume a lot of them by creating a pool and immediately destroying it.
This is not a cheap or fast process, so it is not a huge risk either. Nonetheless, it would be nice to have a simple id-reuse system.
A simple way to do it is that create can have an Option<PoolId>. If None, the sender wants to use LastPoolId + 1 . If Some(claim), the sender is claiming that they know claim is free. claim must always be less then LastPoolId.
Hello @kianenigma would like to get a clear understanding of what this will accomplish.
I think my description is pretty exact, don't have much to add to it after reading it again.
What I would consider is just keeping this fully backwards compatible and creating a new transaction create_with_pool_id instead of breaking the old one.
We would then need an ClaimedId event or something, otherwise UI could get confused to why a PoolId is now pointing to a different pool.
PS: Ah this would not change anything. Nvm.
Thinking out loud, I believe it shouldn't be too hard to to keep track of all the pools that are destroyed and ready to be claimed. In that case we would not really need another fn create_with_pool_id. The existing fn create would first try to get the next_reclaimable_pool_id and if not available, increment pool_id.
With current solution, we might need to expose an api to the frontend client to query a reclaimable pool-id that it can then pass to create_with_pool_id, so we will end up needing to track them anyway.
