Skip to content
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

Replace staking reserves with locks #1604

Merged
merged 70 commits into from Jul 5, 2022
Merged

Replace staking reserves with locks #1604

merged 70 commits into from Jul 5, 2022

Conversation

notlesh
Copy link
Contributor

@notlesh notlesh commented Jun 14, 2022

What does it do?

Replaces parachain_staking's use of ReservableCurrency with LockableCurrency with the goal of allowing stakers to participate in governance.

Here is a good write-up on the difference between the two: https://stackoverflow.com/a/56418101

⚠️ Breaking Changes ⚠️

⚠️ parachain-staking now uses LockableCurrency instead of ReservableCurrency. Bonds will now use a lock with id stkngdel for delegators and stkngcol for collators rather than a reserve on their funds.
⚠️ Querying free_balance will behave differently for stakers. Previously this amount would exclude bonds, now it will include them. It is likely that this will reflect in cases where it did not before, such as Ethereum wallets like MetaMask.
⚠️ Users will still be unable to spend these bonded funds (transfer, pay for fees, etc.) while they are locked, but they will be able to do other operations which require a lock (e.g. they can vote with their staked funds).
⚠️ Migration Strategy: For existing bonds, there is a two-pronged migration strategy to replace reserves with locks.

  • One is explicit (see the new extrinsics hotfix_migrate_delegators_from_reserve_to_locks and hotfix_migrate_collators_from_reserve_to_locks), which can be used by either PureStake to migrate all bonds or by a user to migrate their own bond.
  • The other is JIT (just-in-time), which will migrate any account when a change to its bond occurs as needed.
  • It will not be necessary for any user, dapp, etc. to worry about migration except for a user who does not want to wait for bulk-migration and wants to migrate themselves.
  • We expect to migrate all accounts using these "hotfix extrinsics" immediately following a runtime upgrade, and this should be quick (10s to 100s of blocks).

