# [PROPOSAL 821] [Passed] Gaia v12 Upgrade

Hub Proposals Software Upgrade
1

Change log

  • 2023-08-24 Created initial post
  • 2023-08-25 Prop on-chain

Background

The Gaia v12 release is a major release that will follow the standard governance process by initially submitting this post on the Cosmos Hub forum. After collecting forum feedback, a governance proposal will be sent to the Cosmos Hub for voting.

On governance vote approval, validators will be required to update the Cosmos Hub binary at the halt-height specified in the on-chain proposal.

The roadmap for this and future releases can be found here:

Release Contents

This release contains the major addition of the Liquid Staking Module and a number of updates to core dependencies.

The relevant signaling proposal for the Liquid Staking Module is:

A full changelog and relevant binaries can be found:

Testing and Testnets

The v12 release has gone through rigorous testing, including e2e tests, integration tests, and differential tests. Differential tests are similar to integration tests, but they compare the system state to an expected state generated from a model implementation. In addition, v12 has been independently tested by Hypha.

Validators and node operators can join a public testnet to participate in a test upgrade to a release candidate before the Cosmos Hub upgrades to the final release. You can find the relevant information (genesis file, peers, etc.) to join the release testnet (theta-testnet-001) here, or the Replicated Security testnet (provider) here.

Potential risk factors

Although very extensive testing and simulation has taken place there always still exists a risk that the Cosmos Hub might experience problems due to potential bugs or errors from the new features. In the case of serious problems, validators should stop operating the network immediately.

Coordination with validators will happen in the #cosmos-hub-validators-verified channel of the Cosmos Network Discord to create and execute a contingency plan. Likely this will be an emergency release with fixes or the recommendation to consider the upgrade aborted and revert back to the previous release of gaia (v11).

Governance votes

The following items summarize the voting options and what it means for this proposal:

YES - You agree that the Cosmos Hub should be updated with this release.
NO - You disagree that the Cosmos Hub should be updated with this release.
NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned.
ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

7 Likes
2

Most exciting release in quite some time, bravo

3 Likes
3

According to github:

“// The ValidatorBondFactor dictates the cap on the liquid shares
// for a validator - determined as a multiple to their validator bond
// (e.g. ValidatorBondShares = 1000, BondFactor = 250 → LiquidSharesCap: 250,000)
ValidatorBondFactor = 250
// GlobalLiquidStakingCap represents the percentage cap on
// the portion of a validator’s stake that can be liquid
ValidatorLiquidStakingCap = 50 // 50%
// GlobalLiquidStakingCap represents the percentage cap on
// the portion of a chain’s total stake can be liquid
GlobalLiquidStakingCap = 25 // 25%”

The 25% global cap and the 250 bond factor were mentioned and discussed during the signaling proposal 790. However, this 50% cap on individual validators wasn’t discussed before. So by introducing this cap you are basically setting in stone the current centralization of the Cosmos Hub. Let’s say a small validator contributes a lot and can receive large delegations from liquid staking providers, now because of this cap not possible since can only receive 50% of their current staked ATOM. A cap should be introduced for the larger validators so the centralization doesn’t increase further, not a cap on the small validators also making it even more challenging to improve decentralization. Or this cap refers to currently staked ATOM being directly liquid staked without the unbonding period, not delegations from liquid staking providers? @mmulji @mpoke

4

Hi Cosmic_Validator,

Thank you for sharing your well-thought-out concerns regarding the 50% cap on individual validators’ liquid stakes. I wholeheartedly agree that this is a pivotal issue that deserves meticulous scrutiny, as it can potentially impact the very foundation of network decentralization. Your point about the cap disproportionately affecting smaller validators, in particular, is astute and warrants deeper discussion within our community.

Given the complexity and importance of the issue, I believe it would be prudent to pursue this topic as an amendment contingent on a Yes vote for the current release. That way, we can progress with the proposed changes while keeping the door open for additional refinements that address your valid concerns.

