Some important ideas discussed in the last days regarding Council composition and validators
During the weekend some important ideas came up regarding 1. nature, composition and duties of the Council and 2. number of validators in the network. This article summarises the main ideas to continue with the conversation in order to take action.
1. Council composition and structure:
Regarding plans for Council seat cap and composition, it was suggested to move forward with two measures:
1a. Giving the ElectionsPhragmen.DesiredRunnersUp constant a higher value in the next runtime upgrade. It is said to allow more visibility to candidates. Although this would have no implications for the decision-making process of the Council, this would allow a higher number of runner-ups to be visible.
1b. Increase the number of Council members from 17 to 19: given the number of runner-ups and the increase of all other metrics, the Councillors number increase is suggested for the Council to be more representative of passive stakeholders.
1c. Some suggestions in the governance module were made in Kulupu that raised suggestions in Kusama, in particular lowering the reject origin to 1/5. The direct result is that it would be easier to reject treasury proposals, limiting Council abuse. A second suggestion included addressing the separation between Council and Tech Comm.
1d. Work on background and interviews by Councillors - suggested as a bounty, this consists on written statements / semi structured interviews with (candidate) council members covering: introduction, representation, plans/vision/ambitions, etc.
1e. Open a proposal for participation lotteries to be developed.
2. Validators, number and threshold
As an agreement after the 500 validators milestone report, it was agreed to revisit the metrics after the 600 validators milestone was reached. However, a good point was raised during the weekend regarding validators: A validator slot can now be secured for approx 4300 KSM. The decrease of this value as we increase the number of available slots tells us that the speed of growth is not in line with the stake evolution.
The Council must keep an eye on this to either:
2a. Stop the scheduled increase once the report metrics change, or stop the schedule increase if the minimum stake needed goes below a decided threshold. An idea is also to stop the increase to allow validators to reorganise and nominators to renominate. In order to decide what should be the ideal threshold, Emiel proposed this to be 30% of the avg staked value, which reflects the current value today.
2b. While we monitor/stop the increase for he min.value to reflect the 30% of avg staked value, we should keep in mind the capability of validators to make a profit: a small min.value would allow small validators to start validating, but if we increase the number the profit will reduce.
A suggestion to action:
- Calculate 30% as minimum and keep it in the current value, stoping the increase if it lowers to give validators and nominators time to reorganise.
- Report on the speed of the increase of value, depending on new stake.
- Advocate to increase stake in place
Please add your POV for all ideas using the number on each, making sure we cover all topics.
Comments (5)
Comments (5)
I support 1 as stated. Re 2: The numbers sound good. Is there any way at all to make this automatic? Change the auto-increase to some custom logic which would actually do this calculation and modify the minimum, then stop increasing automatically until the situation improves?
2 seems like a good idea if we could make it automatic. I suggest maybe a mechanism like the following: We set a minimum/max ideal number of validators by referendum. Then every era, we adjust the actual ideal number of validators up or down a bit based on Emiel's metric. So e.g. we'd have a maximum change of 1%, and we'd increase the number of validators by 1% if the minimum backing was over 40% of the average, decrease the number by 1% of it was below 20% and linearly interpolation between so the number would be unchanges near 30%. Then the only question is if it is easy enough to code that it would be worth someone's time to implement this special case. If we think this would be a good idea for Polkadot once tested on Kusams, it might be. I agree on 1a which would encourage more candidates to stand. It's an issue at the moment that you stand to lose your deposit if you drop off the runner's up list and when this list is full, it is a lot more risky to declare your candidacy. For 1b, if you, RTTI-5220 , think you can orgainise 19, I'm in favour. For 1c, I don't know what the council situation is on Kulupu but 1/5 sounds to be a little drastic. Ideally we'd encourage councillors not to blindly vote too much for trerasury proposals. With even a smaller change, we'll end up with situations where both approve and reject motions would pass, and it is just a race to collect votes. For 1d, we already sponsored one video project, although that had a different aim. If it's cheap to become a candidate, we wouldn't want to pay too much to get statements from them specifically. I'm open to suggestions. 1e is a nice idea if the reward is small enough not for our randomness not being perfect to not be a problem.
I support 1 as stated. Re 2: The numbers sound good. Is there any way at all to make this automatic? Change the auto-increase to some custom logic which would actually do this calculation and modify the minimum, then stop increasing automatically until the situation improves?
2 seems like a good idea if we could make it automatic. I suggest maybe a mechanism like the following: We set a minimum/max ideal number of validators by referendum. Then every era, we adjust the actual ideal number of validators up or down a bit based on Emiel's metric. So e.g. we'd have a maximum change of 1%, and we'd increase the number of validators by 1% if the minimum backing was over 40% of the average, decrease the number by 1% of it was below 20% and linearly interpolation between so the number would be unchanges near 30%. Then the only question is if it is easy enough to code that it would be worth someone's time to implement this special case. If we think this would be a good idea for Polkadot once tested on Kusams, it might be. I agree on 1a which would encourage more candidates to stand. It's an issue at the moment that you stand to lose your deposit if you drop off the runner's up list and when this list is full, it is a lot more risky to declare your candidacy. For 1b, if you, RTTI-5220 , think you can orgainise 19, I'm in favour. For 1c, I don't know what the council situation is on Kulupu but 1/5 sounds to be a little drastic. Ideally we'd encourage councillors not to blindly vote too much for trerasury proposals. With even a smaller change, we'll end up with situations where both approve and reject motions would pass, and it is just a race to collect votes. For 1d, we already sponsored one video project, although that had a different aim. If it's cheap to become a candidate, we wouldn't want to pay too much to get statements from them specifically. I'm open to suggestions. 1e is a nice idea if the reward is small enough not for our randomness not being perfect to not be a problem.