V9 Lambda upgrade (with Replicated Security)

Terminology note: Interchain Security is the name for a family of protocols. The feature being discussed here is in this family, but more accurately termed “Replicated Security”. In the past it has been referred to as Interchain Security v1, or ICS, but going forward we refer to it as Replicated Security.

Summary

This on-chain upgrade governance proposal is to adopt . By voting YES to this proposal, you approve of adding these updates to the Cosmos Hub.

The Cosmos Hub is upgrading its security system with a new feature called Replicated Security. This will allow the Cosmos Hub to provide its strong security to other blockchains, which are called 'consumer chains'. The cost to censor or control a consumer chain with an economic attack is the same as the cost to censor or control the Cosmos Hub itself. This means that consumer chains can benefit from the Cosmos Hub's security without having to maintain their own validator sets.

Replicated Security works through the IBC protocol. Consumer chains receive periodic IBC packets containing the up-to-date validator set of the Cosmos Hub and use this to update their own validator sets, effectively replicating the Hub's validator set. This means that the Cosmos Hub's validators can validate multiple chains at once with the same stake.

In exchange for this service, consumer chains are expected to send a portion of their fees and inflation to the Cosmos Hub validators and delegators. These tokens will then be included as part of the Cosmos Hub's staking rewards.

Software details

Updates

• (feat) Add Interchain-Security v1.0.0 provider module. See the ICS Spec for more details.
• (gaia) Bump cosmos-sdk to v0.45.13-ics. See CHANGELOG.md for details.
• (gaia) Bump ibc-go to v4.2.0. See v4.2 Release Notes for details.
• (gaia) Bump tendermint to 0.34.26. See CHANGELOG.md for details.
• (gaia) Bump packet-forward-middleware to v4.0.4.
• (tests) Add E2E ccv tests. Tests covering new functionality introduced by the provider module to add and remove a consumer chain via governance proposal.
• (tests) Add integration ccv tests. Imports Interchain-Security's and implements Gaia as the provider chain.

On-Chain Upgrade Process

When the network reaches the halt height, the state machine program of the Cosmos Hub will be halted. The classic method for upgrading requires all validators and node operators to manually substitute the existing state machine binary with the new binary.

Alternatively node operators can use the Cosmovisor utility to swap the binaries automatically. Cosmovisor also includes the ability to download the binaries automatically before swapping them. Documentation on Cosmovisor can be found here. If you are interested in trying Cosmosvisor with a simulated local upgrade please see the local testnet documentation.

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.

Cosmos Core Contributors will coordinate with validators in the #validators-verified channel of the Cosmos Developer 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 (v8.0.1).

Governance votes

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

• YES - You approve of adding these updates to the Cosmos Hub.
• NO - You don’t approve of adding these updates to the Cosmos Hub. Please indicate why on the Cosmos Hub forum.
• 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 quorum but you formally decline to vote either for or against the proposal.

Appendix: Replicated Security

Changes to this proposal

This proposal went onto the governance forum in mid-December. Since that time, we have made one change to the protocol. In response to the only high-severity finding in the Informal audit report (see 'Testing and audits below'), and feedback from the community, we have made it so that the slashing and tombstoning of validators for offenses on consumer chains must be approved by a governance vote. This will have a very minimal impact on the operation and security of consumer chains while protecting the Cosmos Hub from possibility of an attack by a rogue consumer chain.

This governance gating is temporary until the Cosmos Hub is able to cryptographically verify proof of double signing in an upcoming release of Replicated Security. This does not give governance the ability to slash validators arbitrarily, but rather to approve slash packets that have already been transmitted from a consumer chain.

The ATOM economic zone

It is anticipated that consumer chains using Replicated Security will collaborate closely in an 'ATOM economic zone'. This is expected to have a snowball effect, with the Cosmos Hub securing a growing group of high-value decentralized protocols. Already, some prominent projects such as a smart-contracting platform, an AMM, several liquid staking providers and others have expressed interest in using Replicated Security from the Cosmos Hub.

Replicated Security can also be used to further the cause of “Hub minimalism”. Any new features to the Hub, even if they are core to the Hub's functionality, can be launched as consumer chains. This allows the Hub to scale better and separate release cycles, enabling faster deployment of new features.

Onboarding a consumer chain

This governance proposal will not launch any consumer chains on its own. Instead, it will only add the necessary code to the Cosmos Hub to enable Replicated Security. In order to launch, each consumer chain must submit their own governance proposal to be voted on separately.

It is expected that before launch, a consumer chain will have participated in a Cosmos Hub Replicated Security testnet, conducted their own testnets, and undergone an audit by reputable auditors.

Once a consumer chain proposal passes, Cosmos Hub validators can begin running the consumer chain and receiving rewards. The chain will only start if more than two-thirds (by power) of the Cosmos Hub validators decide to run the consumer chain.

Offboarding a consumer chain

Once the consumer chain is running, validators can be slashed and jailed for consensus faults such as downtime and double signing on the consumer chain.

At any point in time, one-third (by power) of the Cosmos Hub validators will be able to stop running the consumer chain at once: the chain will halt, and none of them will be slashed for downtime.

The offboardings of consumer chains will have strong social norms to protect both sides, and any kind of forceful exit will only be coordinated in extreme cases such as protocol failures or attacks.

For normal cases, a separate governance proposal will be made to remove a consumer chain, which will allow Cosmos Hub validators to stop running it.

Further resources and information:

Archival links

• IPFS pin of unabridged proposal text
• Forum discussion

Essays and detailed feature explanations

• Preparing for Replicated Security
• Governance-Gated Slashing vs Automatic Equivocation Slashing

Testing and audits

• Informal Systems Audit team results
• Findings from Game of Chains and Beyond
• ICS software tests