Did you already do this in the original post? (not sure if I should see “edited” marked somewhere)
Yes. The edit status is rather subtly displayed with the number next to the pencil icon at the very top of the post.
But the text of the post has been reworked from the original version. The thrust is mostly the same, but the order things appear and which things are emphasized is different.
In principle I am in favour of increasing the validator set incrementally over time as this proposal is suggesting. However, I think as @ala.tusz.am said we should keep ICS in mind and the additional overhead that will come with it:
Personally, I would prefer to wait until ICS is live and we have some consumer chains up and running before expanding the validator set.
I share this sentiment, I’m concerned for how increasing the validators set with ICS approaching could impact the performance and coordination of validators for ICS.
Considering how the upcoming upgrade is important for the Cosmos Hub future, I would prefer avoid any extra risk and wait to increase the validators set after Interchain Security is successfully implemented along with the first Consumer Chains onboarded.
1 Like
For most upgrades, validators typically just use Cosmovisor, the upgrade happens at the appropriate time, and the chain goes back to making blocks. Is there something abnormal about the ICS upgrade that’s going to make it more difficult or require something extra on the validators’ ends?
Yes, ICS is not a common upgrade, because it will require that validator will run at least 1 node for each consumer chain, so this will expand the costs for validators. And in the first phase of Interchain Security will be very important to make the whole system sustainable.
Adding more validators right now, also add the risks of having no profitable validators.
More importantly once a consumer chain is onboarded, in order to successfully run a Consumer Chains it requires at least 67% of validators to run that Consumer chain. So adding more validators it will imply more risks to not reach that necessary %.
The first phase of ICS will require a lot of coordination, efforts and additional operations costs from validators. This is why I think it would be better to consider to expand the validators set once an optimal coordination is reached with the current set.
1 Like
A couple good points. I think the community needs to aim their comments at Keplr and Cosmostation. Those wallets present validators to delegators based on total stake, which only further centralizes the network.
We run nodes for both ATOM and MATIC. The wallets needs to act more like the Polygon wallet, which puts the smallest validators at the top of the list and has a banner that asks delegators to please support the network by staking with smaller validators. The Polygon dashboard also has filters where users can see validators based on total stake, performance, commission and random. Here’s a link for your reference: https://staking.polygon.technology/
We wouldn’t be against adding more active validators, but it is important to consider that hardware requirements are going way up in January with the introduction of consumer chains. We are barely profitable at spot #119 currently and our costs are about to rise, so how will validator #190 stay in business? Something to consider.
2 Likes
Is the date for the ICS upgrade firm? I ask mostly because if it’s a month away, there’s no reason new validators wouldn’t be up to speed by then.
If they’re not, it sounds like the worst case scenario would be if none of the new bottom 25 validators are set up to run a specific consumer chain, it would fall on the rest of the validators to do so. I can’t imagine the huge majority of the front page of the active validators wouldn’t – isn’t ICS supposed to generate revenue for the validator and its delegators?
1 Like
Yes, the roadmap is the following:
December 2022
- Signaling proposal on Cosmos Hub
January 2023
-
Final deployment of interchain security on the Cosmos Hub
-
Onboarding of consumer chains (Neutron, and others)
Current validators just ended the game of Chains Testnet that is preparing validators to run ICS Consumer Chains: Interchain Security by Informal Systems
So considering all the preparation done with the current set, I think the most likely scenario will be to go through the initial phase of ICS with the current validators set, unfortunately adding more validators right now brings more risks than benefits.
This is good information. What are the consequences if a bottom-of-the-list validator is woefully unprepared for ICS?
Does that just mean the validator isn’t running a node for a consumer chain and it will fall to the other validators to make sure 67% of them are doing so? (And consequently, that validator wouldn’t generate revenue from the consumer chain?)
Or is there a potential for damage to the actual Hub and not just the unprepared validator?
Going forward, there’s (hopefully) always going to be the next chain requiring coordination between validators, and the next upgrade. In an ideal world, there would never be a perfect place where everything is calm and new validators can just jump in seamlessly.
A note of clarification - ICS isn’t opt-in. If a consumer chain is approved to lease the Hub’s security, all validators must participate in securing the consumer chain.
2 Likes
Totally agree with you. The timing for adding validators is not now.
1 Like