To kickstart the discussion, here are some mitigation solutions that the community might consider:

  1. Tiered Staking Rewards: A system where smaller validators receive slightly higher staking rewards to make them more attractive for staking. This could help in distributing stakes more evenly across the network.

  2. Dynamic Liquid Staking Caps: Instead of a fixed 50% cap for all validators, we could introduce a dynamic cap that adjusts based on the size of the validator, allowing smaller validators to offer more competitive liquid staking options.

  3. Decentralization Bonus: Offer an extra bonus or multiplier to stakeholders who distribute their stakes across multiple validators, thus strengthening network decentralization.

  4. Validator Performance Bonds: Implement a bond system where validators must deposit a certain amount to guarantee performance, which could be partially forfeited in favor of smaller validators if a larger validator exceeds a certain size.

  5. Other Solutions: Open to community input for additional innovative ideas to tackle this problem.

I’m looking forward to hearing what you and the rest of the community think about these proposed solutions. The goal here is to maintain the integrity of the Cosmos Hub by ensuring it remains as decentralized and robust as possible.

I want to specifically highlight the unique position that small validators hold in this ecosystem. Your presence significantly contributes to the network’s robustness, resilience, and decentralization. While each of you individually might not have the same sway as larger validators, collectively, you can make a substantial impact.

I encourage all small validators to pool your voices together. Create a collaborative proposal or statement articulating why adjustments to the current cap are essential for the network’s health. Lobby as a united group to draw attention to this critical issue. Engage with the community on this topic. The more cohesive and vocal you are, the more likely it is that the community will rally behind this cause.

2 Likes
5

Thanks for sharing your feedback and ideas. I think the LSM, if implemented well, could contribute to improving the network decentralization. However, if not implemented correctly it would just contribute to further centralization. The 250 bond factor was introduced so that depending on this validators are eligible for more or less ATOM to be liquid staked. But the individual validator cap of 50% representing the portion of a validator’s stake that can be liquid should be as you mentioned dynamic and favouring decentralization.

The 25% global cap was to avoid liquid staking providers controlling 1/3 of the staked ATOM. But in the Cosmos Hub I’m not aware of any cap on validators to enforce that no validator can get 1/3 of the staked ATOM. What is the justification for this 50% cap for individual validators? Let’s analyse several key points:

-With the 25% global cap only around 55M ATOM can be liquid staked. If a few of the top 10-20 validators have 50% of their current stake liquid the global cap would be reached already very quickly

-Smaller validators may lose delegations if the 50% is quickly reached for them, so that some of their delegators will redelegate to large validators to be able to liquid stake more

The individual validator cap should be dynamic and tiered, for example the top 10 validators can only have 5% liquid, then the next 10 validators 10%, and so on. And from around 100-180th no cap. It is surprising and concerning that in the 790 LSM signalling proposal the 25% global cap and the 250 bond factor were discussed in detail but I don’t remember any mention of this 50% individual validator cap. If I am missing something or some information on github is not updated please let us know @jtremback @zaki_iqlusion because the v12 upgrade with the LSM seems very rushed considering the major implications this could have for the network in terms of potential centralization

6

Why this proposal is exempt from the 14 day discussion period.
What is the logic the LSM is following. The team putting forward this proposal could have tried a bit to explain it to people who are going to vote.
There were only 2 parameters which were included in the prop 790.
1 Max liquid stacked amount. 25%
2 validator bond. where 1 token makes you eligible for 250 LS atoms.

But nothing clear on how the validators will be chosen. What will happen when the 25% limit is reached and a big chunk is undelegated then it will lead to more than 25% delegation. Will it automatically remove some tokens from LSM.

There are so many things to be explained and discussed or the hub is only for the people who can dig deep and understand the code. How does team behind this proposal expect the people to vote if they don’t know how things are going to happen.

7

I just want to speak to the timing and of this prop, and the fact that it is on chain and on forum simultaneously.

The LSM went through months of discussion both before and during the signaling prop: [Signaling Proposal][Draft]Add Liquid Staking Module to the Cosmos Hub - #68 by tom

Then the code went through another month and a half of review here: feat: add LSM to the SDK's v0.45.16-ics-lsm branch by riley-stride · Pull Request #16747 · cosmos/cosmos-sdk · GitHub

