I think that we should strictly define what it is that validators should be doing to prevent misinterpretations.
Below is a tweet containing a video and some bullet points.
Agreed on this one. We had a minor chat already in the Community $ATOM Governance Discussions chat (Telegram: Contact @atomgov).
We can’t expect validators to do all the possible variations of value adding to the ecosystem, especially not for the smaller validators who don’t have a large team at their disposal. However, validators who are only running a node is also undesirable.
So, for me this would surely be ok if we would create this in some sort of behavioural code where a validator at least is expected to run the node + at least 1 service from the list. Then we can call validators, really validators. It also makes validators part of the growth of the ecosystem and the projects in it and part of the success.
we cant enforce such things the only solution is to raise awareness through different interactive channels. Hope people will put some thought before choosing their validators.
wallets and other stacking specific service providers can help out the community.
We need to call out bad practices more in the public forums rather than closed groups.
Thanks for this Jacob! We surely need to raise awareness for what to do and what not to do as a validator.
It is truly undesirable to simply run a node as @LeonoorsCryptoman mentioned above. It is impossible for smaller scale teams to do all the things on the list but the bare necessities should include Governance Participation in my opinion because that shows active engagement and active monitoring of the chain with respect to possible security concerns etc.
I don’t think we should strictly define the list as you mentioned however we should raise awareness and educate as highlighted by @Sumit_Redhu.
It’s true that validators should already know these things from before. But maybe having a document somewhere as a reference for those to check out would be a good start.
I think having this document open will also allow delegators to see what the responsibilities should be and with the delegators informed, they will chose validators that do engage in those activities and eventually the validators that don’t contribute to any of those items will be filtered out by the change in VP.
I think that we need a governance decision on what validators should do because there is no definition whatsoever of the role.
Some validators firmly believe that they should not review software upgrades, for example. In the original documentation surrounding the cosmos hub, that was a key part of planning.
It is possible that you don’t see the need for this because you don’t have community members stating that you’re validator commissions should also cover code contributions, while watching numerous other validators make no code contributions.
I believe that it’s an important to define the scope of validation, because otherwise we will perpetually argue over what a validator’s job actually is. Personally, I am very tired of that argument and wish to create formal definitions.
I also explicitly wish to discriminate against users of white label services who are incapable of performing the basic tasks of validation.
So basically validators should be able to create their own chain if they wish to ?
I can understand the need of a scope, i’m most doubtful about the centralization-kind of scope you proposed.
No. There are numerous vals who cannot even run a validator.
This is risky.
Isn’t having only a handful of validators able - regarding the scope you proposed - to validate numerous chains risky ?
This should be a must for the validators. Even if its out of their reach they can always discuss with friends or other validators if the code is good to go or not. We should have already learned from the aftermath of juno prop 16.
is there any way we can enforce such things.
For voting we can do some sort of slash or reward redistribution (only for self stacked) for some time or some other things. But I think this will open the doors for lot of other problems.
one thing we can do is pass a prop defining the roles after that it will be easy to publicly call out those not taking part.
I agree we need to develop a common community understanding of the validator role.
Intuitively the first three on the list make sense as being essential roles for all validators all of the time.
Can you please share why you think the next three are essential and not merely “nice to have” or “extras” that a validator can offer in order to differentiate in the game of winning stake?
No not really on enforcement but at least we would have some kind of guidelines.
Right now it’s just, a lot of noise and pointless debate because it isn’t defined.
So the last three items really have to do with your approach, and ensure that the validator is aligned with the chain that they’re validating. Also, if you do number three, you’re going to do number six.
The relay network does require maintenance. Not every validator needs to relay. Instead, the validator set should be looking at the relay network as some kind of a shared duty. Currently chain teams are contracting with validator teams and infrastructure providers to do relaying and this really is not ideal. It is better for this stuff to be handled autonomously. The IBC transaction fees code is going to help with that.
But overall the valset should view a healthy IBC network as part of keeping the network valid.
The current state of validator sets across cosmos is risky. There should be approximately zero white label validators and validators should be the primary operators of the infrastructure and they should be able to do basic code review. If they cannot it’s likely that they may want to find another line of work.
i agree whitelabeled vals are a pain for the network. sadly from my knowledge there is no effective way to avoid their existence. is it ?
the scope you proposed to determine what is a “good” val could eventually reduce their expansion (admitting there is a way to enforce that scope in a permissionless world)
but at the same time it would result in disengagement from vals that are doing a great job with 2 or 3 points you mentionned.
Vals who are validating seriously, and who participate in gov processes are fine to me, as long as there are also vals that are doing more.
depends of the goal of the proposal.
would it be a blocker for simply being allowed to validate ?
would it be a blocker for seeking grants/funds from genesis orgs/CP
would it be to enforce a commission floating param ?
what else ?
edit : or is it just informative ?
then we could attribute different status regarding validation.
vals’architects : validate-review code-build core components-gov participation
vals’governors : validate-gov participation
vals : validate
vals’sybil : earn money
to be fair and honest, in my opinion, a validator have to validate (and participate in governance). reviewing code should be an other role/business with different incentives.
to keep the space open to new entrants and to keep a relative level of decentralisation in making blocks, we should not enforce more.
but why not creating new roles and different incentives.
pleb-boi opinion.
Ty sir Gadikan. Your efforts to bring awareness on these topics are very much appreciated. Salute.
The problem is that it is imo certainly not desired to have only coders running as validators. I have seen too many examples where coders are simply not the best fit for a diplomatic approach to solve discussions with a good compromise.
And imo we simply do not need 100-150 or more coders as validators on the chain. A mix of skills along the valset is a must, where some are better in governance pre-discussions and finding the common ground, other better at coding and other find another place where they add value. Just like any successful business contains all kinds of specialties, we need the same in the valset of a chain.
while this is correct but every validator should do due diligence of some scale. This is more important for chains with permissioned cosmwasm and with ICS vals on hub will be required to do more work.
The design of governance is completely based on the idea that validators are very technical.
This also means that there are many security implications too.
What do you mean with;
The design of governance is completely based on the idea that validators are very technical.