[Proposal: 1] On-Chain Remark for Collator Guidelines and Request for Collator Self-Bond Change

Governance Democracy Proposals
,
21

Doesn’t Moonbeam want to cause disruption in the blockchain world? :stuck_out_tongue:

Yea, locking the proposal to specific penalties is too much like the old world, but like you say, some examples should be mentioned.

You can enforce a permanent band of an entity. They would then be forced to make anonymous collators. That’s why I think that none of all that makes sense if there is no hard limit on the number of anonymous collators. This of it this way… if all collators were anonymous we would have no way to know how decentralized the network is - it could very well be one entity behind every moon-whatever node and nobody but them would know.

22

I agree there should be a performance requirement too. It can be expressed as a max % difference of the average blocks signed per round over X rounds, from the average of all collators over the same period.

23

Finally at this stage, completely in support of this proposal.

2 Likes
24

Thank you @Jim_CertHum for this proposal! I support it and I agree with all points!

I am very pleased that you have included this part, for us it is one of the most important to build trust in the community. Infact we are very committed with the community thanks to our CMO Michele (very active on both Official and Unofficial Internationals Telegram groups) and my moderation of the Moonbeam Italian Telegram group as Italian Ambassador and also speaking about Moonbeam when I’m invited to any live discussion on YouTube or any other platform.
For this part, however, I think it is really difficult to choose evaluation parameters and consequently apply penalties (if any). For this reason I wanted to know if you already had something in mind for this or these are only suggestions to be remarked on-chain.

3 Likes
25

Well said @stakebaby .

Specifically, it would have seemed inappropriate for the foundation says, “4 for us, and less for everyone else”. However, it seems completely appropriate for the community to say “4 nodes for the foundation, 4 for Purestake, and 2 for anyone else.”

Limiting the number of anonymous collators seems a very good idea! It lowers the impact of time sensitive upgrades/break/fix scenarios as we have a higher expectation of effective communication with known collators. If we only allow 10% anonymous, then the worst case scenario becomes much better as we can expect timely response from 90% of the set. This limitation will also assist with reducing violations of the “X number of collators per entity” rule.

Lastly, I completely agree with you that if we don’t have actual consequences, then we will not be effective in moving toward our desired goals.

26

@lucapoggi I agree with you, if a collator does none of these things, as they are guidelines, does it constitute grounds for a community vote to face some sort of penalty? I think the first step is to establish them on-chain as community approved guidelines and determine if collators that are not participating react, or not. If there is no change in behavior then we have a broader discussion on how we measure this, and potential penalties.

@stakebaby @Daniel_TrueStaking regarding a limit on anonymous collators, I have some questions about this suggestion. How do we define if a collator is anonymous? If it is based on reasonable identity judgement, then right now there are only a handful of judged identities.
Anything else can easily be gamed unless it is carefully tracked and actively monitored, and even a judgement could be gamed in that an entity could ghost after receiving judgement.

KYC would be the effective way, although has its loopholes and challenges, and will certainly generate strong opinions. There are other questions that should be answered such as if round up or down with the 10%, and what happens during set expansion or if a node goes anon after being identifiable?

I think it’s a good idea, but the practicalities of implementing something if we are going to set firm penalties (and not just propose it as another guideline), brings a lot of complexity and for the sake of keeping this proposal moving, it deserves a separate, longer discussion (unless we decide to sideline this proposal for the time being).

@blackk_magiik regarding a proposed amount of lack of block production before the community may take action while in the active set, should we settle on 4 rounds of no block production? <edit – maybe for Moonriver it should be 12 rounds of no block production – i was thinking of Moonbeam when I wrote 4.>

1 Like
27

I think an anonymous node is a node without a reasonable identity judgment, as long as there is at least one entity providing identity judgments of course.

KYC can certainly be gamed and it might, but the goal is not to make a non-gameable system but to increase the hurdle and risk. We have seen huge companies playing silly games with anonymous nodes. Would they also bother faking KYC? I doubt it, as this is getting legally complicated.

I agree that a limit on anon nodes is so important it belongs on a separate vote that should follow.

Regarding performance measurement, I think networks tolerate around 2-4 hours of downtime, then there is slashing. So, that means 2 rounds in Moonriver and 1 round in Moonbeam. This might be too strict for Governance purposes. Also, do take into account that block assignment is random so it is actually possible that no block is assigned during a round in Moonriver (this is almost impossible in Moonbeam).

1 Like
28

