Open emostov opened 2 years ago
patiently waiting to attempt this :)
patiently waiting to attempt this :)
Happy to hear :) Keep in mind that we aren't sure this will ever actually be added (hence "investigate" in the title). Nonetheless it would be a great project to get a in depth understanding of the pools code. I suspect the trickiest part will be the logic for applying big slashes that would need to dip into the joining pool funds.
New joiners to a bonding pool can be unfairly subjected to a slash if they join a pool after a slash is recorded, but before it is applied.
For new joiners to avoid unfair slashing, I think we would need
slash_defer_duration
joining pools, and have some way of triggering any joining pools that are older thanslash_defer_duration
to be merged into the main bonded pool. This way, if a slash is applied, we could have it just affect the bonded pool and the unbonding pools, sparing the delegators in the joining pools.Any time a slash is applied, we would need to guarantee that a delegator who joined by time the slash was recorded is included in the bonded pool or unbonding pools. This is tricky because the merging of joining pools into the main bonded pool likely cannot be reasonably coupled with recording or applying slashes without significantly increasing the I/O complexity of pool slashes. One idea would be to have a hook on era change that merges any joining pools. Another idea would be to have the slashing logic incorporate any joining pools within the slash range while calculating slashes.
It should be noted that delegators could simply be advised to not join pools that have a pending slash.
Should wait until paritytech/substrate#10694 is merged to start working on this.