We posted this simultaneously to cut down on another month and a half of lead time (2 weeks on forum, 2 weeks in voting + safety buffer on release date). We thought this would be safe given the amount of discussion that has already occurred and how uncontroversial past update props have been. We did not realize a new parameter had been brought in by the LSM team.

If you feel there are still things to change, please vote NO on-chain and we will resubmit. Alternately, if it’s just a param change, then a prop to change the parameter in question can be brought out immediately after this upgrade goes live.

Now, to address the questions about the 50% per validator cap, I will call on @aidan and @zaki_iqlusion

8

@Sumit_Redhu hey

didn’t this signalling proposal give enough details?

9

Hey @Cosmic_Validator @CML @Sumit_Redhu,

My apologies that the Validator Liquid Staking Cap hasn’t been formally defined or discussed. Let me quickly describe the reasoning behind it.

The Validator Liquid Staking Cap is the share of each validator’s total delegated ATOM that can be provided by one or more liquid staking provider(s). For example, if the parameter is set at 80% and a given validator already receives 80% of its ATOM from either LSM tokenized shares or interchain accounts (ICAs) - then Cosmos Hub prevents further LSM tokenizations and ICA delegations to that validator. If the parameter is set at 100% then validators can receive an unlimited amount of liquid staking provider delegations from ICAs, as they can today.

The Validator Liquid Staking Cap is a safety feature introduced to remove the hypothetical attack scenario where a validator spins up a Cosmos Hub node and delegates everything to that node to attempt an attack on liquidstakedATOM holders.

The attack works like this: a malicious validator could attack liquidstakedATOM holders by liquid staking ATOM to their own validator node, then incurring downtime to slash those delegations made to their own node. Those delegations are entirely liquid staked, so holders of liquidstakedATOM would bear the slash penalty.

This safety parameter demands that the malicious validator must attract non-liquid-staked ATOM in order to accept liquid staked ATOM. This would render the attack difficult, even if the parameter were set to a high value (e.g. 90%).

This feature supplements the validator bond factor to protect stToken holders from slashes and the Cosmos Hub from attacks. One way the validator liquid staking cap could be raised in the future (if it’s not initially set to 100%) without loss of security is by slashing validator bond at a higher rate than standard stake.

Thankfully, the attack vector that the Validator Liquid Staking Cap prevents against is fairly unlikely, and this parameter is fully in control of Cosmos Hub governance. So governance can choose to set the parameter to 100%, effectively turning off the parameter. I would recommend that when the liquid staking module upgrade goes live, a governance proposal be introduced to set the parameter to 100%.

10

Yes, we also didn’t realize because the 50% individual validator cap wasn’t discussed before in the signaling proposal 790, we just noticed about this after checking all the github information in detail. It is not fair to introduce a new parameter like that without previous discussion and with potential major implications regarding stake centralization.

Agree with this, the current proposal will pass and most aren’t aware about this new parameter introduced since even you weren’t aware. A proposal should be submitted asap to remove this new parameter and then this new parameter must be extensively discussed before choosing its value, whether dynamic or other ideas, and when this has been discussed and decided then another proposal can be submitted to add this new parameter.

11

Seems like setting the param to 100% would deactivate it

1 Like
12

Thank you for the detailed answer. This attack is highly unlikely because currently Stride and pStake are the largest ATOM liquid staking providers and both have delegation programs in place. I don’t think you or pStake will perform this attack. Moreover, the 25% global cap is precisely introduced to prevent liquid staking providers collectively controlling 1/3 of the staked ATOM. The risk however of this individual validator cap is that centralization will increase likely, because this affects especially the smaller validators negatively both because they are unable to receive large delegations from liquid staking providers and they may also lose delegators who want to liquid stake more since they would redelegate to large validators. I fully agree to introduce a proposal to set the parameter to 100% as soon as the liquid staking module upgrade goes live or even before. Then, the risk of this attack can be monitored and if needed in the future this parameter could be updated with another governance proposal.

13

should this monitoring happen once an attack is performed, or should we prevent it to happen, even if unlikely, and then increase the cap granularly?

