An Overview — RISE v1.3.x consensus changes
Hello RISE community, a few weeks ago (1st of November) we released a new consensus proposal for you to review.
We gathered several pieces of feedback and some of you expressed concerns about the content of the proposal being a bit too technical. Therefore, we are writing an overview of the proposed changes below.
In the last two weeks we have implemented all of the 4 major changes that were detailed in the document but we feel we need to be more transparent with our community by better explaining what is to be expected in a less-hostile language.
Here is a TLDR version of all the 4 changes we would like to introduce:
1. Fair vote weight
Vote weight should be evenly split amongst all voted delegates.
This is not going to have any effect in RISE as our mainchain only allows 1 vote per account, but it will affect future sidechains running on the RISE codebase. Therefore, we have anticipated this configuration for the future of development on RISE.
Example: you have 1 account with 1000 RISEs and you vote for 4 delegates.
Before: each delegate received 1000 voting weight.
After: each delegate receives 1000/4=250 voting weight.
2. Productivity as ranking factor
During this year we released several core versions and some delegates tend to be ‘lazy’. Sometimes updates are critical and need to be performed in a timely manner.
Up until now if a delegate missed a few blocks, down the road he would not have suffered of any side-effects (except from losing forging rewards).
In the new version, we will use the delegate productivity as a ranking factor. For example, if a delegate forged 900 blocks and missed 100 he will have a productivity of 90%. We will just multiply his voting weight by 90% and that will be the delegate’s new used rank.
Example: Delegate has 1.000.000 votes and a productivity of 75%.
- Before: He would still have 1.000.000 voting weight
- After: He will have 750.000 voting weight
3. Delegate banning
Along with improvement #2 we wanted to introduce new code logic for the network to permanently ban a delegate from forging. If as a delegate you miss too many blocks in a row, the network will exclude you for poor performance.
For example, if delegate misses more than 84 blocks (~3 days) in a row he will be not be able to forge a single block again leaving room for other worthy delegates.
4. Active delegates pool modification
Currently in the RISE network we have 101 active delegates. The top 101 delegates are the most voted ones and the delegate in position 102 will (apparently) have no use on the RISE blockchain.
At the time of writing this is the situation at the 101 “border”:
- Delegate in rank 101 has ~797.000 RISE in voting power
- Delegate in rank 102 has ~787.000 RISE in voting power
A difference of “just” 1.3% in voting power dooms the delegate ranking 102 to be excluded from the ability of forging a new block.
We believe this is not fair and we should allow the delegate in rank 102 to prove itself.
Starting from a yet-to-be-decided block we will allow any delegate ranking 199 or lower to forge blocks. What will change then?
Every round will still be composed by 101 different delegates but these 101 individuals will be chosen with a probability that is proportional to their weight.
As a result currently active delegates will have a lower chance of being chosen amongst the next forgers making room for other delegates. Ultimately, making the network fairer, more decentralised and dynamic.
In the plotted chart above we can see the effect the new consensus would have if it was on mainnet right now.
As you may notice from the graph above, there is not much difference between V1 and V2 but we expect the blue line (V2) to dramatically change as soon as the new consensus kicks in.
Ok cool, what is the status of this?
Matteo and I (mostly Matteo) have already implemented all the 4 breaking changes above and you can check out the code in our Github.
Code has been tested and we are going to announce a Testnet update next week.
If everything goes according to plan we will prepare the mainnet release and ask delegates to update their nodes. This will likely happen before the 10th of December.
As always we invite everyone to discuss with us possible concerns and improvements in our developer slack channel. If you feel you are able to participate, please consider joining the #testnet channel and setup a delegate node.
More technical information about these changes can be found here.
