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
Conversation
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. |
IMO, our governance should reflect the will of the collators, they are very important and act in the best interest of our chain. |
Things to verify:
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). |
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. |
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 |
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>
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? |
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.
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; |
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.
Is this needed ?
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 was needed for try-runtime
I believe, although that doesn't currently build (I think we need moonbeam-foundation/nimbus#62)
What does it do?
Replaces
parachain_staking
's use ofReservableCurrency
withLockableCurrency
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
parachain-staking
now usesLockableCurrency
instead ofReservableCurrency
. Bonds will now use a lock with idstkngdel
for delegators andstkngcol
for collators rather than a reserve on their funds.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.hotfix_migrate_delegators_from_reserve_to_locks
andhotfix_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.TODO:
Benchmarks - need to update for entire runtimeWithdrawReasons