Refactor Initial Multiplier Logic

[3esmit]

Description

• Renames fields to more descritive variable names:
  • Account.multiplier -> Account.currentMP
  • multiplierSupply -> totalSupplyMP
  • stakeSupply -> totalSupplyBalance
• New field:
  • Account.initialMP: used for saving how much of currentMP was generated for bonusMP (can be renamed to bonusMP), retrieved when checking if MAX_BOOST is reached.
• processEpoch is now called at first of every external function that would need it, as a modifier.
• Accounts are properly initialized at first stake (Fixes #49)
• It's not possible anymore to unstake only a part of funds, or unstake all, or nothing.
• Fix in migration of processAccount, send only the difference of generated MP to new contract.
• Now with code reuse for math formulas
• Mint Intial (Bonus) MPs now use the same formula as the regular multiplier points, but deltaTime is lockedTime.
• Fixed the Lock and Mint function about locked funds. Now it mints correctly for increased time locked, and increased balance in remaining time locked. Fixes #13
• Changed how lock function works: Now lock time can only increase (previously it reverted), now the parameter value represents time increased, and therefore this case does not exist anymore.

Checklist

Ensure you completed all of the steps below before submitting your pull request:

• [x] Added natspec comments?
• [x] Ran forge snapshot?
• [x] Ran pnpm lint?
• [x] Ran forge test?
• [ ] Ran pnpm verify?

[0x-r4bbit]

@3esmit this looks like this needs to be rebased on top of #47

Also, for future PRs please select a reviewer so someone gets notified about it :)

[0x-r4bbit]

@3esmit I've merged #53 and #59 as discussed offline so you can rebase this PR on top of it (now latest develop)

Once done I will review your changes. You might want to squash your commits into https://github.com/logos-co/staking/pull/52/commits/f476860798a2adfb3d9bb166e95b5a724f5fa76e as we don't need the fix test, fix lint etc commits individually.

Let me know if you need any help with this!

[3esmit]

Tests to be written:

• [ ] tests for process epoch:
  • [x] should update pending rewards
  • [x] should update total supply
  • [ ] should update total supply multiplier points
  • [ ] should increase epoch
• [ ] tests for process account:
  • [x] should update user multiplier points
  • [ ] should update user epoch
  • [ ] should pay user proportional rewards
• [ ] tests for stake
  • [ ] should update user lockup time
  • [ ] should mint bonus multiplier points
  • [ ] should update bonus multiplier points (restake)
  • [ ] should update total supply multiplier points
  • [ ] should update total supply balance
  • [ ] should update total supply
• [ ] tests for lock
  • [ ] should update user lockup time
  • [ ] should update bonus multiplier points
  • [ ] should update total supply multiplier points
• [ ] tests for unstake
  • [ ] should burn multiplier points
  • [ ] should update total supply multiplier points
  • [ ] should update total supply balance
  • [ ] should update total supply

[mart1n-xyz]

Here's the cases we were simulating. Case 1 may be interesting as it compares a user with a lock-up and without. I would suggest trying to replicate these parameters for a start. Case 2 deals with restaking - not yet applicable Case 3 might be again interesting as one of the 2 users joins a year later. Case 4&5 are just scaling this to more users and doing stochastic behaviour.

[0x-r4bbit]

Thanks for the updates!

Let's add some tests related to the multiplier/reward calculation, then I think this is good to go.

We can then add all the other tests you've mentioned in your comment in a follow-up PR

[3esmit]

As I am writing tests I am finding other bugs, so I guess this will be a mega PR fixing many bugs.

[0x-r4bbit]

@3esmit I think it's fine if these are part of the refactor changes you've made.

If not, I think it'd be better if we isolate the changes made in this PR so it closes the 1-2 issues it was supposed to close. Then, additional bugs you encounter, unrelated to the refactor changes can be tracked in additional issues and then tackled one by one.

Sometimes it can't be avoided, but we should strive for keep PRs as small as possible