Preserve failed validator incentive vesting payments instead of dropping them

[andreitrand]

The current solution from #12210 is to have vested system payments for validators dropped if there is no vesting capacity available. This was deemed to not be an acceptable solution (see this comment) so this PR proposes an alternative:

• We derive a deterministic staging account for each individual validator
• Any system vesting payments that fail due to insufficient capacity deposit their amount as liquid to this staging account (vesting parameters - start and duration - are discarded completely)
• The very first vested payment appends whatever staged amount is present to its own amount, with the staged amount inheriting the payment's own vesting schedule

[sigurpol]

One philosophical question: if I get it right, recovery is coupled to a future successful payout. payout_stakers is permissionless, so while a validator is active anyone can trigger the sweep, so far so good.
But a validator who chills/exits and never earns again has no future payout, so their staged funds are stranded indefinitely, is it the case or am I getting it wrong?

[andreitrand]

One philosophical question: if I get it right, recovery is coupled to a future successful payout. payout_stakers is permissionless, so while a validator is active anyone can trigger the sweep, so far so good. But a validator who chills/exits and never earns again has no future payout, so their staged funds are stranded indefinitely, is it the case or am I getting it wrong?

That's correct - we depend on staking to make at least 1 more successful vested payout after a failed one in order to also grab the latter's balance. This is in line with what we discussed together with @Ank4n, but now that you mention it, it doesn't look ideal.

We could also change the architecture to use a global buffer (a BoundedVec with a reasonable capacity) and write to it all failed vestings (each entry being a schedule & the validator that should receive it), then process it at each era boundary for example. This would prevent the problem you described, but we'd have to figure out what capacity to use on the vector and in the worst case (it gets full), some validators would still miss payments.

[sigurpol]

That's correct - we depend on staking to make at least 1 more successful vested payout after a failed one in order to also grab the latter's balance. This is in line with what we discussed together with @Ank4n, but now that you mention it, it doesn't look ideal.

We could also change the architecture to use a global buffer (a BoundedVec with a reasonable capacity) and write to it all failed vestings (each entry being a schedule & the validator that should receive it), then process it at each era boundary for example. This would prevent the problem you described, but we'd have to figure out what capacity to use on the vector and in the worst case (it gets full), some validators would still miss payments.

Another random idea: what if on a capacity failure, we merge the amount into the validator's most-recent existing System schedule instead of failing?

[Ank4n]

om #12210 is to have vested system payments for validators dropped if there is no vesting capacity available. This was deemed to not be an acceptable solution (see this comment) so this PR proposes an alternative:

• We derive a deterministic staging account for each individual validator
• Any system vesting payments that fail due to insufficient capacity deposit their amount as liquid to this staging account (vesting parameters - start and duration - are discarded completely)
• The very first vested payment appends whatever staged am

This is a really good idea. Its less logic as well. Should have just tests to ensure validators don't get any advantage when merging to older schedule.

@andreitrand wdyt?

[andreitrand]

om #12210 is to have vested system payments for validators dropped if there is no vesting capacity available. This was deemed to not be an acceptable solution (see this comment) so this PR proposes an alternative:

• We derive a deterministic staging account for each individual validator
• Any system vesting payments that fail due to insufficient capacity deposit their amount as liquid to this staging account (vesting parameters - start and duration - are discarded completely)
• The very first vested payment appends whatever staged am

This is a really good idea. Its less logic as well. Should have just tests to ensure validators don't get any advantage when merging to older schedule.

@andreitrand wdyt?

I've updated the logic to now merge a failed vesting schedule's amount with the existing schedule with the closest schedule end. This means that a schedule that can't be added due to capacity now always succeeds, albeit at a potentially different vesting rate. Also, note that this logic applies only to System (trusted) vesting schedules, which remain completely disjoint from public schedules. In the case of the latter, failures due to insufficient capacity still occur but lead to a very visible extrinsic failure.

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/29099875331
Failed job name: test-doc