One of the features that make blockchain technology so appealing is its high degree of security and resistance to attack. In a Proof-of-Work (PoW) network, blockchains are secured by miners that lend hashing power to the network. The higher the hash rate, the more difficult for a bad actor to carry out an attack. The Bitcoin network is now widely considered large enough to deter would-be attackers, however, smaller chains with lower hash rates are often vulnerable to malicious attacks.
The same is true with Proof-of-Stake (PoS) networks, in which validators (not miners) secure the network by staking cryptocurrency and validating new blocks based on how much of the cryptocurrency they own (their ‘stake’). The more value staked in a network, the more secure the network. For smaller and emerging chains, the relatively low amount of resources to carry out an attack can make their networks vulnerable.
To circumvent this problem, larger chains can share security by lending their cryptocurrency capital to validate blocks on the smaller chain. In the Cosmos network, this shared security is known as Interchain Security.
While existing shared security architectures have opted for top-down designs, Cosmos continues to build from the bottom-up. It’s not that we don’t admire a grand cathedral, we just can’t imagine living anywhere but the Bazaar. Cosmos subscribes to the notion that sovereignty and interoperability are the two key ingredients for building an open ecosystem of blockchains that can scale for mass adoption.
While the Cosmos Hub is not required for an Internet of Blockchains, the purpose of the Cosmos Hub is to make using the Internet of Blockchains better in every way. Not only that the Hub will compete to provide the best service. For a detailed description of how the Cosmos Hub is doing this, take a look at “What Makes the Cosmos Hub a Virtual Port City”.
By allowing anyone to participate in the Internet of Blockchains, Cosmos is like the Bazaar model. There may be fewer guarantees about orderliness or consistency but this design allows for faster and more diverse ideation and development to take place. It’s this difference in design and ideology that has caused an explosion of Cosmos-based blockchains with a diverse set of features and stakeholders.
Interchain Security has been referred to by many different terms: Shared Security, Cross Chain Validation, Cross Chain Collateralization, Shared Staking, and Interchain Staking. For the sake of simplicity, let’s restrict the use to the following three terms:
At a very high level, Interchain Security allows for a provider chain (like the Cosmos Hub), to be in charge of producing blocks for a consumer chain. It does this by sharing the set of validators who are in charge of producing blocks. The participating validators would run two nodes, one for the Cosmos Hub and one for the consumer chain, and receive fees and rewards on both chains.
In order to be eligible to produce blocks on the consumer chain, the validator would use the ATOM tokens they’ve staked on the Cosmos Hub. If the validator does a bad job producing blocks on either chain, they risk having their ATOM tokens destroyed by a mechanism called “slashing”. The consumer chain uses IBC to communicate with the provider chain to keep track of which validators are participating in Interchain Security using Cross Chain Validation. In this way, the security gained from the value of the stake locked on the provider chain is shared with the consumer chain.
There are two primary reasons that Interchain Security is valuable to the Cosmos Hub. The first reason is because it allows for “hub minimalism” and the second is to lower the barrier to launching and running secure sovereign decentralized public blockchains. Let’s take a closer look.
Practical Hub Minimalism is the strategic philosophy that the Cosmos Hub should have as few features as possible in order to decrease the surface area for security vulnerabilities and to reduce the chance of a conflict of interest between user groups. A hub minimalist might be against a name-service module being on the same blockchain as a DEX protocol, for example, since users of the name-service module must now accommodate users of the DEX even when they have different interests. At best, divergent user groups can peacefully coexist and, at worst, differences may result in hard forks that diverge in the features of an application.
The current Cosmos Hub is adding more features, which carries some of the risks that hub minimalism is concerned with. Should Interchain Security become available, it would be possible to satisfy hub minimalists by allowing for each distinct feature of the Cosmos Hub to be an independent chain that is validated by the same set of ATOM-delegated validators. This way, the operation of each function could occur independently without affecting the operation of other ATOM-secured hub-specific applications. These separate consumer chains may even want to have their own token for governance, fees or other application specific uses that could furthermore be used to pay provider chain validators for their services.
The security of a network is often described as a function of the cost of attacking that network. In Tendermint consensus, we target ⅓ and ⅔ of locked stake for various guarantees about liveness and correctness. This means that, in order to do any of a variety of attacks against the network, you would need to acquire ⅓+ or ⅔+ of all staked tokens. The crude way to calculate the cost of an attack is to take the quantity of tokens needed to achieve these proportions and multiply it by the current market price for that token. We’ll call this the Cost of Corruption.
The Cost of Corruption calculation doesn’t account for the availability of any specific token but it does give a very rough estimate for how secure a chain is. It’s important that the total value locked (TVL) on a chain remains less than the Cost of Corruption, otherwise the chain should be considered insecure.
Since the ability of a chain to serve a valuable purpose is often dependent on the TVL it can handle, it’s important to find ways to increase the Cost of Corruption for chains in the Cosmos ecosystem. Take Osmosis for example: at today’s prices (Aug 18, 2021) the market cap of the network is ~$330MM while the TVL is ~$145MM. Theoretically someone could buy ⅔ of the total supply of Osmo for ~$220MM and steal the ~$145MM locked up. Of course this wouldn’t be worth the effort, but should the ratio become more skewed this might in fact be an attractive target for attack.
Interchain Security allows the Cosmos Hub to assign the value of the Cosmos ATOM to the Cost of Corruption for any chain. At today’s price of ATOM (Aug 18, 2021), this would increase the Cost of Corruption by up to ~$3.5 Billion. Eventually this technology could be shared across a number of networks in multiple directions further compounding the total Cost of Corruption for any consumer chain.
Cosmos SDK chains that have already launched mostly already have staking tokens. Similar to Osmosis, these chains may already have a relatively safe ratio between TVL and market cap. Rather than replace their own staking token for the provider’s, they can be combined in what is called Layered Security. Layered Security, or Interchain Security v2, would allow the combination of a local consumer chain staking token with the Cosmos Hub ATOM provider chain staking token to determine the composition of the validator set of the consumer chain. You would have the full weight of the consumer chain market cap with an additional layer of the provider chain’s market cap.
The relationship could be imagined to be extended even further. One day you may have lateral shared security agreements between large networks going both directions. Cosmos Hub may share ATOM value with any of the other Cosmos SDK projects’s validator set and the other way around. At that point it looks more like mutual security insurance across sovereign networks, but let’s not get ahead of ourselves. Interchain Security v1 uses the full validator set of the Cosmos Hub and will be coming to life over the next year.
While the roadmap for Interchain Security is ambitious it points to an even more exciting future. Warp ahead to a future where Interchain Security is prevalent across zones. Assuming these zones meet a threshold of common validators it’s possible to implement a more efficient form of consensus. This is a version of the famous protocol that collapses multiple nodes into a single validator instance. In this collapsed and coordinated multi-chain consensus a fantastic new property becomes possible: synchronous cross chain communication. This cutting edge work has recently been published by members of the Informal team who are heading the research and spec development of this exciting feature.
Development of Interchain Security is currently focused on Cross Chain Validation, the IBC application-level logic required to enable Interchain Security. There is currently a draft of the Cross Chain Validation spec on the Informal Systems GitHub repository that is already being prepared for model-based testing and formal verification. The implementation is taking place within the cross-chain-validation branch of the ibc-go repository. For more details about the rest of the Interchain Security stack, take a look at the Interchain Security light paper.
Interchain Security allows Cosmos to stay true to its philosophy of sovereignty and open source (like the Bazaar model) and enables blockchains to integrate economically but not politically. It’s an ambitious project but development is well underway, with early estimates that this groundbreaking feature could be coming to Cosmos Hub testnets as early as Q4 2021.
Also published here.