community-repo
community-repo copied to clipboard
Create PR and test runtime upgrade with new council params
Goal
- Change the council period to 2 weeks
- Reduce the number of CMs to 3.
Story Points: Up to 25
Scope of Work
Deploy Staging Network
Use an existing staging network, or request a new one. For everyone's benefit, we think a simple 2 validator network would be easiest. If Jsgenesis is to deploy the staging network, 5 story points will be deducted. The staging network should have short election cycles for quicker "turnover", say divide by 1000 ->
-
AnnouncingPeriodDuration
: 144 -
VoteStageDuration
: 144 -
RevealStageDuration
: 144 -
IdlePeriodDuration
: 576
That should leave enough time to apply with 6 members, especially if using a script.
Note that we need to perform multiple tests, so the network needs to be reset after each upgrade, regardless of results.
Update Parameters
For the "real" upgrade, we would ideally want something like: Election:
-
AnnouncingPeriodDuration
: 14400 -> 28800 -
VoteStageDuration
: 14400 -> 28800 -
RevealStageDuration
: 14400 -> 28800 -
IdlePeriodDuration
: 57600 -> 115200
Council:
-
CouncilSize
5 -> 3 -
MinNumberOfExtraCandidates
1 -> 3
All of these parameters can be found here.
However, there are some risks (wrt to time) to achieve this.
- Without also making chances to the council and/or referendum module, it may be the case that the chain will never change the stage that the upgrade happens in (without
sudo
). Part of the scope here is to determine in which situation(s) this could be an issue, eg:
- If the duration of the stage is increased or decreased (or unchanged for that matter)
- which, if any, stages may have this issue
- If it depends on when in the stage the upgrade is executed
- How to fix it
- Changing the
MinNumberOfExtraCandidates
during the announcing or voting stage may also
Review the modules and look at what triggers a new stage.
A faster an easier approach would be to target a specific stage for when the upgrade "must" execute, and let that stage keep the same duration. Eg:
-
AnnouncingPeriodDuration
: 14400 -> [28800, 43200, 57600] -
VoteStageDuration
: 14400 -> [14400, 28800, 14400] -
RevealStageDuration
: 14400 -> [14400, 14400, 14400] -
IdlePeriodDuration
: 57600 -> [144000, 115200, 115200]
If this approach is chosen, 5 story points will be deducted.
For the testing network, the key test should match whatever is targeted for the main network, and have the upgrade execute on the first and last block before the stage ends. This must be done on a "public" staging network, so that the results can be verified. Remember to check that the query node also handles this well.
If anything else than the 6 parameters are modified, some reasonable tests should be performed to verify that it works:
- Lowering the duration of the current stage
- Increasing the duration of the current stage This can be done on a local dev-chain
Deliverables
Create a PR to the master branch that builds without any tests failing.
For the actual test on a "public" staging network, all the necessary links/endpoints and block references must be shared as a reply to this issue.
@bwhm What branch should be used to branch-off?
Proposal: https://dao.joystream.org/#/proposals/preview/322
@singulart master!
Blocked by https://github.com/Joystream/joystream/issues/4008 - cannot create runtime upgrade proposal on staging because of this.
Was able to work around the problem, approved runtime upgrade proposal that shortens the election periods (not reducing council size!): https://polkadot.js.org/apps/?rpc=wss://44.199.232.212.nip.io/ws-rpc#/explorer/query/0xc98b2fc9ac849aafe090071749773ec858935367b8b392ac09138981a24ea1fe
AnnouncingPeriodDuration: 144 VoteStageDuration: 144 RevealStageDuration: 144 IdlePeriodDuration: 576
@bwhm We still need to discuss the scope, as I am not entirely clear on the exact set of tests that is needed
Proposal execution failed: https://polkadot.js.org/apps/?rpc=wss://44.199.232.212.nip.io/ws-rpc#/explorer/query/731382
Implemented