[Tokenomics] Initial stake weighted rewards implementation

[red-0ne]

Summary

• Initial implementation of Morse's stake weighted rewards.
• Refactor the TLM minting by collecting reward instruction and delaying their execution until all of them are processed
  • This makes TLMs order independent in the case where a TLM adjusts rewards by decreasing them
• Make StakeWeightedRewards TLM use the "base reward" (actualSettlementCoin) to adjust whatever BurnEqualsMint minted.

baseReward = actualSettlementCoin
// The following TLMs can run in any order:
BurnEqualsMint => mint(baseReward)
GM => mint(baseReward * allocationPercent)
// The following can decrease the supplier's total reward if weight < 1
StakeWeighedReward => adjustBaseRewardBy(baseReward*weight - baseReward)

This is missing:

• Unit tests
• Governance params (In a follow up PR)
• SupplierStakeWeightMultiplier calculation

Issue

• [Utility] Stake Weighted Supplier Rewards #763

Type of change

Select one or more from the following:

• New feature, functionality or library
• Consensus breaking; add the consensus-breaking label if so. See [Infra] Automatically add the consensus-breaking label #791 for details
• Bug fix
• Code health or cleanup
• Documentation
• Other (specify)

Testing

• Unit Tests: make go_develop_and_test
• LocalNet E2E Tests: make test_e2e
• DevNet E2E Tests: Add the devnet-test-e2e label to the PR.

Sanity Checklist

• I have tested my changes using the available tooling
• I have commented my code
• I have performed a self-review of my own code; both comments & source code
• I create and reference any new tickets, if applicable
• I have left TODOs throughout the codebase, if applicable

[RawthiL]

If I understand correctly, the weight TLM is being enforced on the claimable amount of coins actualSettlementCoin.
All TLMs seem to be work on base of this value that is the basic tokenomics behavior (coins that amount for the servicer's work and that will be burned on the app stake). So, the TLMs seem to be applied as:

• 👍 MINT=BURN : Just use actualSettlementCoin to add to the servicer and burn from application.
• 👍 Global Mint: Use actualSettlementCoin and a multiplier to increase each actors reward.
• 👎 Stake Weight : Use actualSettlementCoin and a multiplier to increase (or decrease) an actor reward based on the stake weight multiplier.

The last TLM is not faithful to the current stake weight multiplication, since in Morse is not only the MINT=BURN amount of coins (here actualSettlementCoin) that gets multiplied, but the boosted coins: [MINT=BURN]+[Global Mint].

Given that the base coins are only a fraction of the total rewards today, as it is this algorithm will mint much lower rewards to stake weighted nodes.

[red-0ne]

@RawthiL thanks for taking a look. You are understanding it right.

The last TLM is not faithful to the current stake weight multiplication, since in Morse is not only the MINT=BURN amount of coins (here actualSettlementCoin) that gets multiplied, but the boosted coins: [MINT=BURN]+[Global Mint].

Great clarification. Given that, SWR would not be faithful to Morse without enforcing it to be run last. Which breaks the TLM assumption of being order free if we want to treat is as a TLM.

To multiply both MEB and GMR, SWR would need to run as a "post-processing" module, which makes it a non-TLM.

Whether we use the inflationary variant @Olshansk proposed or the Morse one, it has to run last if we want to multiply all the rewards.

[RawthiL]

Yes, that's the problem with this module.

---

Just to leave record of view on SWM:
This module should exist at all in Shannon.

Shannon nodes are lean by default, the cost of a node is no longer an issue and hence the SWM has no place. The problem it solves does not exist in Shannon (neither in Morse today).

If we include this we are importing obsolete code into the new version of the network.

Going from Morse to Shannon will require re-staking of all nodes, so we can break-up or fusion nodes stakes arbitrary during the transition.

cc @Olshansk

[Olshansk]

@RawthiL Thank you for the reminder that SWM came BEFORE lean nodes in Morse.

---

@red-0ne Let's close this PR. Apologize for the redundant work...

---

@RawthiL What this means is that the minimum stake per supplier will be the expected value staked per supplier. cc @bryanchriswhite for visibility.

Suppliers will be able to stake more but there is no upside to doing so (similar to ETH validators). I realize we can play around with other ponzinoics here, but would rather leave that convo to post-mainnet.

@RawthiL The only reason this matters (but there's no actionable for us) is because once we figure out the numbers for probabilistic proofs, it'll be similar to:

• Binomial distribution for allowing unprovable claims will use min stake for calculations
• If proof is missing -> Slash 100% of supplier stake.
• If supplier is staking above min -> it's there problem

👍 if this makes sense @RawthiL @red-0ne

[red-0ne]

@Olshansk, this was an invaluable deep dive in which we learned a lot with @bryanchriswhite.

It led us to lean towards a "demand driven" staking mechanism, where:

• A Supplier should be slashed proportionally to the claim amount it failed to prove; alongside a gov. defined minimum slashing amount.
• To ensure that the slashing amount is never bigger than the Supplier's stake, the stake should also be proportional to the total amount claimed in that SessionNumber (i.e. whatever was the demand at that time).

i.e. If a Supplier wants to claim a total of 100pokt it has to stake at least x * 100pokt. If it fails proving all its claims, then it gets slashed by Max(x * 100pokt, minSlashingAmount). With x and minSlashingAmount being protocol/gov defined params.

We'll present a doc when time permits.

[Olshansk]

@red-0ne Can you create a ticket for this (w/ a screenshot of your prior message).

Personally, I think we can make slashing just be the entire supplier's stake because that's what probabilistic proofs assumes. It is also much easier to go to mainnet with. We can always iterate later.

[red-0ne]

@red-0ne Can you create a ticket for this (w/ a screenshot of your prior message).

[Tokenomics] Investigate demand driven staking amounts