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

Governance Democracy Proposals
,
1

Abstract

This proposal seeks community agreement by remark to formally adopt on-chain guidelines for collator operators on the network and request a change to the minimum bond amount for new collators to 10,000 MOVR in the upcoming Moonriver runtime upgrade. The proposed guidelines will help ensure responsible behavior and establish clear expectations for operators, while the change to the minimum bond is intended to help maintain a diverse set of collator operators.

Details

This proposal seeks to obtain community support for an on-chain remark that articulates the community’s expectations for collator operators on the network.

Part I

The first part of the proposal is to formally adopt a set of guidelines to ensure that collator operators behave responsibly and always act in the best interests of the network and the community. While these guidelines have been informally followed and documented as community norms, codifying them on-chain will enable the community to explicitly adopt them and provide clear guidance to collator operators. It will also establish that there is the potential of penalties for operators who fail to meet these expectations.

By establishing clear guidelines for collator operators, the community can strengthen the network’s overall governance and promote greater trust between delegators and operators.

They are as follows:

Collators have a responsibility to the network to act honorably. If any of the following forbidden offenses occur, action may be taken via on-chain governance:

  • An entity is running 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

  • A collator is running multiple nodes using the same Nimbus key causing equivocation. Equivocation is the action of submitting multiple blocks at the same block height, which forks the network. It is strictly forbidden due to the network degradation that it implies. This can be done by a malicious actor (trying to get more blocks included/produced) or by mistake (having a backup node running with the same key). Each node needs to have its own unique keys and any backup solutions need to ensure there can be no possibility of equivocation

  • A collator acts in a nefarious manner that is uncharitable to the community or other collators

The community also expects collator operators to be actively engaged in the community as a reflection of their commitment to both the community and the network. This engagement is crucial for building trust with the delegators they serve. While the level of engagement is not strictly defined, some examples of what is expected include:

  • Be active in the community

    • Join the Discord and introduce yourself, provide updates as needed, and help support community members or other collators

  • Create tutorials and educational content

  • Become a Moonbeam Ambassador

  • Contribute to open-source software relating to the ecosystem

  • Join the official community forum and actively participate in discussions

  • Actively participate in governance and vote on proposals

Part II

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 entity does not provide a level of service expected by the community, action may be taken via on-chain governance.

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

  • an operator should provide an on-chain identity with a Reasonable judgement with at least one verified communications channel

  • an operator should maintain a client version and at least minimum hardware standards in line with published requirements for the network

  • 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

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

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

Part III

Over the past three months, the community has engaged in active discussions on strategies for maintaining a diverse collator set. The discussion can be found in the link provided at the end of this proposal.

This proposal requests that changes are made in the next Moonriver runtime upgrade such that 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 figure will be reviewed as deemed appropriate by the community. Additional information on the minimum bond requirement can be found in the link at the end of this proposal.

Some benefits of making this change include:

  • It is expected to discourage the use of a strategy where an operator self-stakes tokens to become active in the set, and then gradually reduces their self-stake while gaining community delegations, only to use that self-stake to add additional nodes.

  • The increase in bond rebalances the amount of capital lock-up required to run a collator, closer to the original levels at network launch, which have been skewed due to current market conditions.

  • This change can be complemented by other measures, such as reducing rewards on bond, which may further increase the stability of the collator set and decrease instances of mass unbonding where delegators do not receive rewards.

Links

Forum discussion on ways to maintain a diverse active collator set
https://forum.moonbeam.network/t/ways-to-maintain-a-diverse-active-collator-set/190 -

Collator Bonding Requirements
https://docs.moonbeam.network/node-operators/networks/collators/requirements/#minimum-collator-bond -

12 Likes
2

hey sir thanks for the initiative, could you explain/edit, in the proposal, what exactly the " minimumCandidateStaking" represents?

since surely most of the holders do not seem familiar with the term

3 Likes
3

and in my opinion the benefits should be included in this same proposal in a summarized way, so all users have all the information in the same proposal / discussion

1 Like
4

This is a good point and thank you for flagging it. Let me double check the parameter and I will update. Essentially it is the minimum bonded amount needed for a potential collator to join the Waiting list.

I will summarize the benefits but I do highly recommend that voters read the full discussion as there are quite a few points regarding what changing this value means.

I will add another update here when I’ve made the changes.

5 Likes
5

Thank you @Jim_CertHum for getting this started – much appreciated! This is the culmination of a long and helpful discussion with input from variety of perspectives.

A quick summary would be:

  1. A stable active set is valuable to the community and the parachain
  2. The minBond has a role to play in promoting stability of the active set – that is why it exists and was implemented at mainnet launch.
  3. With the price declines in MOVR and GLMR, the static minBond today is not effective in maintaining stability

Therefore, we should regain the stabilizing value of the minBond by price adjusting it back to where it was after mainnet launch. The exact amount is certainly up for discussion, but the 10,000 amount in this proposal seems about right to me.

–Daniel

7 Likes
6

I’ve made the edits. Note, I backed out of any technical definitions (including in the original proposal before any edits). As this is only an on-chain remark, I don’t see the need to get into the technical weeds, and it’s better just to be clear on what the objective is. If the minimum bond change is implemented, the technical detail will be in the runtime upgrade proposal notes.

5 Likes
7

Thank you very much, Jim, for this proposal! for my part, I fully support this, and I also look forward to such a proposal for Moonbeam in the future, since the issue with active set is more acute in Moonbeam. I also really liked the very important point that you noted is that the community also expects the active participation of collators in the community. In fact, this is incredibly important, since collators are mostly more technical users of the network who can participate in the development of useful tools for the entire community, as well as make various proposal that will benefit the entire network as a whole!

5 Likes
8

thanks for the changes, and seems perfect to me that everything keep the most understandable for the users

I also support the proposal, let’s hope most of the collators take the guidelines into consideration :raised_hands:

5 Likes
9

@Jim_CertHum Great job and proposal! @turrizt beat me to the question, but it was “Will a similar proposal occur for the Moonbeam network as well” ?

I am in favor of this as well

5 Likes
10

i think so. because for the most part, the last discussion on the forum seemed to be more about Moonbeam than Moonriver. it also seems that more and more whales are interested in Moonbeam, and therefore it is likely that a similar proposal is required there as well

4 Likes
11

Thanks for the feedback. Yes, absolutely and I was thinking once the comments are in and any edits are complete on this and it moves to the next stage in the proposal process, it can be used as a template for one on Moonbeam (which would be right about after the next Moonbeam runtime upgrade).

While I was considering submitting it myself, going through this process for the first time so far has been valuable so maybe it would better for someone else in the community to have a go at it to get the exposure.

4 Likes
12

I’ve also added one more example of community involvement expected from collators:

“Maintain an on-chain identity with confirmed Reasonable judgement including at least one verified communications channel.” – this is a recent development that helps delegators get in touch with collators and verified by a 3rd party.

5 Likes
13

Might have overlooked this question, but what is the proposed timeframe to periodically reconsider the minbond amount due to market adjustments? Maybe review every 6 or 12 months?

2 Likes
14

Thank you Jim for putting this together. Very well structured and thought out. It’s an excellent start to setting up a clear code of ethics for collators, that governance will keep them accountable too. In fact, without such a toolset, Gov2 would be useless.

A couple of points I would like to make.

  1. I think a max limit of 4 collators per entity is too high, excluding PureStake and the Foundation for obvious reasons. This is my personal view. I know that this figure was set by the Foundation, but perhaps the reason they said 4 was because they did not want to have a different limit for others. The community can vote on this without that limitation. Maybe a topic for discussion too.

  2. We might also want to vote for a limit on anonymous collators. By their nature, identity-less collators can break through all the rules, and we have seen this happening with P2P making their 5th collator anonymous in Moonriver, and BitcoinSuisse running a 5th anonymous collator, and then eventually retiring it. I do think there should be some anonymous collators in the set because they actually bring some security benefits with them, but I think there should be a limit. Note that, an anonymous collator may actually have a name like SailorMoon, but that doesn’t make it identifiable obviously.

  3. The punishment of breaking the rules should be clear and painful. Kicking the 5th collator of an entity is not punishment - it’s governance not letting them have their cookie, so they can just try again. Therefore, for any rules to have any effect, they need to have clear consequences and those should include an amount of damage that is disproportionate to the if-they-don’t-catch-me benefits. Potential ideas include permanent ban from the set, and confiscating the bond to treasury.

5 Likes
15

It seems to me that these are incredibly important and very precise points!

I’m wondering what it will look like for those entities that currently have 4 collators in an active set. that is, if your points is taken into account and included in the proposal, and if this proposal passes. for example, if we decide that the max collators limit per entity will be, e.g. - 2, then they will have to agree with this and make leave candidates? but, e.g. as we can see, binance also has collators called synclab, it seems that large entities have nothing that would prevent them from having multiple collators with different names. yes, we have a registrar, but it seems to me that it’s not really a problem to set identity for another person?

1 Like
16

Which is exactly why governance exists and it can make these soft distinctions.

A different limit doesn’t have to be enforced retroactively, and if it were, it should give plenty of notice to allow the related parties to comply.

2 Likes
17

Sure, but what I mean is that if an entity launches several collators with different names and identities, it may be challenging to prove that they are all operated by the same entity. However, it seems that one of the important requirements may also be that the collator has an active website or profile on GitHub, as well as experience of collating in other blockchains. by doing so, we can ensure that collator is a well-known and reputable organization, and prevent the creation of anonymous, unknown collators

2 Likes
18

Great feedback on the proposal, thanks Ioannis.

For your point 1, it’s not hard to see how lowering from 4 to 2 would positively impact collator diversity, and I would support that. In fact there seems to be a loose negative correlation between number of collators by one entity and active participation in the community. Also, if someone wanted to hide running more collators than the guidelines allow, they would try and do no that no matter what the number is set. But, I also think this should not be applied retroactively due to the disruption it would cause. It would be good to hear some counter-arguments.

For 3, I think leaving it opened ended is a better approach as it is provides the greatest flexibility for the community to vote if action is needed, without locking the proposal in to something that may need changing later. What about putting in some examples of what those penalties may include?

  • Removal from the active set of collators
  • Slashing of bond
  • Permanent ban from the collating function (I’m not sure how this could be enforced)

Any others?

19

I think what you are describing also becomes apparent when there are issues with a collator and they are anon, which we have seen in the past. We’ve seen difficulty reaching anon collators when there has been a failure to upgrade the client, block production issues, delegators reaching out, and all of this has a negative impact on the network and the community.

Right now the proposal Part I has roughly two subsections – forbidden offenses, and expected engagement. I could add a third part around professionalism, which would include some of the points like comms channels, as well as info that collator should have experience collating, and that if none exists they should have collated on Moonbase Alpha for at least three months, post-mortem for outages, etc.

2 Likes
20

Out loud thought, should there be a sort of SLA for collators? Let’s say they stop producing blocks for long periods of time and efforts to communicate to them go unnoticed. What should be the proposed action?

Ideally encouraging identity verification should help with contact methods

3 Likes