Questnet weekly updates: May 4
May competition starts on May 11, 4pm UTC
Hi All —
We’re excited to gear up for the May Challenge — a new availability challenge based on a *new* voting mechanism. A few key things to keep in mind for the upcoming challenge.
And reminder to sign up for our mailing list here.
Upgrade and Competition Kickoff — May 11, 9am PT / 4pm UTC
The competition will kick-off with a network upgrade at 9am PT on Monday, May 11.
The upgrade has no configuration changes. After Oasis publishes the Genesis Document:
- Update your binary to 20.6
- Wipe state on your node
- Restart your node
- Parameters for this can be found here.
What’s changed on the network with this upgrade
Two key changes to the network at the time of upgrade.
- Block voting power will move from a flat-voting scheme to a stake-weighted voting scheme (more below)
- Epoch duration will shift from approximately 20 minutes to around 1 hour (this is closer to the speed we plan to use at Mainnet Genesis so want to test it out first)
Competition Formula for Best Availability
- With the changes to the voting power methodology we also want to change the way we calculate availability for the competition. We will be measuring the number of blocks an entity signs as a percentage of total blocks they could sign at in Round 0.
- Specifically the formula will change from:
OLD FORMULA (April): Blocks Signed + 50 x Blocks Proposed in Round 0
NEW FORMULA (May): Blocks Signed + ((Blocks Proposed / Times Selected as Proposer) * Blocks with Node Registered)
In plain speak, what this formula means is that a good availability score for May will require the node to be registered and online and signing blocks and proposing blocks, including proposing blocks when another node fails to propose a block.
More on flat vs. stake-weighted voting and how the network will change specifically
Up until now we’ve been using “flat” voting power within the consensus committee, where +⅔ of validators must sign a given block to proceed. We were interested in testing this out to better understand the implications it may have for decentralization, latency, etc.
In May, we’re going to test out something a little different — stake-weighted voting. In this scheme, instead of requiring +⅔ of all validators to sign a block, we will require signatures by validators representing +⅔ of the total stake of the committee to sign a block. We’re interested to see how this will affect performance and upgrade speed!
Other updates / community news
Thought I’d share a few more pieces highlighting some of the applications and SDKs that Oasis Labs is working on. These are relevant primarily for Paratime-level applications but will give you a good sense of some of the enterprise use cases Oasis Labs is beginning to focus on:
