Securing Cosmos - all you need to know about Interchain Security

By Alex Ausmus

The act of securing an ecosystem of sovereign blockchains becomes increasingly difficult as the number of blockchains, users, and developers grow. To sustainably grow a modular, multichain ecosystem, such as Cosmos, the ability to secure multiple execution environments with a single validator set is important. This is the idea of shared security. There are a number of shared security solutions (i.e. rollups, sharding, Polkadot’s Relay Chain), all of which are tailored to their ecosystem’s architecture. Cosmos’ answer to shared security is called Interchain Security.

Shared security is a broad subject; one can even think of the relationship between Ethereum and the smart contracts built on top as shared security. All the applications deployed to Ethereum rely on the security provided by Ethereum. While very generally this is true, more often shared security refers to a horizontal scaling solution. Horizontal scaling is typically accomplished by either splitting up responsibilities between various network participants, or by offering multiple channels for computation.

Rollup technology, for example, falls within the realm of shared security. Let’s consider an optimistic rollup: Rather than requiring all transactions to be executed on the settlement layer (e.g. Ethereum), there is a new network participant called a sequencer whose job is to ‘roll-up’ many off-chain transactions into an on-chain single transaction. The sequencer interacts with the settlement layer similar to how a block building entity builds and hands off a block to a consensus group. What’s really interesting about how a sequencer works in an optimistic rollup is that this role can be fulfilled by a single entity and remain trustless (in the sense that anybody can submit a fraud proof and have the sequencers’ work checked). The rollup architecture allows for anyone to check the sequencer's accuracy, not just a dedicated group. The incentives align to enforce the correctness of the sequencer. This architecture differs from Cosmos and Polkadot's shared security models, in that optimistic rollups use fraud proofs to secure off-chain transactions instead of having block building of multiple blockchains in parallel.

The most comparable shared security model to Cosmos’ Interchain Security is Polkadot’s Relay Chain and parachain architecture. Polkadot is an ecosystem composed of a central blockchain (the Polkadot Relay Chain), which provides security to multiple application-specific blockchains, called parachains within the Polkadot ecosystem. Parachains have dedicated block building entities, called collaters, which send the parachain block headers, along with associated validity proofs, to the Relay Chain for validation. In Polkadot’s shared security, the responsibility of block creation and validation is separated between parachain collators and Relay Chain validators. This means that the state transitions of all parachains must be validated by the Relay Chain, which may create a theoretical computational bottleneck. Whether this poses a technical hard limit of the number of parachains secured by the Relay Chain is yet to be seen - all blockchain technology, especially shared security, is quite nascent. 

At a high level, the primary goal of both Polkadot and Cosmos’ shared security models are the same - to lower the barrier for launching application-specific blockchains with high security guarantees. Consider an ecosystem without shared security, vastly more validator operators are needed to secure the ecosystem. While there is often overlap of validator operators between appchains (a term used in Cosmos equivalent to application-specific blockchains), there is a limit of how many chains any validator operator can support, as they are expected to do more than simply run the software. They often need to participate in governance, secure and maintain a position in the active set, engage with the community on discussions, and provide technical assistance during emergencies among many other things. Shared security is one solution to offset the costs associated with independently validating multiple blockchains. By allowing for a single blockchain to secure multiple appchains, the requirement for growth shifts from the number of unique validator operators in the ecosystem to the economic security of the central security provider and their ability to run multiple nodes effectively.

If you’re looking for a refresher on application-specific blockchains, you might find this article helpful. 

At a high level, Interchain Security allows for validators on a provider chain (e.g. the Cosmos Hub) to use stake on that chain (e.g. staked ATOM) to participate in consensus of a consumer chain in parallel. (A provider chain is a blockchain that allows its validators to secure another blockchain with its stake. A consumer chain is a blockchain that allows another blockchain’s validators to participate in its consensus.)

Source: Informal Systems

As Interchain Security relies on efficient and secure communication of cross-chain information, it requires integration into the inter-blockchain communication protocol (IBC) application layer. Additional IBC functionality is introduced with an interchain standard (ICS) and is then built out and integrated into an IBC release. For example, the interchain accounts feature was formally introduced with ICS 27: Interchain Accounts and is being released in waves based on development time and dependencies on other software. The first interchain account features were released in IBC v3.0.0, and are being integrated into blockchains as they upgrade their IBC software. Interchain Security requires integration ICS 28: Cross-Chain Validation. 

Looking for a refresher on IBC architecture and functionality, we have an in-depth article and the ICF has published an ELI5. 

Shared security is typically accomplished by splitting up responsibilities between various network participants, or by offering multiple channels for computation. In Polkadot’s model, block building and validation is done by separate participants, collaters and validators, respectively. Interchain Security has a single network participant that supports multiple channels of computation. The validators of an Interchain secured zone operate validator nodes for both provider and consumer chains. Trust in Interchain Security comes from the fact that it is the same exact validator set that builds blocks on both chains. In Polkadot, trust comes from the fact that exogenously built blocks must pass through a checkpoint before being handed off to the validators.

While it is very convenient to simply trust a strong validator set to run other blockchain software, this model does place a lot more pressure on validator operators. Provider chain validators run software for multiple blockchains and in the first iteration of Interchain Security, they are required to run the governance approved consumer chain’s software. It may seem like a lot of work to reach consensus on multiple blockchains, but that’s not actually where the difficulty lies. The most overhead related to Interchain Security comes from storing and processing the data, not necessarily achieving consensus. What’s great about this is that, storing data isn’t essential to consensus - think rollups. While it’s ideal to be able offload data availability requirements to rollups, these solutions will not be available at launch. But since the consumer chains are governance-gated, the community will manage the added validator load until there are data availability solutions. Conveniently, there is an IBC-native, data availability protocol, Celestia, in the works. 

Not all consumer chains are equal — some will require large amounts of disk space, and others will require much less. There will actually be two distinct types of consumer chains: custom and contract consumer chains. Informal Systems has written a great article about the tradeoffs between contract and consumer chains.

A custom consumer chain is essentially your typical Cosmos SDK-based chain that has implemented the Interchain Security module and been approved via governance by the provider chain. This could be a brand new chain or a chain that has already been running and wants to disband its validator set to become a consumer chain. A custom consumer chain has all the opportunities of any other Cosmos chain, without the requirement of managing their own independent validator set. To pay for the security provided, the consumer chain must provide a steady stream of rewards (e.g. a portion of its block rewards) to pay the provider chain validators. The amount paid to validators will be established with the proposal that accepts the consumer chain. As more Interchain Security partnerships are established, standards will be set as to how much a consumer chain must pay for security from a particular provider chain.

The need to build an entire chain and negotiate a price for security may not be suited for all builders. Some may want to have the advantages of their own secured blockchain with the ease of writing a smart contract. Conveniently, there will be another way to build a consumer chain that requires much less work on both the consumer and provider side. Contract consumer chains will essentially use a blueprint to create a blockchain via a series of smart contracts. This makes development of the chain much simpler, and also reduces the risk of the provider chain, as a contract consumer chain is essentially a sandboxed appchain that pays its fees with the provider chain’s token. A validator’s decision to support a contract consumer chain comes down simply to economics. “Will the chain be profitable to support?” No need for extensive security audits or concerns around the economics of a separate token. There are so many possibilities that contract consumer chains will open up, and are particularly well suited for gaming and metaverse projects.

So, how does one become a consumer chain? No matter if it's a custom or contract consumer chain, they must be approved via a governance proposal. The consumer chain will need to make the case not only that it is economically viable to support, but also that it aligns with the goals and the vision of the provider chain. While robust and secure code is paramount to a successful blockchain application, the technical implications of a less stable blockchain is not dangerous for the provider chain. Assuming the provider and consumer blockchain software are run on separate machines, there is no way a consumer chain can compromise a provider chain. If a consumer chain experiences network-wide downtime, the provider chain keeps on moving. If malware is distributed through a software release, and provider and consumer chain validator hardware is separated, there is no cross-contamination. The provider chain has no dependency on the consumer chains, and cannot be directly impacted by issues of a consumer chain.

We will see the first public incentivized testnet running interchain security – Game of Chains – towards the end of 2022 and by early 2023, Interchain Security will likely be deployed on the Cosmos Hub mainnet. As of the end of Q3’22, a handful of teams have publicly expressed interest in becoming a Cosmos Hub consumer chain. The first chain to be launched as a consumer chain will likely be Neutron - a DeFi hub supporting CosmWasm smart contracts. The Neutron team is partially funded by the Cosmos Hub’s community pool according to Proposal 72 and is very much committed to becoming the first consumer chain. Two liquid staking projects have expressed interest in becoming a Cosmos Hub consumer chain - Quicksilver and Stride. Another team is Polymer Labs, which is focused on enabling IBC connectivity to all chains through various means, one being zero-knowledge technologies.

At this year's Cosmoverse conference, some stealth projects were announced that plan on becoming Cosmos Hub consumer chains. One of these projects will be a generic asset issuance chain of which Circle is exploring issuing USDC on. This has huge implications for the Cosmos and broader Interchain ecosystems, as it offers any IBC-enabled chain the ability to use a native form of exogenous assets such as USDC. With Interchain Security still a few months out, these projects will likely need to reevaluate the economic and technical feasibility of onboarding as an Interchain Secured zone once the time is near.

While the first major milestone of Interchain Security is around the corner, looking down the future paths that it could take is very exciting. One obvious potential next step would be to make Interchain Security opt-in for validator operators, allowing each to choose which consumer chains they wish to support. This would also open the doors for Proof-of-Authority networks to be secured with Interchain Security. Another option would be to allow chains to pair an independent validator set with provider chain security as a way to enhance their own security. And past that, we could then begin imagining a chain consuming and providing security. A birds-eye view of a network like this would be visualized as a multi-directional mesh of security over the ecosystem, with various subgroups of more strongly secured zones. 

To summarize, Interchain Security is a novel approach to shared security with potential to create a drastically different blockchain security landscape. We at Coinbase Cloud are extremely excited about what this means for the future of the Cosmos ecosystem and are consistently amazed by all those involved. 

I would like to give thanks to the Informal Systems teams, particularly Jelena Djuric & Jehan Tremback​​ for their great insights into the technical details of Interchain Security.