Discontinuation or Minimization of Invulnerable Collators on System ChainsPlaza/AssetHub/PolkadotHub

[SAXEMBERG]

This is meant to be the main discussion about the removal or reduction of invulnerable collators on Plaza/AssetHub/PolkadotHub that was cross-posted the Polkadot referendum 1395 discussion as well as the Kusama referendum 487 discussion.

We would like to kickstart a discussion for a plan to revamp the invulnerable slots for the Polkadot public execution layers, specially the ones that will expect high transactionality and that expect a revamp in the short term future i.e. Plaza/AssetHub/PolkadotHub. Currently, we have a static set of invulnerable collators on all system chains or public chains plus a number of open slots for permissionless validators. These invulnerable collators spent resources and time in the beginning of these system chains and currently are rewarded by bounty 32 and with the invulnerable slots due to the lack of sufficient native fees that will help support operations and due to stability but with the advent of Plaza/AssetHub/PolkadotHub we would like to see that change to a completely permissionless or at least a permissionless maximized approach to collators. That’s why we are inviting comments on the Polkadot forum, on the Polkadot referendum 1395 and the Kusama referendum 487 about potential minimization or discontinuation to this invulnerable set. We envision this as a gradual but constant change given that most execution layers on Polkadot similar to what Plaza/AssetHub/PolkadotHub plans to be i.e. Moonbeam, Astar are quite permissionless when it comes to collators. The same applies to other competing L1s.

We would like to hear the feedback from Parity, the main developer of Plaza/AssetHub/PolkadotHub, owner of a large number of invulnerable collators on Plaza/AssetHub/PolkadotHub, other developers working on Plaza/AssetHub/PolkadotHub, the recipients of bounty 32 “Polkadot System Parachains Collator Bounty” as well as its curators and interested collators.

Mostly about the feasibility of an increase in permissionlessness in Plaza/AssetHub/PolkadotHub and what plans, solutions and ideas Polkadot agents can bring forward regarding this gradual plan.

A simplified plan should look like:

-Partial removal of a portion of invulnerables on Kusama – Polkadot maintains the status quo.

• Plaza/AssetHub/PolkadotHub upgrade goes live on Kusama.

• Complete removal of invulnerables on Kusama (or maximum invulnerable removal possible) – Parital removal of a portion of invulnerables on Polkadot

• Plaza/AssetHub/PolkadotHub upgrade goes live on Polkadot – Complete removal of invulnerables on Kusama (or maximum invulnerable removal possible) begins testing.

• Complete removal of invulnerables on Polkadot (or maximum invulnerable removal possible).

[tom.stakeplus]

AFAIK, there’s already a long term plan implemented by the fellowship. You may want to ping Joe about it.

