Slashing updates in replicated security

One of our goals at the Informal Systems Cosmos Hub team is to be open and responsive to feedback from the community on our work. For this reason, we aim to get all important governance proposals in front of the community on the governance forum well in advance of voting so that we can modify them with feedback received. We put up the draft Replicated Security proposal on the forum in mid-December 2022. Since then we have received a lot of feedback. This post deals with one piece of feedback in particular, and our modifications to RS in response to this feedback. Slashing in RS Replicated Security ensures that consumer chains have the same exact security and liveness as the Cosmos Hub itself. Part of this is that validators must be punished for consensus infractions on consumer chains. In the current RS implementation, this is done by having the consumer chain send a “slash packet” to the provider chain reporting on any misbehavior by a validator. Once this happens, the slash packets go into a queue known as the “slash throttle” so that validators representing more than a few percent of voting power cannot be slashed at once (more on that later). Once the packets get out of…

Excerpt (1198 of 4748 characters). Read the whole post on the forum ↗

Are you guys aware that the planned update will put ANY operator of Cosmos validators at significant legal risk if they are forced (due to jailing) to validate ALL consumer chains, even if a regulator (think SEC) considers them securities?

At latest in the moment any of these consumer chains pays out validators in their own token and this token is considered a security token, we are all doomed…

@universe

Doesn’t this fall under the domain of governance rather than technical infrastructure?

If I’m not mistaken, the technical infrastructure to off-board consumer chains already exists via the “remove consumer chain” proposal.

Maybe a better place to discuss it is here: Preparing for Replicated Security

We also recommend that all consumer chains be fully audited before being approved by governance, to avoid loss of user funds through normal vulnerabilities, as well as malicious code crafted to send fraudulent slash packets. Are there also safety measures in case the initial release of the code is ok and approved, but malicious code is integrated through upgrades?. They will, however, still be jailed for downtime. One interesting thought is that being removed from the active set is already quite a punishment, even without having a x% of delegations slashed. Because that effectively puts your commission at risk and your reputation. So a simple but effective measure might be to make the period longer after which you can re-enter the active set. That way you already have a simple but effective trigger to make sure your uptime is ok. In the scenario where malicious code on a consumer chain tries to jail every single Cosmos Hub validator at once, the throttling code mentioned above will take several days to jail them all. How will this work when it happens on multiple chains at once? Will that means that we will get a long queue of waiting slashings, which will take…

Excerpt (1199 of 1221 characters). Read the whole post on the forum ↗

Is this mechanism only for use in the case of equivocation and downtime?

Or is it broader scope?

It makes sense from the perspective of protecting the hub from a Byzantine consumer chain.

However equivocation is very serious.

How would we get a double signer out of consensus fast?

Reading this. I think the role of a validator needs an addition - growing ba**s to build for decentralization

Are there also safety measures in case the initial release of the code is ok and approved, but malicious code is integrated through upgrades?. All upgrades should be audited as well. However, the audit to determine whether a chain has malicious slashing code in it is a lot easier to do than the audit to determine if it itself is secure agains attackers. But in general, the overhead of this auditing of all upgrades is a big reason we are trying to move towards an untrusted consumer chain paradigm as soon as possible. One interesting thought is that being removed from the active set is already quite a punishment, even without having a x% of delegations slashed. Because that effectively puts your commission at risk and your reputation. So a simple but effective measure might be to make the period longer after which you can re-enter the active set. That way you already have a simple but effective trigger to make sure your uptime is ok. Jailing already is effectively the main punishment for downtime, not the slashing. This is why we were able to remove the slashing component for greater safety while still disincentivizing downtime. How will this work when it happens on…

Excerpt (1198 of 1819 characters). Read the whole post on the forum ↗

Is this mechanism only for use in the case of equivocation and downtime?

The social slashing mechanism is only to be used for equivocation, as this evidence can be verified by anyone participating in governance. Validators will still be jailed automatically for downtime on consumer chains.

However equivocation is very serious.
How would we get a double signer out of consensus fast?

To actually execute an attack using double signing, an adversary would need to control 2/3s of the stake on the Hub. At this point it would be impossible to remove them using any form of slashing, since they would control everything. Slashing is designed more to enforce the ground rules of PoS, to avoid a scenario where it is economically rational for every validator to validate on a million different forks of the chain.

Social slashing works just as well to prevent this scenario. So while perhaps a double signer deserves to be removed from the set as soon as possible, there is no immediate security risk if they are removed after 2 weeks. Indeed, the unbonding period on Cosmos chains is designed to tolerate evidence of equivocation being submitted weeks after it happened.

