Consumer Chain on-boarding and centralization - Chorus One Research

The goal of this post is to gather feedback on our centralization concerns around the on-going onboarding of consumer chains to the Cosmos Hub.

Upfront, it is important to note that our concerns relate to the economics of the current consumer chain model in general - a fixed, minority revenue share with limited opt-out.
As the vote to on-board Stride is currently live, we will use this case as a revenue proxy for past- and future consumer chains.
This is not an assessment of any particular consumer chainā€™s characteristics or growth perspective.

As such, we have and will continue to vote ā€˜Abstainā€™ on all related proposals until we feel that a more systematic and sustainable model has been agreed upon.

While running a validator incurs fixed costs, the revenue collected from consumer chains is variable as a function of voting power.
Currently, for a majority of the validator set, this revenue stream appears insufficient to cover the fixed cost associated with operating an additional node for a consumer chain.

Therefore, this manifests as centralization pressure, including in the following ways -
Small validators may need to terminate operations, causing delegators to seek out more stable options, i.e. delegate to large validators.
Small validators especially may have to compromise on cost, decreasing their security and consequently attractiveness.
Large validators will have relatively more income at their disposal.

This situation can be framed as a fixed tax imposed on the validator set. Small validators may not be able to afford it, leading delegators to prefer large validators over the long run.
Large validators now control more stake, and delegators earn higher yields due to consumer chain emissions.
However, this benefit is generated at the expense of decentralization, i.e. staking on Cosmos Hub just shifts on the risk <> return curve.
Large validators win, delegators ostensibly win, small validators lose.

Letā€™s dive in: Consumer Chain on-boarding and centralization - Chorus One research - Google Docs

Please access the link above for the full analysis.

10 Likes

Yep. This has been the talk between smaller teams for a while now. I would imagine most of us starting to close nodes after a couple more chains are onboarded. We have to cover up to 10k monthly just in salaries from our own money for a while now. Let alone server and other running costs. I would imagine that at this rate, most small validators, operate at between 50 - 80% loss. For example onboarding stride next is going to send us to -90%. I also didnt notice the concern that general security will, and is already, going down. To save costs, validators will first of all cut server costs, then team costs. This of course, is also a huge security issue.

PS. thanks for the analysis

6 Likes

I tend to view these economics as inherent to Proof of Stake as it matures.

You are going to see the same thing play out with Ethereum + Eigenlayer.

Larger operators will be able to support more and more rehypothenication of security and more atomic composability guarantees as cross domain composability takes off.

The general idea of small validators as economically viable isnā€™t sustainable and never was.

1 Like

Agreed, but we wanted to highlight and put it to paper either way.

Opt-in as in Eigenlayer at least theoretically allows smaller operators to still just validate Ethereum. Though I agree the ā€œpressureā€ will be to support more services to provide competitive rewards.

If onboarding is forced, it feels to me like a more competitive/market-based model for on-/offboarding consumer chains might be preferrable to the current governance-based approach. That sort of goes in the parachain slot auction direction.

Currently, Iā€™m not so clear about the process of how the Cosmos Hub would offboard an underperforming consumer chain. Who would initiate this?

5 Likes

@lexa and I wrote a thread about this: Scaling up with conditional basic income

The ensuing conversation discusses some of the design space around this and is heavily related. Would it be worthwhile to have those threads merged?

4 Likes

Your concerns make a ton of sense and Iā€™ve been thinking about the same things for some time. I definitely agree we should be having more conversations about the effects of replicated security on centralization and validator sustainability. This is a big part of why the Duality proposal will suggest routing 100% of network value from the deployment back to the hub.

Longer term solutions are needed. Here are some of the ones that have come to mind in the past.

Facilitating replicated security chain M&A. While not every case will make sense for this, it feels likely that some might. This would void the fixed costs of adding additional consumer chains as no new chain needs to be spawned. That said there are high coordination costs for something like this as previously disconnected teams will need to become closely aligned in vision and roadmaps.

Rollup Centricity. Another thought would be for future versions of ICS to endorse rollup-centric architecture. In this world Replicated Security chains can act as settlement, sequencing or DA layers for rollups. With the introduction of Celestia into Cosmos, my guess is that itā€™d be best for the hub to align itself with Celestia through the former functionalities (Settlement and Sequencing). Nick White has talked at lengths about how to use the Hub for these as well and I agree that strong alignment is in the best interest of both. Weā€™ve been working on some of these things at Duality Labs recently, would be happy to chat more about it on a call sometime.

5 Likes

its about education, education and more education. currently there are loud voices around the hub screaming for diversification and screaming for making val commissions hard-coded, no more than 5%, etc. This does not make any sense. Smaller validators shouldnā€™t be blackmailed by (foundation or anyone else) delegation policies (if you have less or more than X percent, we will not delegate to you). It is exactly for this cases that the com rate exists. To balance the in and out. Its becoming a bit strange tbh

3 Likes

This is something I extensively pointed out and talked about. I do share the same concerns.

Itā€™s finally time to hear from validators which are now in trouble.

I can not agree more on @serejandmyself ā€™ s take, education education and more education.

I am really hoping that some super heroes come to our rescue.

2 Likes

Insted of increasing and capping commissions there should be more viable options that wonā€™t hurt the community or strain validators even more now that cosmos hub is getting more complex for itā€™s validators.

I do not know technical knowledge needed but this is just an idea. A solution to this might be found on polkadot but with a few twists. As I understand there is auction for parachain slots. What if this was implemented for cosmos hub in some form?

Instead of providing only a portion of fees/and inflation every new chain should pay for validators maintenance costs. I am not sure what are costs of running a node on cosmos but running 2 servers(1 validator and 1 sentry) are at least 400$ a month give or take depending on how they run these servers (correct me if i am wrong here). So with the current validator setup of 180 validators the cost to run basic setup for a year is around 1 million $.

