search

multiversx / mx-chain-go

⚡ The official implementation of the MultiversX blockchain protocol, written in golang.
https://multiversx.com
GNU General Public License v3.0
929 stars 202 forks source link

Feat/delegation impr v3 #6605

Open sasurobert opened 1 week ago

sasurobert commented 1 week ago

Reasoning behind the pull request

Delegation improvements after Staking Phase 4.0:

Proposed changes

Delegation Fixes after Staking Phase 4.0:

  1. claimRewards with callValue should return an error. Add a flag and check for call value
  2. Staking Providers should not change their fees frequently, there were cases when they changed exactly before epoch change. Proposal: add storage for last epoch when change happened and do not allow a new change of FEE for the next 30 days. There are always errors, so will always change the fee downwards, but upwards only once per 30 days.

Delegation improvements after Staking Phase 4.0: MIP-18 - Migration feature for delegated EGLD to improve the efficiency of the dynamic validator market This is a feature request asked by a lot of community members and someone has written a proposal as well. The solution I propose is to enable users to move funds from one provider to another once per 30 days. changeStakingProvider@amount@sourceSCAddress@destinationSCAddress vmInput.Caller address is the delegator, it is the user address, or the SC address in case of liquid staking contracts or DAO. vmInput.RecipientAddress is the delegation manager contract, which will forward the call to the delegation contract the user wants to move his funds. sourceSCAddress and destinationSCAddress are verified to be a system delegation contract. removeDelegationFromSource@delegatorAddress@amount: does basic checks, can be called by delegation manager address only, and removes from the user the specified amount if the user has enough delegation there. The system checks what was the last time the delegator moved funds to this contract, by checking a new storage in which the epoch was saved. If epoch == 0 or epoch + 30 < currentEpoch we can go to the next step of moving. Rewards are calculated for the user and saved into claimable rewards (this code already exists and used when user delegates more), and the new amount of delegation is computed by subtracting the amount value. moveDelegationToDestination@delegatorAddress@amount: does basic checks, can be called by delegation manager address only, adds the stated amount to the user’s delegation. It creates new storage where the current epoch is saved, the user cannot changeProvider from this place for the next 30 days.He can always unStake and unBond. It will call the internal delegate function, compute rewards for the user if the user already had delegation, increase the delegation amount for the user New function in ValidatorSC is called which makes unStake and unBond in one call for the staking provider, actually the only thing it needs to do is to change the TotalStakedAmount from the staking provider, without adding it to the unStakedFunds. Unstaking of nodes is happening at the end of the epoch if the SP does not have enough funds (this process is the existing code - which works like this even now). moveStakeFromValidatorToValidator@stakeAmount@valiadtorA@validatorB - it can be called by system delegationContracts only. The caller is the delegation contract from which the funds are moved out. This function will also increase the TotalStakedAmount for validatorB. Nothing else to do. removeDelegationFromSource, moveDelegationToDestination and moveStakeFromValidatorToValidator are called synchronously. If one of them fails, no changes are made. Process finished.

Testing procedure

  1. try claimRewards with callValue before and after activation flag. After it should fail.
  2. try to change increase service fee multiple times in the same time period, it should fail after activation, but decreasing it should work.
  3. Create multiple staking providers, delegate from various users to these staking providers and start to migrate delegation amounts from one to another.
    • if a user moves from SP 1 to SP 2, it cannot move from SP 2 towards SP 3 for the next 30 days.
    • the user can move any number of times from SP 1 to any number of providers
    • the user can move into SP 2 from other SPs.
    • after 30 days cooldown period user can move from SP2 again. Unstake and UnBond in the cooldown period should work

Pre-requisites

Based on the Contributing Guidelines the PR author and the reviewers must check the following requirements are met:

github-actions[bot] commented 1 week ago

📊 MultiversX Automated Test Report: View Report

🔄 Build Details:

github-actions[bot] commented 1 week ago

📊 MultiversX Automated Test Report: View Report

🔄 Build Details: