In this article, we will explore how Interchain Security solves the existing bootstrapping bottleneck in the Cosmos ecosystem.
Shared security vs Interchain security
Interchain Security is Cosmos’ version of shared security, but there are some important differences between Interchain Security and the shared security of other blockchain platforms.
On a smart contract platform like Solana or Ethereum, shared security means apps share a single state by deploying as smart contracts. The biggest advantage is that they don't have to worry about bootstrapping a validator set, which is a bottleneck in Cosmos.
Interchain Security is Cosmos' solution to the security bootstrapping issue. Instead of launching a typical Cosmos chain with its own validator set, projects can lease another chain's validators, also called the "provider chain".
Consumer chain economics
The provider chain provides security to the chain that consumes it, also called the "consumer chain". This model allows consumer chains to retain independent fee markets, unlike dApps in smart contract platforms that typically share the same fee market due to finite block space.
However, this model comes with a tradeoff. Provider chain validators need to increase their resources to validate new consumer chains. While this allows for independent fee markets for consumer chains, it does pose tighter requirements on provider chain validators.
Although consumer chains have no upper bound to scaling, in practice, validators may need to invest in more computers to run all these chains in parallel. So they will receive a portion of gas fees and token inflation from the consumer chains for providing this service.
One risk here to the provider chain is centralization of validators: if it becomes prohibitively expensive to validate all the consumer chains, larger operators will start to make up a larger amount of total stake and smaller ones will drop out.
In addition, if consumer chains are unable to generate enough income to attract validators, they may need to increase token inflation to make validation profitable.
In v1, any consumer chain that gets accepted by governance must be secured by all provider chain validators. In v2, individual validators will be able to opt in/out, and validators outside of the provider chain may be able to opt-in as well.
There are two types of consumer chains: contract and custom.
- Contract consumer chain: run smart contract environments (e.g CosmWasm or the EVM). While they are a lot easier for provider chain validators to assess as candidates, they do lose some flexibility.
They must use the provider chain’s token (eg. ATOM) as gas. 25% of fees go to the provider chain and the remaining (~75%) go to a developer DAO, governed by the consumer chain’s own token.
- Custom consumer chain: fully customizable chain developed with the Cosmos SDK. The gas token can be the chain’s own custom token and the chain has a full custom binary, allowing devs to decide things like gas metering and how transactions are assembled in blocks.
However, provider chain validators see these chains as riskier to onboard because with unlimited possibilities there are unlimited attacks. Validators can isolate the risks of these chains by validating them on a separate computer.
Conclusion
After the birth of Interchain Security, the lifecycle of a Cosmos chain could be: Appear as a consumer chain using Cosmos Hub’s ICS service, wait until have a higher market cap, and finally make a transition from a consumer chain to a standard Cosmos chain with own validator set.
Follow Aura Network to update the hot news, insights and knowledge about the entire Cosmos ecosystem!