Something to consider, there is 0 or near 0 revenue for operating these nodes outside of the payments from governance (bounty #32). Unless we want to increase txn fees on these chains it’s likely there will never be any revenue without payments from governance or inflation. Those payments set the bar for attack threshold and that threshold is pretty low. IMO, leave the invulns. Since the only real attack someone could run is a withholding attack (not processing txns) it would be fine to reduce the number of invulns but there should always be a couple on these chains.

Full disclosure: I do operate 2 collators for these chains. 1 on polkadot collectives and another on kusama assethub, both receiving an invuln slot. I was supposed to receive a third but passed on the opportunity due to lack of time to deal with it.

[tunkas]

Disclosure: I operate multiple collators on KSM and DOT SysPara, of which 3 are INV collators.

I fail to understand the reasoning behind your wish to see the ‘change to a completely permissionless or at least a permissionless maximized approach to collators’? I am not against such approach if there is merit to it, so I am interested to hear the reasoning behind it.

As mentioned by Coinstudio in currently open discussion on Polkadot referendum 1395 (link posted by you above) reasoning behind current model can be found in approved RFC-0007: System Collator Selection of Polkadot Fellowship RFCs. Available resource is also a discussion on an Economic model for System Paracollators.

Side note: Astar parachain is maybe not the best example for your case of permissionless collators maximization approach - out of 46 collators 18 are Invulnerable and 28 are permissionless. This mounts to 39% of Invulnerables - so not that different from current 50% on Polkadot System Parachains.

[CoinStudio]

I write as a collator on several system chains and as an author of the active proposals:

• Polkadot Ref #1395 Polkadot System Parachains Collator Bounty #32 Top-Up Proposal - Jan/2025
• Kusama Ref #487 Kusama System Parachains Collator Bounty #20 Top-Up Proposal - Jan/2025

For those interested, all related discussions, documents, and previous referenda are linked within the top-up proposals.

To provide a clear vision, the cost of operating an entire single Kusama system chain collator set is approximately $3,600 per month, while the cost for a Polkadot system chain collator set is closer to $4,000 per month. These chains currently generate zero or near-zero revenue outside of the payments from governance (Bounty #32 and Bounty #20). Without governance support or significant changes—such as increasing transaction fees or introducing inflation—there’s little chance for these chains to become self-sustaining.

The payments from governance effectively set the bar for economic security, which is currently quite low. As Tom pointed out, without invulnerable collators, anyone could take all active spots on Kusama BridgeHub which currently takes about 800 KSM (~$24,000) and perform a withholding attack. This demonstrates the vulnerability of system chains without invulnerable slots and highlights how fragile their economic security would be under such conditions.

That said, my stance to ensure the long-term sustainability of these chains is that redesigning the economic model of system chains should take a higher priority over simply removing invulnerable collators.

In a permissionless system, anyone with a solution to the problem can propose and apply changes through OpenGov, as has been done before. For reference, here are two past referenda that addressed similar topics:

1. Referendum 315 - Expand invulnerables set on Asset-Hub Kusama
2. Referendum 224 - Further decentralize collator set on Kusama system chains

[joepetrowski]

The design of this system was addressed in RFC 7 and included all the points you are making here about economics, the introduction of inflation, the non-profitability of collating, ulterior motivation for collating, etc. I won’t regurgitate them here.

W/r/t specifically removing Invulnerables, they are there to ensure that someone is always available to collate the chain. Likewise, the bond-acquired slots are there to ensure that anyone can collate the chain if they want to (they may have many reasons to want to, I’m not to judge).

As an addendum, “Plaza”, “Asset Hub”, and “Polkadot Hub” are not synonymous .

• Asset Hub: A parachain.
• Polkadot Hub: All the user-facing functionality of Polkadot. Basically every user story that is not deploying and running a parachain. People using the Hub should not need to know anything about parachains.*
• Plaza: A bunch of projects going on in parallel to make a major upgrade to the Hub, focused on improving user and developer experience.

*An example of a Polkadot Hub user story: Someone wants funding for a project, so they set an identity, apply for USDT funding from the Fellowship, it gets approved, and they receive their payout. Identity is set on the People Chain, application and approval occur on the Collectives Chain, and the payout is received on Asset Hub. UIs need not expose anything related to the backend architecture – which logic is on which chain – to the user. This is precisely the motivation behind shared security and the design of Polkadot; talking about products like the Hub as individual chains is doing ourselves a disservice.

[SAXEMBERG]

@tom.stakeplus

Unless we want to increase txn fees on these chains it’s likely there will never be any revenue without payments from governance or inflation.

Thank you for the comment, as a matter of fact these are some of the solutions that we believe could be implemented and used for a transition into an invulnerable free set. Transaction increase and progressive reduction depending on future activity (if needed). Yet still with accessible fees at the very beginning. Due to Polkadot architecture these fees could be low for the user but much higher than current ones at the collator level.

@tunkas

I fail to understand the reasoning behind your wish to see the ‘change to a completely permissionless or at least a permissionless maximized approach to collators’? I am not against such approach if there is merit to it, so I am interested to hear the reasoning behind it.

Polkadot is meant to be as permissionless as possible. Imagine for a moment that AssetHub after Plaza gets significant transactionality and fees. The current collation system is less than ideal for permissionlessness. And if that were to happen a more violent and confrontational update is likely to happen so it’s better to lay down the basics for such transition if it ever were to happen.

@CoinStudio

there’s little chance for these chains to become self-sustaining.

This is what we want to hopefully change.

@CoinStudio

To provide a clear vision, the cost of operating an entire single Kusama system chain collator set is approximately $3,600 per month, while the cost for a Polkadot system chain collator set is closer to $4,000 per month.

We operate validators on Polkadot so we are aware of costs. Polkadot should always remain the main objective for stability and whatever the chain needs, the treasury should be able to provide. As for Kusama, we already hold the view that it needs to take it’s own path as being the eternal livenet didn’t pan out as well and these Kusama operation costs are far above the current and future interest (if it remains on the same path). So if it were up to us, we’d just attempt to migrate progressively to a fully permissionless collator set for Kusama AssetHub right now prior to Plaza, even if the upgrade plan doesn’t pan out. A progressive approach should eliminate these withholding attack risks and frankly, could make staking on Kusama interesting again.

@joepetrowski

W/r/t specifically removing Invulnerables, they are there to ensure that someone is always available to collate the chain. Likewise, the bond-acquired slots are there to ensure that anyone can collate the chain if they want to (they may have many reasons to want to, I’m not to judge).

Aren’t we already at a point where on some system chains like AssetHub we have already more interested parties willing to collate in anticipation of Plaza thus the requirement of invulnerables for such anticipated chains becoming less important?

[joepetrowski]

@SAXEMBERG

Aren’t we already at a point where on some system chains like AssetHub we have already more interested parties willing to collate in anticipation of Plaza thus the requirement of invulnerables for such anticipated chains becoming less important?

No, without Invulnerables, you can end up in the situation where everyone deregisters* and the parachain cannot produce a block. Because the economic incentive is low, it’s a reasonable assumption that one actor could buy all the permissionless slots and perform such an attack. The economic incentives are low because we don’t want to charge users (either via inflation or via higher transaction fees) to pay for collation since it is not really a secure activity and it doesn’t scale (paying validators makes more sense because they secure all parachains, not just one).

I understand that you are probably right, most of the time, in that there is enough interest for slots that people will take them, but that is not the case we are designing for. We are designing to avoid the possibility of the chain completely stalling even once. Given the economic weakness of the permissionless slots (and assumption that a single entity could acquire them all), the Invulnerables are meant to guarantee a diverse group of known collators on the assumption that at least one of them will always be online and able to produce a block. Note that economically this is very different from validation, where slash size increases with the number of simultaneous offenders, so as one entity acquires enough validators to perform such an attack they are exposing themselves to a 100% slash.

As stated in the RFC, the goal is not to make collation profitable. There are other reasons to collate on system chains, like ensuring application liveness. While I recognize that costs like 4,000 USD/month are expensive for an individual, if you are e.g. Tether/Circle and want to make sure that USDT/C are working, this is not a big expense and there are much better reasons to pay it than hoping to recoup it in fees.

Rather than try to reduce the number of Invulnerables, I would recommend lobbying to increase the number of permissionless slots on the chains.

*Not technically true, the pallet won’t let the last candidate deregister, but the last candidate could just not run their node.

[Paradox]

Hi Sax,

Thanks for opening this discussion, I think it’s a great way to discuss a pain point perceived by some new permissionless System Parachain collators who feel entitled to invulnerable slots “right now”.

As I’ve seen most start with disclosures, I may as well do the same. I hold three invulnerable system Parachain collator slots and I’ve paid for the opportunity to be permissionless ones on as many of the other chains as I can afford. I initiated the bounty for funding for System Parachain collators and set out the charter we (System Parachain Collators) follow. I have recently been appointed the role of coordinator which somewhat formalizes the role I’ve grown into within the group.

On to the topic…

Invulnerables exist to provide a group of collators for which there’s little reasonable expectation that they’ll collude to censor or halt transactions.

Let’s work by example, taking an extreme position, we may consider if there were no invulnerables on AssetHub and all slots were permissionless. There is now a calculatable cost to halt or censor transactions for some period. This cost is not as high as one may think, it starts with some token value > the highest bid bond and forces an end position with cost #[permissionless collators] * [min bond].

At present there’s a ratio of about 1:1 invulnerable to permissionless collators. In the scenario above if transactions are being halted by rogue permissionless collators we’ll still have some reprieve from invulnerables albeit after waiting some time.

In short, invulnerables are desired to protect the chain, the next question would be how many are required to prevent the potential issue described above. While some may argue that we only need one, this doesn’t yield the best user experience. I defer to RFC-0007 which I believe takes an informed approach to determining the “ideal ratio”.

I would also respectively challenge your thoughts on invulernable selection being static. The invulnerables were assigned via governance and it can be changed via governance.

As a group the System Parachain Collators have put together a systematic procedure to fairly identify candidates as invulnerables for new chains. The approach favours new entrants who have demonstrated technical capabilities and who are not likely to collude. I can only hope that a proposal to adjust the quantity of invulnerables or existing assignments is done with deep consideration.

Since typing this post I see that Joe’s responded with several points which I resonate with. I agree that the cost to the treasury is relatively low for the importance of the services provided, I didn’t consider deregistration as a form of attack and I agree that increasing permissionless slots might be the way to go here. Go Joe.

Regards,
Will | The guy with a baby

[bLd]

Completely permissionless is very risky with Aura pallet.
Aura pallet is too basic for that, it was not designed for a completely permissionless set.
Ideal situation would be a brand new collator selection pallet, which represents a lot of work.

Still, I’m in favor to reduce number of invulnerable slots.
Also, to be considered hardware requirements should be accounted in rewards: an almost unused system chain requires very few, and a chain destined to be widely used such as AH will require much more.
But to apply that, performance should be measure which is pretty difficult to apply at runtime level (considering we’d like an autonomous reward system).

[SAXEMBERG]

@joepetrowski

As stated in the RFC, the goal is not to make collation profitable. There are other reasons to collate on system chains, like ensuring application liveness. While I recognize that costs like 4,000 USD/month are expensive for an individual, if you are e.g. Tether/Circle and want to make sure that USDT/C are working, this is not a big expense and there are much better reasons to pay it than hoping to recoup it in fees.

thanks for the clarification and position.
Best