Would it be feasible or beneficial, to propose that we have a specific new form of emergency Governance proposals with respect to consumer chain related governance? Essentially social slashing/jailing in the case of a double sign or malicious code, could be automatically proposed and dealt with through Governance, but with a reduced time frame and automatically execution. However, the reduced voting period can still provide enough time to find if there was malicious code involved or if a double sign was legit. Example: (X) validator, commits a double sign on (Y) consumer chain. If these types of double signs can be logged in an on-chain queue, maybe this queue could automatically trigger some form of emergency proposal to be automatically sent to on chain governance. This same governance, emergency prop, could automatically slash (X) validator, if the proposal passes. If for example, there could be a standard slashing packet module in both the Hub and Consumer chains, mandatory for each consumer chain to utilize for the specific purpose of social slashing. This slashing packet module would log the double sign in a queue, and automatically trigger the emergency proposal, which…

Excerpt (1198 of 2049 characters). Read the whole post on the forum ↗

jtremback:

The social slashing mechanism is only to be used for equivocation

Then it is easy for me to support these updates to replicated security.

I have been absentmindedly concerned about byzantine consumer chains, and this is a good way of ensuring that a team doesn’t launch “SlashChain” which somewhere in its code has buried:

Report xyz vals for equivocation and rekt them.

Overall I think the likelihood of an unjustified social slash is lower than the likelihood of a SlashChain.

This is essentially what we have, except the proposal must be submitted by a human. This is not likely to change the security properties.

Gotcha, thanks for the clarification on that.

I understand wanting to have social slashing in the event a consumer chain has a major bug that slashes a large set of the Hub’s validators, but I have concerns. We have already seen governance takeover for Prop 82 where off-chain agreements were likely made to kill the prop. Can’t this exact same issue can happen to slash specific validators as a form of retaliation (not like it’s too far fetched given how divided part of the community are for the vision of the Hub). Validators need to be held accountable to do deep due diligence on the code. With that being said, why not do the exact opposite. Slash if a validator does something seemingly malicious, but instead of burning funds it’s held in a separate pool. We then create a bipartisan/neutral governance council (voted on by Hub community) that decides whether that slashing event was warranted (was it bad consumer chain code everyone missed, or was it actually malicious validator behavior). If the former, return funds back to slashed validator. If the latter, burn the funds. Eigenlayer is going down this path. It puts onus on the validators to still audit code, it creates a neutral third party (voted by governance and…

Excerpt (1195 of 1459 characters). Read the whole post on the forum ↗

We have already seen governance takeover for Prop 82 where off-chain agreements were likely made to kill the prop. Can’t this exact same issue can happen to slash specific validators as a form of retaliation (not like it’s too far fetched given how divided part of the community are for the vision of the Hub).

Just to be clear, the governance-gated slashing in RS cannot be used for general-purpose slashing of validators. It is not possible to create an equivocation slashing proposal without a slash packet having been received for that validator from a consumer.

So given the very limited use-case here of governance acting as nothing more than another layer of safety to approve slashing events that have already been transmitted by a consumer chain, I don’t think that concerns about slashing being misused are relevant in this case.

We’ve written an in depth analysis of the the effects that governance-gating will have here: Informal Blog — <!-- -->Governance-Gated vs. Automatic Equivocation Slashing

TLDR; The only concrete changes are that evidence will need to be submitted within a week for the governance vote to finish in time, and consumer chains will need to reduce their IBC trusting periods to 5 days.

Appreciate the quick response! Thanks for the clarification.

All systems Go!

Associated discussion:

Prop 818 Discussion Hub Proposals

Greetings Cosmonauts, 818 has gone up without a forum venue for community dialogue. LOA Labs validator is opening it up here to complement the discussion on Twitter and elsewhere. Why this is such a fascinating and consequential governance proposition? See @dimiandre twitter post: "… Prop 818 on is so much fun Assuming that no one votes for the best of the network but only for their own interests we have: - Validators voting yes to free some space in set and harm a competitor - Validators …

Associated Discussion:

[Sane Defaults] Universal use of remote signers Conversation

The community consensus is quite clear that using a remote signer is the correct way to configure one’s validator. Why doesn’t Notional use a remote signer? human error I personally call validators after they get slashed. In the case of this most recent slashon the hub, one of them is a dog and so I haven’t called them. The other is @serejandmyself and I haven’t called them because they have produced very detailed documentation on the incident. Both were victims of human error – and not usin…