[Task (L1SC)]: Staking reward generation through inflation

[lzpap]

Description

In SUI, staking rewards are subsidised by pre-minted tokens. Once these run out, staking rewards come only from transaction fees.

In IOTA, instead of pre-minted stake subsidies we plan to introduce inflation/deflation based on the amount of tx fees collected in an epoch. The issue is about creating support for this in the epoch advancing system transaction, which currently just takes a portion of the stake subsidy tokens and distributes it to stakers.

The threshold of target staking reward amounts should come from the protocol config and be a governance parameter.

Requirements (1st iteration)

Preview Give feedback

1. [Task (SC-Platform)]: Get rid of the storage fund's ability to earn staking rewards. #937
   3 of 3
   team-sc-platform +1
   
2. [Task (SC-Platform)]: Disable stake subsidies #938
   team-sc-platform +1
3. [Task (SC-Platform)]: Retain the TreasuryCap of the IOTA token from genesis and place it into the system object. #946
   team-sc-platform +1
   
4. [Task (SC-Platform)]: Allow minting and burning of IOTA tokens via the treasurycap only during advance_epoch(). #947
   team-sc-platform +1
5. [Task (SC-Platform)]: Set a constant target reward rate per epoch for validators and burn/ mint new tokens depending on computational fees. #945
   team-sc-platform +1
6. [Task (SC-Platform)]: Put refundable charges into total_object_storage_rebates and non-refundable charges (which are gonna be 0 for now if we set the refund rate to 100%) into non_refundable_balance #939
   team-sc-platform +1
   
7. [Task (SC-Platform)]: Remove rebates from total_object_storage_rebates #948
   team-sc-platform +1
   
8. [Task (SC-Platform)]: Distribute reward tokens to validators while preserving the tallying rule and slashing. #949
   team-sc-platform +1
9. [Task (SC-Platform)]: Verify that reward generation and distribution works by spinning up an network #940
   team-sc-platform +1
10. [Task (SC-Platform)]: Set config parameters for staking according to the following table (from Confluence) #944
    team-sc-platform +1
    

Additional tasks

Preview Give feedback

1. [Task (SC-Platform)]: The v0 framework cut needs to be updated when the inflation mechanism is implemented #942
   team-sc-platform +1
2. [Task (SC-Platform)]: Wrap the IOTA's TreasuryCap into IotaTreasuryCap to protect the IOTA tokens from unauthorized minting/burning #941
   team-sc-platform +1
   
3. [Task (SC-Platform)]: Get rid of stake subsidies in Rust #1001
   team-sc-platform +1
4. [Task (SC-Platform)]: Get rid of reinvestment in the codebase #1005
   team-sc-platform +1
5. [Task (SC-Platform)]: Update SystemEpochInfoEvent with information about minting and burning tokens, rename leftover_storage_fund_inflow #1015
   team-sc-platform +1
   
6. [Task (SC-Platform)]: Add tests checking leftovers burning #1016
   team-sc-platform +1
   
7. [Task (SC-Platform)]: Add staking delegation tests cover the inflation mechanism #1061
   team-sc-platform +1
8. [Task (SC-Platform)]: Fix iota-genesis-builder according to the inflation implementation #1063
   team-sc-platform +1
   
9. [Task (SC-Platform)]: Set storage_rebate_rate to 100% #1069
   team-sc-platform +1
   
10. [Task (SC-Platform)]: Rename storage_fund to storage_deposits #1074
    team-sc-platform +1
11. [Task(SC-Platform)] Decide whether to keep and/or adjust the IOTA conservation check #1017
    team-sc-platform +1
12. [Task (SC-Platform)] Rename storage_reward to storage_charge #1148
    team-sc-platform +1
    
13. [Task (SC-Platform)] Rename TOTAL_SUPPLY_NANOS to STARDUST_TOTAL_SUPPLY_NANOS #1171
    team-sc-platform +1
    
14. [Task (SC-Platform)] Fix CI after inflation introduction #1173
    team-sc-platform +1
    
15. [Task (SC-Platform)]: Check behavior of the storage out of gas scenario #1206
    team-sc-platform +1
    
16. [Task (SC-Platform)]: Update the iota-graphql-e2e-tests test snapshots #1235
    3 of 3
    team-sc-platform +1
    

[miker83z]

We'll wait for the Tokenomics taskforce to provide us some requirements

[valeriyr]

Do we need to implement this part of the specification?

Depending on the size of the storage_deposits, mint new tokens as storage_rewards to be distributed among validators, effectively compensating them for holding the data. Could also be set to zero if we think that target_reward already accounts for this, or we could dynamically adjust target_reward.

[lzpap]

Do we need to implement this part of the specification?

Depending on the size of the storage_deposits, mint new tokens as storage_rewards to be distributed among validators, effectively compensating them for holding the data. Could also be set to zero if we think that target_reward already accounts for this, or we could dynamically adjust target_reward.

No need for it right now.

[Dkwcs]

@lzpap
What should we with leftover_rewards?

        // Because of precision issues with integer divisions, we expect that there will be some
        // remaining balance in `storage_fund_reward` and `computation_reward`.
        // All of these go to the storage fund.
        let mut leftover_staking_rewards = storage_fund_reward;
        leftover_staking_rewards.join(computation_reward);

Just burn them?

[lzpap]

@lzpap
What should we with leftover_rewards?

        // Because of precision issues with integer divisions, we expect that there will be some
        // remaining balance in `storage_fund_reward` and `computation_reward`.
        // All of these go to the storage fund.
        let mut leftover_staking_rewards = storage_fund_reward;
        leftover_staking_rewards.join(computation_reward);

Just burn them?

Do you mean the leftover rewards after distribution to all validators? I'm guessing it's in the range of a couple of nanos? Then we should simply burn it.

[Dkwcs]

@lzpap
What should we with leftover_rewards?

        // Because of precision issues with integer divisions, we expect that there will be some
        // remaining balance in `storage_fund_reward` and `computation_reward`.
        // All of these go to the storage fund.
        let mut leftover_staking_rewards = storage_fund_reward;
        leftover_staking_rewards.join(computation_reward);

Just burn them?

Do you mean the leftover rewards after distribution to all validators? I'm guessing it's in the range of a couple of nanos? Then we should simply burn it.

There was one case in tests when computation rewards could be higher than usual
For an instance - when every validators are slashed and all their rewards will burn

[Dkwcs]

Also what should we do with storage_fund_reward? Replace it or completely remove?
It passes to validators for now

[lzpap]

Also what should we do with storage_fund_reward? Replace it or completely remove?
It passes to validators for now

Storage fund reward is earned by the storage fund from the stake subsidies . We discussed to get rid of the storage deposits ability to earn rewards. Those funds shall not be considered staked.

[lzpap]

Also what should we do with storage_fund_reward? Replace it or completely remove?
It passes to validators for now

Storage fund reward is earned by the storage fund from the stake subsidies . We discussed to get rid of the storage deposits ability to earn rewards. Those funds shall not be considered staked.

@Dkwcs see my comment here #959 (comment)