Enabling Opt-in and Mesh Security with Fraud Votes

We’re putting this on the forum to start a discussion about whether it makes sense to create a new type of governance proposal on the Hub which would allow for votes to slash validators or delegators for attacking consumer chains with incorrect execution. Several things are important to note: • This new proposal type would only apply to validators who had opted into an Opt-in consumer chain, or delegators who had opted into a Mesh consumer chain. • It is a temporary measure until fraud proof technology and surrounding systems are mature enough. • This type of proposal is to be used only to slash validators for incorrect execution. It is not to be used to slash validators for downtime on a consumer chain (even if they maliciously cause it to halt), or any other offenses. If we implement this type of proposal we should add text to all governance proposals created stating the above. • Even if the Cosmos Hub does not use this proposal type to enable Mesh Security, it is likely that other Mesh provider chains will. Unlike Replicated Security, both Opt-in Security and Mesh Security allow a subset of the stakers on a chain to contribute to securing another chain. While the…

Excerpt (1196 of 15574 characters). Read the whole post on the forum ↗

I am in support of this because I think that what we have done best with in cosmos is governance. I am not aware of other systems routinely holding votes at the scale that we do in cosmos. Obviously, there’s potential for abuse here, in particular of the “minority rights protection” kind (think like state of delaware courts, for example). That said, this is a sensible and sober solution to the issues at hand that will allow us to grow. jtremback: It is of course possible to run Opt-in or Mesh Security without fraud proofs or fraud votes. In this case, if validators or delegators were to cause incorrect execution, the only option for slashing them would be for the provider chain to hard fork to a version of the state where the offenders were slashed. This would essentially be the same thing as this proposal does with governance, but done with a potentially frantic back-channel hard fork. It could work, but it seems much better for something like this to be done in a controlled and intentional manner with a fraud vote as proposed here. Yeah I think that the YOLO scenario is best avoided. “The slasher” has always been a key differentiator of cosmos. Risk vs…

Excerpt (1197 of 1905 characters). Read the whole post on the forum ↗

I support this initiative. One of Cosmos strengths is governance, so playing to those strengths and fast-tracking opt-in/mesh (before validity proofs are technically ready) is advantageous. I doubt RS will scale beyond a handful of chains, so for the Cosmos to stay at the center of shared security in Cosmos, it will need opt-in/mesh. Clear slashing conditions should also make the Hub more attractive as a mesh provider - consumers have stronger guarantees that Hub validators will be slashed if they incorrectly execute blocks, compared to other chains with similar market caps. So putting additional slashing conditions on validators who opt-in to provide security makes sense: validators must be held accountable for correct execution, and the slashing conditions make the Hub a more attractive security provider. However, broad social slashing is risky - clearly defining a social contract around what exact conditions lead to a slash and what the magnitude of the slash will be is better than governance trying to reason about whether the validator committed an offense/how much the validator should be slashed, after the offense has happened. I do think social slashing is fraught (for…

Excerpt (1197 of 1377 characters). Read the whole post on the forum ↗

Sounds interesting. A bit concerned about the requirement for voters to sync up full nodes, which is expensive. Im also curious as to what is the current landscape for fraud proof systems is like? I mean any major developments that I can read (possibly some papers).

In this nascent phase of ICS V1, I feel like if we provide opt out too soon, many top validators may start opting out of all consumer chains because they don’t want the slashing risk without much incentive. And it will negatively affect the narrative of inheriting $3B worth of economic security.
Apart from that I think the idea is cool.

aidan:

I do think social slashing is fraught (for example, social slashing can undermine property rights - very bad!), so clearly defining the social contract early and having a plan to migrate to in-protocol proofs is essential.

This is what makes me absolutely love working with stride.

What I mean is, I’ve always thought that they really think things through.

Overall as I stated above, and for all of the same reasons that Aiden supports this effort, and @jtremback is proposing it, I’m in support.

Yeah actually right now I’m kind of feeling negative about the opt-out .

My reasoning for that is that I view the lower slots on the Cosmos hub as training wheels and so they should not be excluded, they should be instead exposed to the full difficulty of running a full Cosmos hub validator.

Primary issue is not with lower ranked validators opting out. Its with top rank validators opting out. Lets say top 15 validators opted out from the next CC. The security gets halved since now only 50% of stake is securing that chain.
There is secondary issue with lower ranked validators opting out, and its not about seeing them as training wheels. It’s that their delegators don’t get rewards from consumer chains and as a result a delegator will get more rewards if they stake to a higher ranked validator which can afford to opt-in to all consumer chains. This will lead to stake centralization.

i believe that if the top 15 validators opt out, the security will only go down for a short time, imo, in this case a flow of smaller validators would enter the set, never seen before =) in the case when the entry price grows, the case is imo, alas - worse

Ghazni_Stakecito: In this nascent phase of ICS V1, I feel like if we provide opt out too soon, many top validators may start opting out of all consumer chains because they don’t want the slashing risk without much incentive. And it will negatively affect the narrative of inheriting $3B worth of economic security. Apart from that I think the idea is cool. Opt-in security used to be called ICS v2 and Mesh security ICS v3. With ICS v2 consumer chains can launch with one permisionless transaction rather than going through the governance voting process. This means that many consumer chains may launch with ICS v2/Opt-in Security but then validators will perform in-depth due diligence and only opt-in for those consumer chains promising or only providing higher rewards than the costs to run that consumer chain nodes, hence leading to consumer chain competition and only the best consumer chains will get most of the high security from the Cosmos hub. With Replicated security, the competition is very low, meaning that any serious project putting a governance proposal to become a consumer chain will likely be approved to enhance the narrative of the ATOM economic zone even if no…

Excerpt (1196 of 2366 characters). Read the whole post on the forum ↗

I really like this idea @jtremback.

Getting out in front of this issue with a system that works, leveraged cosmos’s strengths and allows us to build more automated systems is a fantastic approach.

controversially, I think we should drop soft opt-out.