I’m thinking anonymous is “collators without an identity judgement”. We can change that definition as needed, but that seems a good starting point.

I agree with you, we should not sideline this proposal with details of “how” we will perform an enforcement actions. It is sufficient to identify “where” we want to go at this time. We can let the discussions and governance work through the “how” at a later date.

1 Like
29

@Jim_CertHum I think 12 rounds for Moonriver is adequate, that’s roughly 24hrs of no block activity. Given having 1 collator not producing blocks has no affect on the network, I think its more for the delegators to show there are established community guidelines for collators. Additionally since there is the Insurance cover fund, a backed offline collator wouldn’t have any effect to the delegators. So maybe the action should be based on 2 conditions? 1) collator has no activity after 24hrs, no communication or lack of, and no insurance fund = governance vote to chill vs 2) collator who has a insurance fund but no block activity they have a longer grace period for recovery before governance vote to chill?

Entirely open to suggestions

1 Like
30

Is there a way that delegators can see if a particular Collator is part of a larger network of Collators? In this case, specifically Synclab?

31

you can see who is the major delegator in these collators, e.g. on subscan. you will see that a large delegator votes exclusively only for 4 collators

2 Likes
32

That makes sense, thanx

1 Like
33

Thanks everyone for the great feedback, it’s really been helpful to know what can be improved in the proposal. I would like to move this to the next stage in the next day, so I’ll summarize the changes that seem to have agreement.

If there are any strong objections, or parts that are felt to require more discussion, please flag it and I will set it aside, moving forward with the remaining agreeable parts.

In Part I:

  • change that an entity should run no more than four collators to – an entity should run no more than two collators unless the community determines by governance that it is for the benefit of the network that an entity should run more than two collators

Add a new Part III around Professionalism

For the benefit of the network, the community expects that collator operators will provide services in a manner that is in line with industry standards. If any collator does not provide a level of service expected by the community, action may be taken via on-chain governance.

Examples of the expected service level from collator operators are as follows:

  • an operator should provide an on-chain identity with a Reasonable judgement and at least one verified communications channel [moving this from Part II which was previously added]

  • an operator should maintain a client version and hardware standards in line with published requirements

  • an operator should implement technologies and procedures that provide redundancy and failover to limit downtime while in the active collator set

  • when a collator fails to produce blocks for multiple consecutive rounds, reasonable efforts of proactive communication should be initiated by the operator to the community, including actions that are being taken to resolve the problem

[@blackk_magiik re the above on further thought, if a collator doesn’t produce blocks for at least one round, it seems professional that they should let the community know – and if they don’t the community can act as needed – this ties into having comms channels, someone will always reach out to them if there is a way to. In the future when transaction volumes increase even one round of missed blocks could impact the transaction queue afaik – agree?]

The community may use on-chain governance when any of the guidelines described in this on-chain remark are not adhered to. Specific actions that may be taken (but are not limited to) include:

  • Removal of an individual collator or set of collators from the active set
  • Slashing of bond
  • Permanent ban of the entity from participating in the collating function on the network

Finally, where the proposal states

“a new potential collator must have a bond of at least 10,000 MOVR in order to be considered eligible and become a collator candidate”

it will be changed to:

“a new potential collator must have a bond of at least 10,000 MOVR in order to be considered eligible and become a collator candidate, and this will be reviewed as deemed appropriate by the community”

5 Likes
34

I understand the intent but tbh it will be impossible to clearly define an “entity”.
The adage “if something can go wrong, it will go wrong” is very true in the case of Moonbeam and Moonriver (any many others), it may just be a matter of time because there is no shortage of pirates and bad-actors.
Good luck with this, I can see risk exposure purely by the nature of this discussion. Compelling Collators to become active in the community is probably not sustainable long term, not without intense scrutiny and action through governance, which then further burdens your Collators.
Whales themselves may not be such a bad thing, because they raise the bar for pirates to misbehave.

1 Like
35

You are right, and any entity, no matter how we define it, can always appear to be two or more separate entities in the current landscape. As a community I think we need to be reasonable in how we enforce this proposal, if it is enacted.

1 Like
36

@Jim_CertHum looks good!!

1 Like
37

Looks good. Thank you for organizing this.

1 Like
38

Final updates are made to the proposal.

1 Like
39

Proposal has been submitted to Governance:

4 Likes
40

According to the result of the related Governance vote, this PR was already merged:

It should be included in RT2300 for Moonriver.

3 Likes