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
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
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
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.