The idea is this every new chain that wants to join ICS should be able to pay 1 million in ATOM. This atom should be vested duruing 12 mouths and payed to the validators every month. Also it should add a portion of fees and inflation(if token has inflation) to all stakers.

So for example chain A wants to join ICS it should have 1 million$ ready to give in atom and give 10% of fees and inflation duruing the first year. After 1 year a new governance proposal should be initiated and looked into this chain. If this chain A has substantial revenu to cover with basic operation fees of the validators then the terms should be altered. For example maybe increasing higher % of fees and inflation given to atom stakers.

If chain A doesnā€™t have enough revenue to cover basic needs for the validators then terms should stay the same or if the community decides that chain is not good enough stop supporting from ICS and shutting down nodes for chain A.

Polkadot has a feature Crowdloan. So if chain A has a good plan and idea community could in turn pay atom needed for ICS and in return chain A can airdrop tokens to people who supported them.

For this to work there would need a lot of changes needed on the hub. But like I said just an idea. It could be more viable than the current ICS module. The benefit here is that chain that wants to join ICS should have at least some skin in the game. I think this way the chain will at least try to make a viable product that will give results.

Thoughts on this?

1 Like

Welcome to the forum @Kamikaza731 and thanks for sharing your ideas!

This is in some ways similar to proposal that @pupmos made here: A Formal Proposal for Enhancing Cosmos Hub Interchain Security Mechanism Design

Itā€™s an interesting idea to explore and should definitely be considered. I find the crowdloan concept a nice touch that would help me get behind something like this a lot more.

As an additional resource, thereā€™s a group of folks discussing this in relation to the @duality proposal here:

1 Like

@zaki_iqlusion Iā€™m curious what the initial vision was then, i.e. for a few large validator companies to control the majority of stake, like what we have today?

If thatā€™s the case, whatā€™s the difference between that and the current legacy economy and the power structure it enables?

Maybe Iā€™m naive but I thought we were trying to do better than that here?

cc: @Othman

3 Likes

Our thanks to @ChorusOne-Research for conducting this research and publishing the resuts.

Chainflow falls in the category of ā€œ52.7% (95/180) of validators on the Hub have a voting power of <= 0.2%.ā€

Although we could opt-out of supporting Neutron, i.e. within the very limited opt-out window, as part of our long-time and continued support of the Hub, we decided to support it as an ongoing experiment.

(Note that Neutronā€™s recent $10 million VC raise has given us pause. We will re-evaluate our support based on factors such as token allocation and the decision whether or not to make it public. We also believe that it was probably a mistake to onboard the chain prior to a token allocation being made public and will take that up under a different forum post.)

As such, this research rings true to us. We also note that it assumes a single validator/backup configuration. Add sentries and the picture looks even bleaker.

During the earliest pre-mainnet testnets, I remember @zaki_iqlusion reminding us that while we were all vying for a spot as a hub validator, there would be many more opportunies to validator on other chains too.

Pre-ICS weā€™ve seen a number of smaller validator operators emerge, who punch above their weight and contribute value that is multiples greater than their relative size. Now that ICS has been adopted, that path has become constricted.

Weā€™ve seen since the Hubā€™s launch that relying on human altruism to decentralize stake doesnā€™t work. We believe itā€™s time for in-protocol incentives and disincentives to be implemented, if we truly want to decentralize stake beyond where it is now. Itā€™s our hope that this type of research and related conversations will begin to take us in that direction.

#KeepStakeDecentralized :mechanical_arm:

P.S. - As part of our Nebular Builders sponsorship, we have space for validator-specific programming. Weā€™d like to invite the @ChorusOne-Research team to present this research in the space and we can moderate a conversation realted to it.

cc: @Othman

4 Likes

Wait a minute. Letā€™s unpack this.

Zaki, do you agree that the economic viability of small validators is at least desirable (leave aside feasibility for now) or not?

4 Likes

Thanks for sharing the analysis. Just some comments:

  • Suppose just the Hub without any consumers.
  • If we do not consider the engineerā€™s salary, a validator needs around 70k Atoms to cover the cost of the full node (using a commission of 5% and an Atom price of 10$).
  • With the engineerā€™s salary, a validator needs around 1,250,000 Atoms to cover the total cost (127,200 $/year). Hence, only 40 or 45 of the current validators in the Hub would be profitable.
  • Many validators are probably paying less to the engineer. But previous figures show that the profitability/unprofitability of the validators is already there. It is not due to RS.
  • RS could help improve that situation since there are some economies of scale if the engineer can maintain ~8 networks.
  • This improvement will not be immediate.
  • One ā€œproblemā€ with the current design of RS is that it provides $2.5 B of security to chains that need a tiny fraction of it. New chains cannot afford such high security.
  • Another relevant point is: why are the chains the ones that make the offer? It could be the other way around. The Hub can set a price for its service. Or a two-part tariff, with a fixed amount plus a variable part as a function of the consumer Market Cap. Or, the Hub makes a menu of offers/contracts and a chain that aspires to be a consumer has to choose an offer/contract to include in its proposal. E.g., the menu can have three contracts, each with different levels of security (in terms of $ and number of validators) and price. Etc.
2 Likes

5% should be the minimum commission allowed. O% commission nodes should be against the rules.

A tax imposed on staking with larger validators would also help the network decentralize. We would be in favor of a progressive tax levied in traunches, top 25 validators pay the highest tax to community pool, next lower traunch tax is levied on validators 26-50, the next lower taxed traunch is 51-75, etc.

1 Like

and you didnā€™t even take into account the fact that some validators have a lot of other salaries to pay for the services they are creatingā€¦

2 Likes