It’s now a few months that the network is living with 50 validators, securing it, and validating it.
All of them are validators from the testnet.
The first point that did take my attention to make this proposal is that some of them, are actually not active, with delegation allowed from the team.
I personally found this as a mistake (and I’m not concerned).
There are actually 12 validators with a lot of REGEN tokens delegated to, and 18 more validators waiting for an open seat.
To not create a huge change in the available place, let’s start with this proposal:
Allow the 12 validators that should be active to have a seat
This, increase to 62 active validators in the network.
Let’s not forget active ones that could join and didn’t make it in time to join. As there is 18 validators already ready to be active, let’s add this to the proposal:
Allow 8 more seats (what about 13?)
This, increase to 70 active validators in the network (or 75 if more allowed, didn’t want to push hard for a first proposal).
Regen Network is a huge blockchain and a lot of validators are interested to join the movement.
The more there is, the more visibility will gain the project.
Let’s not make too much of a first step, but let’s let a chance to people invested to have a place and help to scale Regen.
Hope to have quick returns from validators and the community on this to make live the proposal.
I’m all up for allowing more validators. As I was reading through the post the number 65 came to mind, not sure why.
Anyway, I’m good with either 62 or 70 (or 65 )
Hi all - this is Dave from LOACOM validator. Generally positive toward this proposal although I would love hearing the longer term plan for total # of validators that were originally envisioned. Ultimately, I’m still more inclined to support ‘active’ validators who are participating in the community and helping grow the movement in addition to standard validation services.
I(0base.vc) agree with this proposal. I believe that the ecosystem can become healthier by increasing the number of network participants. And as a low-level validator with no significant delegation, profitability is not significantly affected.
As a validator of other Cosmos SDK chains who has been participating in the Regen community discussions/Telegram and intends to retire carbon credits in order to offset our carbon footprint, we are definitely interested in validating on Regen Network.
We don’t have any validator running currently on Regen but would plan to set one up if the conditions were right.
Hi, I’m Pacobits from stakely.io team. We think that validators who participated in testned and support it with the required quality and effort should be part of the active validators set.
The first proposal for 12 validators is good, and not a big increase too much. We’ll be incoming less, but the project will be more secure because of more decentralization.
Furthermore adding new actors to the validators regen ecosystem, it’ll have more attraction for end-users.
Increasing the validator set should be an evolutionary process and driven by the network expansions. 12 or 15 is good for the next step. There should be always a place for validators who will contribute back to the network or have more stake than just tokens. And we should definitely find a way to help those types of validators.
Validators could put a portion of the validator rewards (eg 1%) in a fund which will be used to grow the network and REGEN value. Big support for these kinds of initiatives.
Although I am in favour of increasing the validator seats eventually, I think it would be way too early to do it now.
All of them are validators from the testnet.
Yes most of us are, which is a plus point in my humble opinion as we were during testnet, and are more familiar with network than the validators who joined after mainnet.
As @willszal mentioned the token just floated, and we may not wanna attract the wrong type of validators on the network who are in it just for some quick gains from rewards.
Most of us are running their validators since mid April, before their was any token
That being said, the end goal should be to increase the validator seats but I think maybe wait for a little more time.
But If we decide to increase the validator seats and make a proposal for it soon, I think regen foundation should not delegate huge amount of tokens to these new delegators, lets wait for them to prove their worthiness
The first point that did take my attention to make this proposal is that some of them, are actually not active, with delegation allowed from the team.
I personally found this as a mistake (and I’m not concerned).
I think a bigger mistake would be to delegate huge amount of REGEN to the new validators so early.
That being said I am open to hear otherwise, and open to increase the number of seats but think It would be nice for Regen Foundation to consider the performance and loyalty of the new validators before delegating to them <img src="https://forum.regen.network/images/emoji/twitter/slight_smile.png?v=9" title=":slig
As Simply Staking we believe that increasing the validator set size is an important part in growing the network. We fully agree with taking smaller steps and going to 75 before going to 100 and upwards, this is a small enough step to allow the network to grow organically and not too rapidly, and large enough to allow new validators to join and bring something new to the table in terms of participation and possibly tooling.
We are Akik Takat, currently ranked 12, with 2.82% of voting power. We run a validator, and also participate in the implementation of Regen Network and the Community Staking DAO.
The active validator set has the following distribution of stake (linear scale):
In the Aneka explorer, all the inactive validators that have stake are listed as “last seen 2 [or 3 or 4] months ago”. Is this a bug in the explorer? Or did the inactive validators with stake really turn off their machines a few months ago?
If the current proposal passes, increasing the active set to 75 validators, and those inactive validators that Aneka ha
Consistent with the thinking behind selecting 50 as the initial number, validator sustainability will be key to determining whether the proposal passes. Validator sustainability is related to the amount of fees moving through the network. The amount of fees is tied directly to network utility.
So as network adoption and utility increases, fee volume increases too. Higher fee volumes can support a larger validator set. A proposal to increase the validator set should then be more likely to pass as the network’s utility grows.
I’m looking for the post about how blockchain held the promise of decentralizing finance, but has just maintained the trend of channeling more money to people who have the most money. Did ChainFlow write that, or someone else?
If I vote yes on this proposal:
it won’t be because of ideas of network decentralization
(I think network decentralization won’t happen via expanding the validator set, at least not right now with the current distribution of stake, as explained in the charts above. I think decentralizing stake has more to do with validator reputati
On the community call just now we talked about the current governance parameters and the Byzantine Fault Tolerance of the network. This changes my understanding of network security. I thought governance proposals required 66.7% approval of all bonded REGEN (i.e. 66.7% of all online voting power), but in fact passing a proposal only requires 40% quorum and 50% approval, as seen in this screenshot of the parameters page on Aneka:
This means that a vote could happen with 40% quorum, and within that 50% approval means 20% total approval (50% of 40%). For parameter change proposals, the parameters are changed once the vote passes. For software upgrade proposals, after the proposal passes, 66.7% of voting power must perform the software upgrade in order for the chain to continue.
So, now I understand network security a bit more:
If 33.4% of voting power goes offline, then the chain will halt. That currently means the top 6 validators, or the bottom 32 validators.
If a bad proposal were submitted, and 20% of voting power were hacked (top 3 validators, or bottom 23 validators), and another 20% of voting power voted no, and we didn’t find some other way to respond during the 2 week voting period, then the bad proposal would pass. (By bad proposal, I mean something that would destroy Regen Network, not a functional proposal that I disagree with).
Therefore, if I see a bad proposal that hasn’t reached quorum, it’s better to ignore it instead of voting no, because that way the proposal won’t reach quorum. If the proposal passes quorum, then voting NoWithVeto is a good idea, and we need 20% + 1 to vote no if 20% voted yes, or 33% NoWithVeto if more than 33% vot
)