14

This attack is: Stride, pStake or other ATOM liquid staking providers setting up a Cosmos Hub validator to slash the holders of liquidstakedATOM.

Preventing an attack to happen is also done regarding incentives. What incentives Stride has to slash the holders of stATOM? I cannot see any incentives to perform this attack, because this would be like slashing themselves and nobody would liquid stake with them after performing such attack. They could just launch the Cosmos Hub validator and not slash but receive all rewards, but they would be negatively contributing to centralization and it would be like a reputational slash as well. Delegators have the same slashing risks with any validator, and delegators are precisely expected to perform due diligence when choosing validators, similarly they should perform due diligence when choosing liquid staking providers. The serious attack is liquid staking providers controlling 1/3 of staked ATOM but this is already prevented with the 25% global cap for liquid staked ATOM.

By monitoring I mean keeping an updated and real-time list of all ATOM liquid staking providers, the amount of liquid staked ATOM each has, to which validators they are delegating and many other variables. Alerts and notifications included in case of any large redelegation or other suspicious transactions, alerts in case of new liquid staking providers or liquid staking providers with a very fast growth.

15

The attack is slightly different. It’s not Stride attacking the Hub; it’s a Hub validator attacking Stride. As Riley said:

The attack works like this: a malicious validator could attack liquidstakedATOM holders by liquid staking ATOM to their own validator node, then incurring downtime to slash those delegations made to their own node. Those delegations are entirely liquid staked, so holders of liquidstakedATOM would bear the slash penalty.

However, as you point out, the delegation program (and the validator bond factor) help to prevent against this attack. This would add a bit of extra security and seemed reasonable given only 25% of stake can be liquid (so a validator having nearly 100% of their stake be liquid seems unlikely, or at least implies LSP delegations are imbalanced).

Since it’s a parameter, setting it is up to Hub governance, and it’s easy enough to change!

1 Like
16

Well, this is as good a place as any to get to the bottom of this parameter. I have a question: isn’t this duplicating functionality already provided by the validator self bond param?

1 Like
17

I agree, it seems to be duplicating functionality provided already by the validator bond factor. Because the malicious validator would also need to attract non-liquid staked ATOM for the validator bond factor in order to accept liquid staked ATOM?

Thanks for the clarification Aidan, but didn’t Riley mention the following also?:

Here Riley mentions a ‘liquid staking provider’ spinning up its own Cosmos Hub node, so wouldn’t then be Stride, pStake or other liquid staking providers attacking liquidstakedATOM holders? Becuase if a malicious validator independent of Stride for example would try to do this attack, wouldn’t this validator need to find a way to convince or trick Stride first so that you delegate all to this malicious validator? Which is unlikely to happen given the delegation program?

18

In theory, validator bond should solve this attack vector. But if validator bond requirements are too high (safer) it’s harder for validators to participate in liquid staking.

The X% cap makes it easy for validators to participate in liquid staking, while protecting liquid stakers against the attack described above. It does make the assumption that attacking validators can’t attract 100-X% stake from normal users so it’s not perfect.

One way to maintain safe liquid staking and guarantee inclusivity for all validators is to do away with validator liquid staking caps and instead implement different slashing rates for validator bond vs. normal stake. Put simply, slash validator bond before slashing user stake. This is something that’s been discussed with the SDK team for the final version of the LSM that eventually gets upstreamed into the SDK.

But, this would be a more involved discussion. To keep the design simple while adding a bit of extra security, this feature was introduced. But, it’s not strictly necessary, and the safety guarantees provided by the validator bond factor are probably sufficient.

Also, @Cosmic_Validator my apologies: my previous response included a typo, I’ve now edited it. The potential attacker is a validator, not a liquid staking provider.

19

Yes I agree with this, and @jtremback and others seem to agree as well. So then another proposal should be submitted to set this new parameter to 100% to deactivate it, would the LSM team submit this proposal on-chain or Informal Systems should do it? @Riley

20

Sounds like a plan. I don’t have anything specific to this proposal. But this made one thing clear, guidelines doesn’t matter when major entities are involved