Shared pool precision affects alpha tx fees #2336
Description
The shared pool precision is limited in a way a following example explains in detail. Simply put, if there are two coldkeys and one of them is trying to unstake partially, which is going to push beyond of what alpha shared pool can handle in terms of precision, the shared pool requests unstaking the full amount.
This is not a huge issue when removing stake: We just unstake all instead of unstaking partially, no alpha or tao is lost. But when paying transaction fees in alpha, we have no utility to return unused portion of unstaked tao mainly due to two reasons:
- This operation is unstaking outside of transaction. Very hard to index/track, it will harm indexers (such as taostats), and will be confusing for the community
- This kind of unstaking does not update tao flow and will be immediately exploitable
The fix is to use bigmath in alpha share pool to make it's precision virtually infinite.
Precision example
| Action | Shared pool numerator | Stake | Shared pool denominator | Total hotkey alpha |
|---|---|---|---|---|
| 1. Alice stakes 1 | Alice: 1 | Alice: 1 | 1 | 1 |
| 2. Bob stakes 1 | Alice: 1, Bob: 1 | Alice: 1, Bob: 1 | 2 | 2 |
| 3. Emission of 100 | Alice: 1, Bob: 1 | Alice: 51, Bob: 51 | 2 | 102 |
| 4. Alice unstakes 50 | Alice: 0, Bob: 1 | Alice: 0, Bob: 52 | 1 | 52 |
The problem appears on step 4, if we don't fully unstake Alice. One may ask why don't we use higher precision denominator to start with. Here is another example that shows that denominator value will never be enough:
| Action | Shared pool numerator | Stake | Shared pool denominator | Total hotkey alpha |
|---|---|---|---|---|
| 1. Alice stakes 1 | Alice: 1000 | Alice: 1 | 1000 | 1 |
| 2. Emission of 100 | Alice: 100 | Alice: 101 | 1000 | 101 |
| 3. Alice unstakes 100 | Alice: 1 | Alice: 1 | 10 | 1 |
Emissions are "eating" the denominator digits and in order to increase it back, we need to re-scale the complete share pool (all coldkeys in it), which is a O(n) operation.