Preventing intersubjective faults in ICS

Hub Proposals CHIPs
1

This is a discussion about preventing misbehavior by validators on consumer chains, for offenses other than double signing. These are defined as “intersubjective faults” by the EIGEN paper, but it is a topic we have been studying in the context of Interchain Security for years.

The approach we are advocating for here is:

  • First, to define precisely what constitutes various types of intersubjective faults.
  • Second, have a social contract in place that validators committing these faults should be punished by a hard fork of ATOM that takes away their stake, in the worst case scenario.
  • Third, build a governance proposal that slashes and tombstones them without the need for a hard fork, unless governance is compromised.

With this approach we will have a system which provides protection against intersubjective faults comparable to that provided by the EIGEN token, but which is much smoother since it will not require a fork for every single dispute (and will never require a fork at all unless governance is seriously compromised).

But first, some background:

Slashing for equivocation

The only type of serious validator misbehavior that is currently slashed for on the Cosmos Hub is equivocation (double signing). There are a few reasons for this:

  • Equivocation is one of the few types of validator misbehavior that cannot immediately be detected by a full node. This means that slashing is important to stop it, since a security conscious user (such as an exchange) cannot just run a full node to rule out any double signing attack.
  • Equivocation is also one of the few types of validator misbehavior that is easy to prove on chain. All it takes is comparing a few signatures. Incorrect execution cannot be proven on chain without fraud or ZK validity proofs, using cutting edge cryptography that is generally not production ready yet. Oracle attacks, liveness attacks, and censorship cannot be proven at all.

Slashing for intersubjective attacks with forks

However, it is important to stop several types of attacks other than double signing, especially for consumer chains, due to the “subset problem”. A few of them are:

  • Incorrect execution: Breaking the rules of the protocol, such as making new tokens out of thin air.
  • Oracle attacks: Claiming wrong values for values reported to chain logic when validators are acting as oracle nodes. For example: reporting the price of 1 BTC to equal $1 when the real price is very different from $1.
  • Liveness attacks: Maliciously stopping a chain or severely impairing its operation by refusing to sign valid blocks or include valid transactions.

These are known as “intersubjective faults” (thanks to Eigen Labs for the name). They are obvious to human observers but not provable to machines. These types of attacks are prevented on PoS blockchains, including the Cosmos Hub, by the fact that the chain can be hard forked to slash and remove the malicious validators. In fact, the EIGEN token design is intended to replicate the type of forking that is possible on a chain, but in the context of a smart contract.

Fault resolutions

Since forking the chain’s entire state just to punish a validator requires a lot of work and attention from the developers and the community, we are creating a special type of governance proposal- the “fault resolution”. This can be used to slash validators with a vote without a fork needing to take place. If the governance system is compromised by bribing or collusion, a hard fork can still take place, so this type of governance slashing does not introduce any additional security assumptions over a system (such as EIGEN) which only uses forking.

Fault definitions

We’re currently working on “fault definitions” for these types of misbehavior to ensure that the question of whether or not it happened in a specific instance does not become contentious. This will help prevent debate about whether or not something should be slashed for (as happened with prop 818), and allow the community to focus on the facts of what took place.

These fault definitions can be used in the event of a slashing by forking, and these fault resolution governance proposals are designed to be used together with good fault definitions.

Incorrect execution fault definition

Preamble:

This guideline is intended to define incorrect execution so that validators using it to attack a consumer chain can be punished with social forking or social slashing.

Incorrect execution is when a validator does not follow the basic rules of the protocol. Some examples:

  • Creating money out of thin air
  • Removing money from a user’s account without them having sent it

In general, incorrect execution is any state transition that is not supported by the generally accepted full node software of the consumer chain.

Defined Terms:

Generally accepted full node software: This is the full node software which can plausibly be said to be generally accepted, meaning that a user following the chain’s development with a reasonable level of vigilance and due diligence would be running this full node software

General Provisions:

In order to be guilty of incorrect execution, a validator must have:

  1. Proposed or signed a block which is not valid according to the chain’s generally accepted full node software.
  2. Validators must have had a plausibly malicious motive for signing the block in question.
6 Likes
2

I already saw a discussion somewhere on GitHub issues on a proposal type to slash a validator. (UPD: Found it: Make a slash governance proposal · Issue #10917 · cosmos/cosmos-sdk · GitHub) Can these two be merged? E.g. a proposal suggesting to “slash a validator by 1% but leave them in the active set” or “slash a validator by 5% and kick them out permanently”.

Also, some of the things, like oracle attacks/liveness attacks can be also slashed for on chain, like AFAIK on Kujira if your price-feeder reports the data that differs severely from what others are reporting (or doesn’t report at all), your validator is jailed, so it makes sense to add these as a separate slashing/jailing reasons.

3 Likes
3

Introduction:

We are thrilled to see this concept being introduced to the public. These solutions have been under development in the Cosmos ecosystem for quite some time, long before the introduction of EigenLayer’s intersubjective slashing. While some may view Eigen as an innovator in this area, it’s important to remember that Cosmos has had this capability since its inception. Thanks to the SDK’s governance module, which can execute actions based on vote tallies, Cosmos has always had the ability to slash participants based on subjective criteria. However, the Eigen paper presents interesting mathematical approaches to resolving this problem with efficiency, which could be valuable to draw from.

We look forward to participating in this debate and the next step of the CHIP process, which will be the “signaling phase,” expected to follow this early community feedback gathering.

Feedback & Suggestions:

Regarding feedback, at Govmos, we recommend drawing inspiration from the Eigen math presented in their whitepaper. Specifically, we suggest leveraging the newly accepted permissionless CosmWasm integration on the Hub to create logic similar to Eigen’s. This would involve creating mirrored versions of committed ATOMs in a separate smart-contract based consensus bucket, accessible only to interested parties in each local “subjective consensus.” Each consumer candidate would have its own declared sub-group with a unique identified tied to its consumer ID. The participating validator set for that consumer ID could be accessed directly from the gaia keeper, and once subjective misbehavior is submitted to this consensus, a local fork of this particular sub-group would be initiated. The resolution would follow steps and mathematical processes similar to Eigen’s, isolating the resolution process and preventing the bloating of the general governance system. Only involved parties would participate in the conflict resolution, and in cases where local governance is compromised, the issue could be escalated to general governance.

Furthermore, we suggest evolution in future version should consider extending this feature to the wider Interchain ecosystem beyond consumers. By using IBC as a mediator for messages, any connected chain could utilize this complex fault resolution system, using ATOMs as collateral. These chains would remain sovereign for classical faults and execution slashing via their own consensus but would rely on the Hub to resolve these more complex “intersubjective” issues. They would “rent” the associated collateral security, creating their own “sub-set” within our system. This sub-set would fork and request resolution upon any subjective slashing submission.

Conclusion:

As @jtremback rightly explained, this system would not cause any forks in ATOM. Instead, it would create bonded representations of ATOMs in a dedicated smart contract, which would handle the subjective slashing resolution. This process involves the losing parties transferring their staked value to the winning parties after conflict resolution. The actual mechanism is, of course, more complex, and we recommend reading the whitepaper for a full description of the process, as it involves multiple variables to balance proper incentives to resolve quickly and efficiently.

Thanks for reading,
Govmos.
pro-delegators-sign

6 Likes