TODO:

  • Basic implementation
  • Fix tests
  • New tests
  • Ensure locks can't overlap (currently because a delegator can't be a collator)
  • Test optimistic migration (too big, won't work 😭)
  • Develop a migration strategy: Staking Locks: Abandon optimistic migration approach #1624
  • JIT lazy migration: Staking Locks: JIT migration #1625
  • Weights Benchmarks - need to update for entire runtime
  • Document breaking changes
  • Review WithdrawReasons
  • Test that user can vote while locks in place
  • Explicit extrinsics to update a reserve->lock

@crystalin crystalin added A0-pleasereview Pull request needs code review. B7-runtimenoteworthy Changes should be noted in any runtime-upgrade release notes D9-needsaudit👮 PR contains changes to fund-managing logic that should be properly reviewed and externally audited labels Jun 14, 2022
@notlesh notlesh added A3-inprogress Pull request is in progress. No review needed at this stage. A0-pleasereview Pull request needs code review. and removed A0-pleasereview Pull request needs code review. labels Jun 14, 2022
@crystalin
Copy link
Collaborator

I'm still not sure if we are going to use Lock/Unreserve for the self-bond. We might want to use reserve so it is "slashable" but I'm not sure what would be the condition (maybe for the rand key reveal slashing)

@notlesh
Copy link
Contributor Author

notlesh commented Jun 14, 2022

I'm still not sure if we are going to use Lock/Unreserve for the self-bond. We might want to use reserve so it is "slashable" but I'm not sure what would be the condition (maybe for the rand key reveal slashing)

It'll be easy to remove that if we decide to do so.

@notlesh
Copy link
Contributor Author

notlesh commented Jun 14, 2022

IMO, our governance should reflect the will of the collators, they are very important and act in the best interest of our chain.

@crystalin
Copy link
Collaborator

Things to verify:

  • Not possible to stake multiple times with the same token
  • Not possible to stake to different collators with same tokens (as opposed to democracy that allow to vote to multiple referendum with the same tokens)

I think those will require a separate storage to keep the count of those locked tokens

@notlesh
Copy link
Contributor Author

notlesh commented Jun 20, 2022

I think those will require a separate storage to keep the count of those locked tokens

I'm assuming that a delegator's total locked amount should be their total bond amount, which we are already keeping synced at all times (this is the total across all of their delegations, so it shouldn't provide any "overlap" problems).

@crystalin
Copy link
Collaborator

Out of curiosity, why do we have 2 different locks for delegators and candidates ?

@notlesh
Copy link
Contributor Author

notlesh commented Jul 4, 2022

Out of curiosity, why do we have 2 different locks for delegators and candidates ?

Good question. That started out as something between being defensive and unsure. I think we could get rid of it (combine the two) but I think it still has some small value for future-proofing. I don't have a strong opinion about it.

@crystalin
Copy link
Collaborator

I'm worried it might play against us if we remove by mistake the check for not being a candidate/delegator at the same time

pallets/parachain-staking/src/lib.rs Outdated Show resolved Hide resolved
pallets/parachain-staking/src/types.rs Outdated Show resolved Hide resolved
pallets/parachain-staking/src/types.rs Outdated Show resolved Hide resolved
tests/contracts/compiled/CallPermit.json Show resolved Hide resolved
notlesh and others added 7 commits July 5, 2022 07:21
Co-authored-by: girazoki <gorka.irazoki@gmail.com>
Co-authored-by: girazoki <gorka.irazoki@gmail.com>
Co-authored-by: girazoki <gorka.irazoki@gmail.com>
Co-authored-by: tgmichel <telmo@purestake.com>
Co-authored-by: tgmichel <telmo@purestake.com>
@notlesh
Copy link
Contributor Author

notlesh commented Jul 5, 2022

I'm worried it might play against us if we remove by mistake the check for not being a candidate/delegator at the same time

I've considered the same problem, but I think keeping them separate would help if something were to go wrong. What do you think would be improved by combining them?

Copy link
Collaborator

@girazoki girazoki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I have the concern of additional DB reads/writes jit migration would add, did we take a decision on that already?

@crystalin crystalin mentioned this pull request Jul 5, 2022
14 tasks
@notlesh
Copy link
Contributor Author

notlesh commented Jul 5, 2022

LGTM, I have the concern of additional DB reads/writes jit migration would add, did we take a decision on that already?

Yes, I think everyone thinks this is acceptable as it is limited in several ways. Thanks for considering it though.

@@ -60,6 +60,8 @@ impl<T: Config> OnRuntimeUpgrade for AddAccountIdToNimbusLookup<T> {
#[cfg(feature = "try-runtime")]
fn pre_upgrade() -> Result<(), &'static str> {
use frame_support::traits::OnRuntimeUpgradeHelpersExt;
use sp_std::vec::Vec;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this needed ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was needed for try-runtime I believe, although that doesn't currently build (I think we need moonbeam-foundation/nimbus#62)

@notlesh notlesh merged commit 8ec7a31 into master Jul 5, 2022
@notlesh notlesh deleted the notlesh-staking-locks branch July 5, 2022 18:23
@notlesh notlesh added D1-audited👍 PR contains changes to fund-managing logic that has been properly reviewed and externally audited and removed D9-needsaudit👮 PR contains changes to fund-managing logic that should be properly reviewed and externally audited labels Jul 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A0-pleasereview Pull request needs code review. A3-inprogress Pull request is in progress. No review needed at this stage. B3-apinoteworthy Changes should be mentioned in the release notes of the next minor version release. B5-clientnoteworthy Changes should be mentioned in any downstream projects' release notes B7-runtimenoteworthy Changes should be noted in any runtime-upgrade release notes D1-audited👍 PR contains changes to fund-managing logic that has been properly reviewed and externally audited D1-runtime-migration PR introduces code that might require downstream chains to run a runtime upgrade. D3-breaksconsensus The PR alters the node runtime and/or the SRML modules such that the logic is materially different. D10-breaksdocs Changes to code that require changes in documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants