Note: This Idea assumes passage of Referendum 88 which is currently in voting. If Referendum 88 fails this proposal will be discarded.
Abstract
This proposal seeks community agreement by on-chain remark to add an addendum to the collator guidelines established in Referendum 88. It is proposed that the guidelines revert to the previously established community norm of four nodes per entity, and formally adopt this norm as a community guideline.
Details
In Referendum 88 the following guideline was established by on-chain vote:
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.
The on-chain guidelines will be updated to revert and codify what had been a community norm (altered to be specific to Moonbeam), which read:
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 four collators in Moonbeam
Justification
This addendum is being proposed for the following reasons:
The original idea for changing from four to two collators was initiated in the “Ways to maintain a diverse active collator set” thread. It was suggested and supported by a few community members. The support was far from unanimous in terms of responses expressing agreement to the suggestion, and the majority community responses rallied around other initiatives (including the increase to 2,000,000 GLMR bond which overwhelmingly won a poll in the discussion) to maintain diversity in the active set.
The impact of changing from 4 collators to 2 collators has wide-reaching implications that deserve more deliberation and input from the community than the 5 days provided during the idea stage of a proposal, particularly on Moonbeam as opposed to Moonriver. For instance, the change would cause a large number of delegators to lose rewards. This would occur because collators who are currently running more than two nodes would have to remove some of their nodes from the active set in accordance with the updated guideline.
I would like to add my personal support for reverting the guideline to 4 collators per entity.
While I understand that the spirit of the proposal was to encourage decentralization and give smaller collators more opportunities to get into the active set; my concern is that actually lowering the guideline is going to be pretty disruptive - the guideline of “4 collators per entity” has been in place for a long time and I worry this could have some pretty significant unintended consequences. For example, some of those larger entities are bringing in significant volume of users and transactions into the ecosystem - I’m concerned that disrupting their deployed collators and delegators could lead them to look elsewhere.
hm, for some reason I missed this point, and it seemed to me that the new guidelines about 2 collators instead of 4 apply only to future/new collators, i.e, i thought that this should in no way concern collators who already have 4 active nodes. I agree with Sikko’s opinion, those collators and their delegators who are already in active set should not suffer from new guidelines
I agree with you all. It will be highly disruptive for existing collators to downgrade from 4 to 2 without significant impact. I also believed the limit of 2 was for new, future collators post the acceptance of the governance vote. Looking back at the proposal I can understand the concern. We didn’t clearly specify it was for future collators instead of existing.
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
Can we adjust this addendum to say the following instead or is the intent to remove the 2 node rule all together regardless of wording?
A new future entity cannot run more than 2 collators unless the community determines by governance that it is for the benefit of the network that an entity should run more than two
IMO, it would be appropriate to provide clarification that this change would not affect current active collators. you probably could consider adding a comment on the Forum or Polkassembly to inform the community. from previous conversations on the forum, i initially realized that these guidelines would only apply to future / new collators. while it’s possible that other community members share the same understanding, it would be beneficial to clarify this to dispel any doubts in the future
Personally, I’d rather see it set to 4 across the board and have an even playing field. We already have a grandfathering rule for the minimum bond; the more rules we set up; the more it’s confusing for new players looking at the ecosystem.
I think you also have to be a bit careful about a “pulling up the ramp by incumbents” narrative setting in. If tomorrow some new big player shows up, that can potentially bring a lot of users, TVL and transaction volume (which is a good thing for the entire ecosystem). But now put yourself in the shoes of that bigger player - would they be willing to deploy here if there’s 4-5 players that have 4 nodes; but they can only start 2? I feel that’s a tough sell and I’m not clear how you justify it.
I agree with the concern of negative impact to the overall community. I also agree this is best suited as a restriction on future node additions. I think perhaps the easiest path forward is to simply propose that all new nodes must abide by this restriction.
Note that this is per new node not per new collator. Thus, to avoid community disruption, every entity running 4 nodes today can continue forward with that amount. Every entity with 2 and 3 nodes today can continue forward with that amount. Any new nodes, regardless of the entity being new or existing, will be limited to a max of 2 nodes per entity.
I’m not sure I agree with you on this. if we look at the situation in the past, the whales that run the 4 nodes, in most cases, simply created chaos in the active set, knocking out small entities and their delegators, the delegators sit without rewards and it does not benefit anyone. if we talk about the fact that new large entities can attract a large number of new users, TVL and so on, then based on the situation that we have now, I did a little research and looked at the delegations of these collators in general, in fact, they are just the big nominators of their collators, and their accounts usually do not interact with ecosystem projects, do not participate in governance, discussions on forum, and so on, i.e, it seems the only benefit from this is that they can lock a large amount of tokens.
if we are talking about community collators, we see that they are active in all discussions, governance votes, create various tools for the community and much more. I would be sorry to lose these collators, because whales will come and launch 4 nodes each.
as correctly pointed out by @blackk_magiik, if a new entity can bring significant benefits to the ecosystem as a whole, they can introduce themselves to the community, share their plans and ideas, and initiate a joint discussion about the possibility of launching 4 nodes. this means that with the help of governance, entities that could benefit the ecosystem could potentially obtain community approval
These are great points, and the kind of discussion that I think we all need to reflect on, including some of the counterpoints. It’s not beyond me that by proposing we change back to four may speed up CertHum’s extinction from the active set, but I stand by proposal as it’s currently written, and I’ll provide some more reasons.
Why not 1 instead of 2? Wouldn’t 1 provide even more decentralization and diversity? But what do we potentially lose if we went to 1 moving forward? If the guideline started with 8, and the proposal went to 4, 4 would probably seem just right. The fact is that the chosen number of nodes appears in part, arbitrary.
If we compare Moonbeam to some other larger chains, for instance, the relay chain, we see that not having a node limitation did not visibly hinder the growth those chains. Perhaps there is an aspect of that fact, that a large project, and other sources of liquidity see participating in block production of the chain as a fundamental part of their strategy in the integration of new chains. I don’t know what downstream impact this will have, but I know the norm has been 4 since launch.
Another fact is that the rule, whether 2, or 4, or 8, is toothless and hallow. There’s no clear way to enforce it with the limitations of identity judgements. Access to the collating function can be centralized to enforce it, but doesn’t that go against true decentralizing? And there is yet to be any definition of what an entity really means, either.
On converting the limit from 4 to 2; this should, by default, not force previous players to exit. Law (like “legal” law) is not applied retroactively. So, I don’t see the point of voting on this point.
On the other stuff, I’ll write something up tomorrow.
It will help decrease large delegator disruption. Allowing entities to rush in with 4 collators, kicks out ~1200 delegators of other collators. The same argument is also brought up as a reason to not change the limit because the change would kick out delegators; however, it does not apply in that case (see my previous comment as well as turizt and Daniel). So, it appears we all agree in principle here.
On having an even playing field where all entities can have 4 collators (past ones and future ones), I disagree, because even playing fields are not defined across time but across space. Laws change, they get stricter or more lenient - it’s what laws do. The new law would apply to all new entities and that’s even. It also allows for Governance to keep its pre-emptive role.
On making it harder for bigger entities to compete with the players that already have 4 nodes - it does to an extent, and it should. If there is a new player who is not willing to come in with 2 nodes cause he wants 4 or nothing, they are unlikely to offer more than the 1-4 players they kicking out. So it’s a tough sell and a bad sell for the network’s interest. Chances are they will still come in with 2 nodes.
On the arbitrarity of the number 2 - it’s not. It’s less than 4, to put a break on the takeover and centralization of the set, and dissemination of community collators. It’s also higher than 1 to allow bigger entities to be bigger. Why not 3? Cause binary search is faster.
On comparing Moonbeam to other chains - most chains don’t need an entity limit because rewards are proportional to backing, so, players can put their bags behind one node. Also, I would not call number 4 the norm - it was never voted in; and it has a blood trail behind it (ok, i am being overdramatic). In any case, it certainly deserves a revision.
On the enforceability of the rule being a reason - 1) We recently witnessed the 4-rule being enforced even though it was not voted on-chain per-se. 2) Laws are not not-voted because it’s hard to enforce them - that’s against the spirit of law. 3) Conflict of interest law has no problem defining entities in % ownership terms, and I don’t see why would Moonbeam.
To conclude:
The question is not so much about how big will Moonbeam allow big players to be, but how small will the small player be and if that “small” is big enough for him to stay alive. Right now, the small player is allowed to be 1/4 of the big player or 1/16 for orbiters. The set is nearing 50% control by “big” players if it’s not already there (anonymous nodes, hellooo). To me, this is a screaming alarm, of which StakeBaby itself is a prime example. We have, perhaps, the most community support (based on our min bond and exposure through stakeglmr), but that has been far from enough to stay safe. If it’s tough for us, it’s near impossible for others. Being friends with many community collators, I am more worried about them giving up morally and psychologically than big players not being enticed enough to enter.
If a player comes along that has a lot to offer and wants 4 collator spots in return, then, their case should be made on merit through governance. This will have the added benefit of the big players entering (for the first time) the discussion in this forum.
Hi all, I read all the comments so far and I’m really happy @Jim_CertHum brought this topic. My main worry was always to see the whole active set consisted eventually by 18 entities with 4 collator each. As @stakebaby mentioned, for regular community collator it’s almost impossible to fight those entities if they are not strongly backed by the community or a big whale (who can rug them anytime). I don’t need to elaborate regarding the contribution of those comminity collator to the ecosystem (especially compared to those gohst entities who just drop their collator and move on).
Having said that, any decision regarding the number of nodes should be from no on and not retroactively, exactly as we do in any decision (like the 2m GLMR self stake proposal). We should remain consistent.
My suggestion is either:
(1) Cancel from now on the privilege to have more than 1 node with a disclaimer that if the entity really shows it can contribute to the eco-system then it can get a permission to launch more than 1 (by vote)
(2) Limiting the number of entities who can run 4 collators (assuming now it’s 9, then limit it to 11 for example). However, this is quite difficult to implement and monitor (and what we do with entities who want to run only 2 nodes for example)?
My preffered solution is to just cancel it. No more than 1 collator for entity and that it.
Many good points have been raised here! To my eyes it seems that most of the responders here support the idea that reducing collators per entity from 4 to 2 is not intended to be disruptive to existing collators.
Proposal 88 prohibits an entity running more than 2 collators with this phrase, “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.”
My point is that the original guidance allows the “community” to vote and “grandfather in” all active collators prior to this node limit restriction. We can do so because to remove active collators would be disruptive to the community and thus we can easily conclude it is beneficial to let them remain. With this “community decision” in place, then perhaps this addendum is no longer needed to avoid disruption?
If so, then perhaps we could put forward a community vote to grandfather in entities with 3 or 4 collators prior to Proposal 88? This would allow us to solve the disruption concern without the need to retract our guidance which targets a max of 2 collators/entity going forward.
Good points!
I generally agree with doing it retrospectively seems rather unusual and also not fair towards the ones who have been running collators since the beginning when there still was a bull market with high prices. Yes, certainly also not fair that some community collators barely can be kept in the active set. But since you mentioned fairness this angle should also be considered.
& as pointed out by @stakebaby, applying it retroactively seems legally odd to say the least
We agree with the general sentiment discussed here, in any “legal” scenario, a new law would not apply retrospectively. As others have already mentioned, forcing active collators to shut down their collators would result in significant, although possibly only short term, disruptions to delegators, we can attest to this as we had to shut down our 4th collator a few weeks ago, and we received a number of complaints from delegators that stopped receiving rewards and had to undelegate.