[Aptos Framework][Vesting] Pay out the accumulated rewards relatively to vesting's remaining grant instead of staking contract's principal

[movekevin]

Description

Using the staking contract’s principal is indirect and the vesting contract can use it remaining grant amount as the base to get the actual amount of accumulated rewards so far. Here’s an example to make this clearer:

1. Vesting contract has 100 APT and 1 staking participant (to keep it simple). 100 APT is also the remaining amount. The underlying staking contract has a principal of 100 APT.
2. The stake pool earns 50 APT.
3. Before calculating outstanding rewards that belong to the vesting pool, vesting::unlock_rewards first requests commission to be paid out to the operator, which is 5 APT (10% of 50 APT earned). Remaining total active stake is 145 APT, all belonging to the vesting pool.
4. Since there’s been no tokens vested yet, the current vesting::unlock_rewards would calculate outstanding rewards to be 145 (total active in stake pool) - 100 (remaining_grant) = 45 to be distributed to staking contract participants.

Test Plan

Unit tests

[zekun000]

do we need this since unlock_stake already does a request_commission internally? isn't the accumulated_rewards = total_active_stake - remaining_grant - commission_amount?

[movekevin]

Great suggestion, thanks! Definitely a simpler and less redundant computation. Updated.

[zekun000]

a completely orthogonal question, after some period of vesting, isn't it possible that the remaining grant drops below the minimal staking amount?

[movekevin]

a completely orthogonal question, after some period of vesting, isn't it possible that the remaining grant drops below the minimal staking amount?

Yes this is already a known potential issue in the far future. However, by then, we'll likely have gone through a couple more iterations and add some more features such as adding stake. Another alternative direction is to move the funds to another contract built on top of delegations.

[zekun000]

I think the comment could be clearer about the difference between this and the accumulated rewards returned from the staking_contract_amounts call

[areshand]

what is the expected reward for shareholder here? could we add an assert to make sure the calculation is correct?

[github-actions]

✅ Forge suite compat success on testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 9d791bc9f7d10c8c10ce0c18d8c03eeda6a70c4f

Compatibility test results for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 9d791bc9f7d10c8c10ce0c18d8c03eeda6a70c4f (PR)
1. Check liveness of validators at old version: testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b
compatibility::simple-validator-upgrade::liveness-check : 7490 TPS, 5202 ms latency, 7800 ms p99 latency,no expired txns
2. Upgrading first Validator to new version: 9d791bc9f7d10c8c10ce0c18d8c03eeda6a70c4f
compatibility::simple-validator-upgrade::single-validator-upgrade : 4575 TPS, 9043 ms latency, 11000 ms p99 latency,no expired txns
3. Upgrading rest of first batch to new version: 9d791bc9f7d10c8c10ce0c18d8c03eeda6a70c4f
compatibility::simple-validator-upgrade::half-validator-upgrade : 4641 TPS, 9023 ms latency, 11800 ms p99 latency,no expired txns
4. upgrading second batch to new version: 9d791bc9f7d10c8c10ce0c18d8c03eeda6a70c4f
compatibility::simple-validator-upgrade::rest-validator-upgrade : 6622 TPS, 5949 ms latency, 11400 ms p99 latency,no expired txns
5. check swarm health
Compatibility test for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 9d791bc9f7d10c8c10ce0c18d8c03eeda6a70c4f passed
Test Ok

• Grafana dashboard
• Humio Logs
• Test runner output
• Test run is land-blocking

[github-actions]

✅ Forge suite land_blocking success on 9d791bc9f7d10c8c10ce0c18d8c03eeda6a70c4f

performance benchmark with full nodes : 6604 TPS, 6008 ms latency, 8700 ms p99 latency,(!) expired 80 out of 2820320 txns
Test Ok

• Grafana dashboard
• Humio Logs
• Test runner output
• Test run is land-blocking