-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add support for redelegation and bring back 7 epoch locking time #3296
Conversation
This reverts commit ce53468.
} | ||
pendingEpoch := pool.chain.CurrentBlock().Epoch() | ||
if shard.Schedule.IsLastBlock(pool.chain.CurrentBlock().Number().Uint64()) { | ||
pendingEpoch = new(big.Int).Add(pendingEpoch, big.NewInt(1)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why add 1? you still want to validate for the current epoch right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's the same logic as collectRewards. If currentBlock is from last epoch, then currently it's epoch+ 1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. My only concerns is whether it will work with slashing. Maybe we can test it out in integration test. Also note Ganesha's comment.
Slashing should work as before as the logic is fairly decoupled. Yea, we will test in integration. |
For port number, take a look at this? https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9700 |
wrong PR? Please approve btw if this PR looks good. |
Add redelegation support. The redelegation works without disturbing the existing staking transaction interface, so no need to modify all the client integrations such as Trust wallet or staking dashboard. It's a two step process where the user first undelegate the tokens which will be locked, and then the new delegation will first try to use the locked token, if not enough, then use the liquid token from normal user balance.
The locked tokens will only be used for redelegation if they are already passed 1 epoch after it's first locked. For example, if 100 ONE is undelegated and locked at epoch 10, then they are only considered for redelegation if it's epoch 11 now. This is to prevent the case where malicious attackers commit attack and then immediately switch token to other validators to avoid slashing.
At the same epoch for redelegation fork, also bring back the 7 epoch undelegation locking time.
Local Integration Tests Done:
Delegation without using locked token.
Delegation using all locked tokens (redelegation).
Delegation using balance when the locked token are not 1 epoch old.
Delegation using partial locked token and partial balance.
Delegation using locked token from multiple undelegations.