We are excited to announce that we are ready to propose the next runtime upgrade to be voted by the community. RTU4 has been verified successfully in our testnets and a release has been cut on the centrifuge-chain repository.
As mentioned in the community call and in previous posts this upgrade enables token transfers, among other work around collator selection (more information on this to follow soon).
Proposal timeline sequence:
Monday 24th Jan EOD UTC: Council Motion to vote on externalProposeMajority on the preimage hash of the code upgrade (parachainSystem.authorizeUpgrade(…))
Monday 24th Jan EOD UTC: Council Motion to vote on fastrack on the preimage above with a delay on voting of 50,400 blocks (7 days @ 12s/block)
After these steps (Monday 24th Jan EOD UTC), the upgrade will be up for public referenda voting by the community for a duration of 7 days.
Let us know if you have any questions!
How can it be that voting is still on? The screenshot from above is 9 days old and the referenda ist still running with 14 hours left. Could somebody please explain this?
Timeline calculated in a base of produced blocks ( 50,400 blocks - please check the first message)
You can find the average time for producing each block here:
This is the same way Polkadot and Kusama indicate roughly the deadline because nobody knows exactly the time of deadline and timeframe calculated in base of produced blocks.
Thank you very much, I should have paid attention to the detais above. Do you also know how the target of 12 seconds is set and how this can or will be adjusted over the time running? Thanks in advance!
Hi @Supermario as @ImdioR mentioned the 12s is the target time that a parachain should take to produce and include a block. That is imposed by the relay chain (kusama or polkadot) to make sure consensus on the parachain and on the relay chain for the candidate block makes it on “constant” time and verifying and including blocks from one parachain doesnt affect finalization of other parachains.
In our case, we had a hidden issue in one of our collators that caused the higher times in block production since one of the authorities was not able to produce the next block in the slot allocated when it was its turn to propose.
That should be fixed now, and back to the expected throughput.
