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

Increases staking delays #1030

Merged
merged 8 commits into from
Dec 3, 2021
Merged

Increases staking delays #1030

merged 8 commits into from
Dec 3, 2021

Conversation

crystalin
Copy link
Collaborator

@crystalin crystalin commented Nov 26, 2021

What does it do?

  • Increases the staking round for Moonbase and Moonriver to 2 hours
  • Increases the staking delays for Moonriver to 2 days
  • Decreases the min candidate bond from 1000 MOVRs to 500 MOVRs
  • Increases the staking round for Moonbeam to 6 hours
  • Increases the staking delays for Moonbeam to 7 days

@4meta5 is it safe to change the block per round while the network is already live ? Is it safe also to change the delays while the network is live ?

My understanding is that the default staking round is only used for genesis, so we will need to use set_blocks_per_round. Is it safe to use it in the middle of a round ?

@4meta5
Copy link
Contributor

4meta5 commented Nov 26, 2021

is it safe to change the block per round while the network is already live ? My understanding is that the default staking round is only used for genesis, so we will need to use set_blocks_per_round. Is it safe to use it in the middle of a round ?

Correct, it is safe. We will need to use set_blocks_per_round to change it for a live network but it is safe to use in the middle of a round. The next round will start NEW_ROUND_LENGTH blocks after the last block in which the round number increased.

Is it safe also to change the delays while the network is live ?

Yes, it is. This would not change the scheduled time for already made requests, only requests made after the delay is changed.

Copy link
Contributor

@4meta5 4meta5 left a comment

Choose a reason for hiding this comment

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

lgtm

@notlesh
Copy link
Contributor

notlesh commented Nov 29, 2021

There are rust tests in each of the runtimes that should be failing with these changes. If CI doesn't catch that, it must not be running them...

I'll fix them locally when I get a chance and verify whether or not CI is running the tests.

@notlesh notlesh added the B7-runtimenoteworthy Changes should be noted in any runtime-upgrade release notes label Nov 29, 2021
@girazoki
Copy link
Collaborator

AFAICT, they are failing no?

@crystalin crystalin added A0-pleasereview Pull request needs code review. D1-runtime-migration PR introduces code that might require downstream chains to run a runtime upgrade. labels Dec 1, 2021
@crystalin
Copy link
Collaborator Author

@4meta5 are those changes safe to be included in runtime 1000 (staking) migrations ?

@4meta5
Copy link
Contributor

4meta5 commented Dec 1, 2021

@4meta5 are those changes safe to be included in runtime 1000 (staking) migrations ?

Yes, it is safe. It will not change anything in the migration.

@4meta5
Copy link
Contributor

4meta5 commented Dec 1, 2021

I was worried by the fact the round length increased, but rewards per round did not changed in the integration tests.

It seems the mock runtime uses a constant inflation per round genesis config https://github.com/PureStake/moonbeam/blob/master/runtime/moonbase/tests/common/mod.rs#L109-L127

We should update this to use the actual numbers. Because inflation rewards are proportional to total supply, we should mint more balance in the runtime mock genesis config. I'll make a jira ticket for this.

I think this PR can be merged, but the integration tests don't really test what we need them to test. The genesis configs in chain_spec probably need inflation to be updated to reflect these default blocks per round.

@4meta5 4meta5 mentioned this pull request Dec 2, 2021
for x in 2..599 {
for x in 2..1199 {
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd prefer to express these in terms of the configuration values like 5 * LeaveDelegatorsDelay or whatever value this is. But that can be for a followup.

Copy link
Contributor

Choose a reason for hiding this comment

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

In my deferred staking PR (#1035 ) I added a roll_to_round_begin which takes a round number rather than a block number. That's only loosely related to this...

/// Reward payments delay (number of rounds)
/// Blocks per round
pub const DefaultBlocksPerRound: u32 = 6 * HOURS;
/// Rounds before the collator leaving the candidates request can be executed
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
/// Rounds before the collator leaving the candidates request can be executed
/// Rounds before the candidate's request to leave can be executed

My rewording makes it clear that this applies to all candidates, not just the selected collators. But after writing it, I wasn't sure that was actually true.

@librelois librelois mentioned this pull request Dec 2, 2021
15 tasks
* fix genesis chain_specs so round inflation is set based on default blocks per round configured

* fix build

* use gorka suggestion to use associated type instead of storage item

* fix units

* export ParachainStakingConfigTrait from runtime to use in chainspecs

* fix

* revert export use direct const getter

* unused import

* try TS inflation genesis config

* fix arithmetic

* fix annual to round inflation in genesis

* fix

* fix

* pub mod inflation

* compiles still TS tests off

* fix ts
@crystalin
Copy link
Collaborator Author

FYI the alphanet round was already set to 2 hours (600) on chain

@crystalin crystalin merged commit 5790983 into master Dec 3, 2021
@crystalin crystalin deleted the crystalin-staking-period branch December 3, 2021 03:09
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. B7-runtimenoteworthy Changes should be noted in any runtime-upgrade release notes D1-runtime-migration PR introduces code that might require downstream chains to run a runtime upgrade.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants