If the crypto industry in 2020 is about Defi and how to break down financial systems into interoperable components, we start to see interoperability becoming popular in the fast-growing crypto industry in 2021. How do these interoperable components interact with each other? We have seen the appearance of modular blockchains like Cosmos, Polkadot, ETH2.0 and others.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.Therefore, as we mentioned in our previous article, Cosmos can be understood as 1) the core concept and philosophy, how to build a blockchain in the first place; 2) the technical architecture, the core components that lower the barrier of development. The bottom layer is Tenderment Core, and there is Cosmos SDK on top of it which provides the one-click deployment experience, and IBC is the inter-chain communication protocol which provides inter-chain services  for chains and 3) Cosmos Hub not only funds technical architecture of Cosmos, but is also the home for  the most secure validator set in the ecosystem and is committed to providing better inter-chain services for all sovereign chains on IBC.

If IBC is known as the initial plan towards interoperability across chains, the Interchain Account (ICA) represents the evolution. As we have previously described in our article on the design of different bridges, cross-chain communication can be classified into two types which are based on trust-based interoperability protocol and trust-minimized interoperability protocol. Trust-minimized solution refers to the intra-cluster communication protocol for example, Ethereum and Layer 2 networks implement the protocol by fraud proof and validity proof. IBC communication between Cosmos Zones,, parachains and relaychains on Polkadot are good examplesThe communication between clusters is also known as trust-based inter-cluster communication which requires additional assumptions

IBC can be understood as interoperable protocols for blocks and mainly takes care of reliable transfer, authentications, and data ordering etc. Similar to the TCP/IP protocol, the unique aspect of IBC is that it separates the ‘application layer’ from the ‘transport and network layer’ (or TAO, transport, authorization, organization). The transport layer (or ‘TAO’ for transport, authentication, ordering, people normally referred for interoperable protocols)  provides the necessary infrastructure to establish secure connections and authenticate data packets between chains. The  application layer instead defines exactly how these data packets should be packaged and interpreted by the sending and receiving chains.This means that IBC defines how data is sent and acknowledged across blockchains, but it doesn’t define what that data is or how it should be structured. This sets IBC apart from other interoperability solutions which require a lot more standardization in the application layer. Adding additional requirements for standardization can add a layer of politics which decreases the diversity of blockchain architecture that can exist in the interoperable network.

IBC is designed in such a way that the channel can be understood as the information channel forIBC module (which can be interpreted as an Internet application),to communicate over through standardized data packets using IBC standards. For example, if you transfer $Atom from Cosmos Hub to Osmosis, you need to use a specific channel between two zones. And the communication from Osmosis to Cosmos Hub is another channel. Theoretically, there can be infinite channels between two chains. For one Zone, you can also have millions of channels, however, practically, it will be limited by the infrastructure overhead and other factors.A relayers facilitates the data transport between zones and monitos the state of outgoing packets and submits them to the appropriate destination chain. The whole process will involve three times of handshakes, similar to the TCP/IP.

ICS-20 (ICS stands for Interchain Standard) token transfer module is the first module in the IBC that allows zones to interact with each other. Again, the module can be thought of as the internet app, however, the internet app/module is restricted to just token transfers but there are other modules. What can we do once the assets have been transferred? We need the inter-chain account module (ICS27)to answer that. Before introducing inter-chain accounts, we need to emphasize why not create new application standard instead? The new application standard require considerable time, research and resources, and the well-designed standards will take the long view of the ecosystem. For example, if there would be a new IBC standard for liquidity pool related functionality, then each sender and receiver chain would be able to correctly parse the packets being passed through the relevant IBC transport layers to their corresponding message types, and perform the transaction execution accordingly. For example, with this new standard, we can move the LP pair of Atom/USDC of Osmosis to the Atom/USDC on the Crescent Network with one click. Hence, considering the

rapid growth of Cosmos ecosystem over the past few years, we should consider more viable short-term solutions at the current stage, in order to boost the IBC traction for early adoption. When there are hundreds of applications and features in the Cosmos ecosystem, building such standards would bring redundant implementation and standardization for new feature/application deployments. Also, It creates a significant t development overhead for developers/ICS teams while the quality of the standards could not be guaranteed. Therefore, we decided to go with a stepping stone solution of inter-chain accounts..

An inter-chain account transaction is a non-IBC transaction of the target blockchain packaged inside an IBC package which contains instructions on what task should be submitted to the receiving blockchain (such as token swap, staking, collateral lending etc).tYou may interpret it as a letter inside an envelope of thea box The sender (Zone) sent the box to the receiver (Zone) via a relayer. The receiver's IBC module opens the box and relays the envelope to the destination which is the receiver's interchain account module. The interchain account module opens the envelope and submits the specified task to the chain. The execution of the transaction will depend entirely on the internal logic of the receiver, while the interchain account module is only responsible for relaying the encrypted transaction which is the letter. The letter itself will be a receiver's standard, which is not related to the transaction type itself.

So interchain accounts allow control of an account on one chain on  another chain, while assets are moved via interchain accounts, the user do not need to operate in multiple product interfaces back and forth. The above diagram compares an IBC interchain account transaction with a typical IBC application transaction. In the IBC application transactions, the process of handling transaction date from sender chain and receiver chain’s modules have to be defined.(e.g. Module A can be an ICS staking module, Module B can be an ICS governance module, and Module C can be an ICS CDP collateralized debt position module). In the case of IBC interchain account transactions, only the process of relaying transactions from one blockchain to the interchain account on the target blockchain needs to be defined while the transaction itself is handled by the target blockchain’s internal logic, and not by IBC module.

For example we can send Atom from Cosmos Hub to Osmosis. After Atom is sent to the Osmosis network, we can stake Atom to Cosmos Hub validators  directly in the Osmosis network/interface through the Osmosis interchain account function. We do not need to transfer assets back to Cosmos Hub and then stake the nodes via the Cosmos Hub interface. You may further use the staked position for collateral and investment purposes, such as opening the collateral on Umee, or investing in the liquid staking protocol.etc. More importantly, you do not have to leave Osmosis' interface during the process, which greatly improves the user experience. Also, interchain governance is a good topic to explore.

This provides a far more scalable solution in the short-term for fast-changing blockchain ecosystems like Cosmos, where potential architectural changes in the target blockchain can be frequent and new features can be added to the blockchain. As long as interchain accounts are implemented, new features on the blockchain can be immediately supported as IBC transactions.

This allows interchain accounts to act as a stepping stone for early stages of application interoperability for projects to test what type of integrations are possible before committing resources to create a standardized IBC application implementation.

Inter-chain accounts provides a scalable and interoperable solution in the short term for fast-changing blockchain ecosystems like Cosmos where thepotential architectural changes in the destination chain can be very flexible and frequent. New features can be quickly deployed and accessed. Through IBC's inter-chain account module, the new features on the blockchain can be immediately supported as IBC transactions.  quickly support transactions on IBC. This allows interchain accounts to act as a stepping stone for early stages of application interoperability for projects to test what type of integrations are possible before committing resources to create a standardized IBC application implementation.

. For example, the Sommelier protocol is an interchain liquidity provider built on Ethereum and Cosmos. Sommelier access the Tendermint chain via IBC and EVM-compatible chains such as Ethereum via Gravity Bridge. Cellars can be understood as the series of smart contracts  for specific Defi strategy, similar to a dynamic vault. Before the inte-rchain accounts go live, each IBC chain that deploys Cellar needs to deploy the Sommelier Cellars module. It requires a full chain upgrade for each chain, and when the module is updated, it needs to be updated accordingly. When more and more chains deploy Cellar, it will bring a lot of communication and implementation costs, which greatly limits the scalability, interoperability and efficiency of Cellar module deployment. With the launch of interchain accounts, Sommelier’s cellars can send messages back and forth the original/destination chain. The messages can execute a number of actions as defined by Cellar’s strategy such as rebalancing, reinvesting, lending and others. . For example, a Celler strategy to optimize the LP strategy of AMM on Osmosis, or a stablecoin lending strategy on Umee, can be communicated and updated with other parties in the form of IBC messages. This significantly reduces the complexity of the IBC interoperability and increases the number of the chains the Sommelier can support.

Currently existing interchain security solutions have adopted a top-down architecture while Cosmos instead uses the bottom-up approach. Unlike Ethereum 2.0 and Polkadot, Cosmos wants to build a more solid foundation on which this functionality can be built. For example, after the IBC communication protocol standard is used/adopted, Cosmos can begin to build a sharding solution on it.

Of course, the interchain security is a shared security model similar to Polkadot, which allows validators on one blockchain to produce blocks and maintain security for another chain. . In Polkadot's shared  security model, the security of all parachains depends on the security of the relay chain. However, it limits the number of slots and tradestrade synchronous communication for scalability, as do rollups and other layer-2 architectures In the L1, a global world computer vision such as Ethereum, the limit for block size and gas fee becomes the bottleneck for its scalability. All Dapps built on it will compete for the priority of producing blocks in the network and hence allthe transaction behaviors are withina single sequence (you can understand it as a congested highway). On-chain contracts interact by competing for block space, which will trigger many contracts among different applications to compete for block space. The network congestion will lead to the high gas fee and inefficient resource pricing problems.Their community has recently proposed a Dank Sharding solution for scalability. It is essentially a large engineering adjustment which will take years.. Cosmos, on the other hand, provides the flexibility by allowing Zones to have their own validators, values  and assets, and determining the security of their own network. It consists of multiple chains with multiple sets of nodes, enabling horizontal interoperability and scalability but with no competition required between chains. For example, Cosmos Hub and consumer chains are not in the competitive position but rather an aligned value to bootstrap the ecosystem. . For some AMM application sovereign chains like Osmosis, which already has a relatively secure set of validation nodes, a significant TVL (total value locked) and a high market value, there is no needs to fully rely on the security of Cosmos Hub (Full interchain security, V1). But there will be some needs for shared security later on. However, for most of the long-tail projects/early-stage startups , they don't have access to professional validators who can secure the network, and this will likely impose significant risks and limits for their early development. .With the launch of ICS, there are two points that need to be mentioned.Firstly, ICS itself is an opt- in module for all applications built on Cosmos, rather than  a mandatory one. Secondly, once the application decides to implement it, the consumer chain can choose the same validators as that of the Cosmos Hub(note that Opt in does not mean mandatory, but in v1, it is mandatory for 175 validation sets to validate blocks.There will be more flexibility provided in v2 and v3).  If it is developed further through Cosmwasm, it will be more scalable thanks to this specialized, multiple smart contract platform. Note for v1, the consumer chain distributes 75% of the gas fee to the treasury DAO managed by multi-signature wallet while the remaining of 25% will be used to incentivise the Cosmos Hub and Atom stakers.

Interchain security allows the provider chain (Cosmos Hub) to produce blocks for the consumer chain by sharing the set of validators. Participating validators need to run nodes from both sides (provider  chain and consumer chain) and receive fees and rewards from both sides. Validators need to use their staked ATOM tokens on Cosmos Hub to validate the blocks for the consumer chain. If a validator does a bad job producing blocks on either chain, they risk having their ATOM tokens destroyed by a mechanism called slashing. There will be a three versions of ICS. The first one is that the security of the consumer chain is maintained entirely by the Cosmos Hub nodes. And whether these consumer chains can be approved by the governance proposal of Cosmos Hub will vary on their risk profile (a CosmWasm contract chain vs a custom chain w/ changes at the SDK). . Therefore, Atom stakers need to consider the risk for the validators as they are exposed to the downtime and misbehavior risks for the consumer chain just as other POS chains while given the additional incentives. In the first version, all 175 validators of the Cosmos Hub must validate the consumer chains. In this case, values of all  staked Atom as well as the numbers of of validators on Cosmos Hub that are securing the consumer ensures that the consumer chain have the same security guarantees as the Cosmos Hub. f  The slashing risk here is what ensures the consumer chains inherit the security of the Cosmos Hub. Hence, the value of the $ATOM stake of the participating ICS validators and the slashing risk of those validators ensure that the Cosmos Hub validators do not act malicious towards the consumer chain and offer the same security guarantee. To sum up, In the first version, the network  ICS depends on the security of Cosmos Hub. (See the following chart for the differences between Consumer Contract Chain, Smart Contract Platform, Independent  BlockChain, Custom Consumer Chain etc).

In the second version, it will 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. And in version V3, this relationship can be further extended to enable lateral shared security agreements between large networks going both directions, where Cosmos Hub can share Atom values with any of the other Cosmos SDK project;s validator sets and the other way around. This can be understood as mutual security insurance across sovereign networks.Also notice in version V3, the Cosmos Hub validators have the right to stop verifying a chain.

Compared with V1 of full security, network security will be jointly determined by validators sets of both consumer chain and provider chain,in V2 and V3 and hence for some participating validators of Cosmos Hub, there will be the possibility of Sybil attack if the only validator on the consumers act maliciously.

The governance of interchain security will mainly follow two processes, public governance and private governance. Public governance is similar to the public discussion before a democratic election. It is an advertising activity by soliciting opinions, feedback from the public and finally deciding whether to officially proceed with the proposals. Most projects on Cosmos are governed through this way, such as Osmosis and Juno Network. Opinion is collected via theCommonwealth (Similar product to Forum). In addition, there is a private internal governance approach. ICS discusses with projects or validators regarding issues such as, when to launch consumer chains. We would like to mention here that Solana is a protocol that highly relies on private governance rather than solicit the public's opinion. The future development of the chain is decided by a few centralized nodes, which is why the community always criticizes that the chain is not decentralized enough.

As mentioned above, when the consumer chain is launched, it needs to be governed on-chain through a permissioned list. You need to know where to launch these chains (code base in Engineering design base related to the engineering, etc.), when to launch, and the potential development environment. Essentially, it will go through different steps such as development, testing, deployment, alpha testing, launch, beta testing, etc. The projects that will be implemented  include Quicksilver, a liquidity staking protocol, and Crescent Network, etc. They will be the first projects to use ICS. Note that Quicksilver intends to use ICS when it is made available, but will be launching without it. They have to have the same validators; they are secured by the atom value, so both chains have the full security of the hub. During the early phrase, nodes need to start the consumer chain manually in a governance-gated way. The second version will provide more options for validators and consumer chains. For most chains developed on Cosmos SDK, they have their own staked tokens, such as Osmosis. Its TVL and market cap have reached a secure ratio. (The security of the network is determined by TVL and the Cost of Corruption. When the total value locked (TVL) is lessr than the Cost of Corruption, the network is considered secure; Cost of Corruption Is to take the quantity of tokens needed to achieve the proportions and multiply by the current market price for the token. depends on the product between the number of tokens and value of the tokens, related to the proportion of attacked nodes (it’s 2/3in the Tendermint mechanism)

Let us take Osmosis as an example, as of June 4, 2022, its market value is $1.2 billion, and its TVL is $230 million. Theoretically, for those who want to attack, they need to get 2/3 of the Osmo tokens, which is about $800 million, to steal $230 million of TVL assets. So this attack is unprofitable, so the network is relatively safe.:We will be excited for v2/v3 cause it will allow chains like Osmosis or Axelar to borrow specific amounts of security as opposed to the full security of the Hub (rendering their native staking tokens as just governance tokens). This will be especially important as the TVL on Osmosis increases and as Axelar gains in popularity to increase its security.

The beautiful trio, all working together to ensure shared security across the interchain:

Interchain Security = shared security from the Cosmos Hub (full and partial security) < 1 year

Interfluid Staking = shared security from Osmosis liquidity pools (partial security) ~ 1 year

Celestia = shared security for EVM rollups (full security for optimistic rollups)  < 1 year

So we have seen two main advantages of ICS. One is lowering the barrier of development. It will become easier to deploy. The other is security. We have seen liquidity staking protocols such as  Quicksilver and Lidowhich require high security s are ready to launch through interchain security. Meanwhile, Rocket Pool, a derivative staking platform on Ethereum, also has plans to access IBC through a consumer chain. Although launching a consumer chain  requires governance, you will be able to exit any time and can switch to other chains or your own sovereign blockchains. For example, when the Quicksilver protocol becomes big enough and it can always switch to the sovereign chains via binary at any time and continues its vision for the sovereign blockchains with a more solid community.  So to sum up,, we can understand the ICS as a leverage tool used by the early-staged project to access the Cosmos ecosystem. Through the participating from the most secure nodes, the backing from Cosmos Hub(through approved governance, etc.)and of course the security technology and financial leverage supports it, it will eventually develop and grow into a solid sovereign app-chain.. We strongly believe that the future era of multi-chain blockchain will be dominated by these application sovereign chains.

Welcome to the IBC gang, let’s talk

Interchain Security is Coming to the Cosmos Hub

Nansen-alpha

Building with Interchain Security

If the crypto industry in 2020 is about Defi and how to break down financial systems into interoperable components, we start to see interoperability becoming popular in the fast-growing crypto industry in 2021. How do these interoperable components interact with each other? We have seen the appearance of modular blockchains like Cosmos, Polkadot, ETH2.0 and others.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.Therefore, as we mentioned in our previous article, Cosmos can be understood as 1) the core concept and philosophy, how to build a blockchain in the first place; 2) the technical architecture, the core components that lower the barrier of development. The bottom layer is Tenderment Core, and there is Cosmos SDK on top of it which provides the one-click deployment experience, and IBC is the inter-chain communication protocol which provides inter-chain services  for chains and 3) Cosmos Hub not only funds technical architecture of Cosmos, but is also the home for  the most secure validator set in the ecosystem and is committed to providing better inter-chain services for all sovereign chains on IBC.

If IBC is known as the initial plan towards interoperability across chains, the Interchain Account (ICA) represents the evolution. As we have previously described in our article on the design of different bridges, cross-chain communication can be classified into two types which are based on trust-based interoperability protocol and trust-minimized interoperability protocol. Trust-minimized solution refers to the intra-cluster communication protocol for example, Ethereum and Layer 2 networks implement the protocol by fraud proof and validity proof. IBC communication between Cosmos Zones,, parachains and relaychains on Polkadot are good examplesThe communication between clusters is also known as trust-based inter-cluster communication which requires additional assumptions

IBC can be understood as interoperable protocols for blocks and mainly takes care of reliable transfer, authentications, and data ordering etc. Similar to the TCP/IP protocol, the unique aspect of IBC is that it separates the ‘application layer’ from the ‘transport and network layer’ (or TAO, transport, authorization, organization). The transport layer (or ‘TAO’ for transport, authentication, ordering, people normally referred for interoperable protocols)  provides the necessary infrastructure to establish secure connections and authenticate data packets between chains. The  application layer instead defines exactly how these data packets should be packaged and interpreted by the sending and receiving chains.This means that IBC defines how data is sent and acknowledged across blockchains, but it doesn’t define what that data is or how it should be structured. This sets IBC apart from other interoperability solutions which require a lot more standardization in the application layer. Adding additional requirements for standardization can add a layer of politics which decreases the diversity of blockchain architecture that can exist in the interoperable network.

IBC is designed in such a way that the channel can be understood as the information channel forIBC module (which can be interpreted as an Internet application),to communicate over through standardized data packets using IBC standards. For example, if you transfer $Atom from Cosmos Hub to Osmosis, you need to use a specific channel between two zones. And the communication from Osmosis to Cosmos Hub is another channel. Theoretically, there can be infinite channels between two chains. For one Zone, you can also have millions of channels, however, practically, it will be limited by the infrastructure overhead and other factors.A relayers facilitates the data transport between zones and monitos the state of outgoing packets and submits them to the appropriate destination chain. The whole process will involve three times of handshakes, similar to the TCP/IP.

ICS-20 (ICS stands for Interchain Standard) token transfer module is the first module in the IBC that allows zones to interact with each other. Again, the module can be thought of as the internet app, however, the internet app/module is restricted to just token transfers but there are other modules. What can we do once the assets have been transferred? We need the inter-chain account module (ICS27)to answer that. Before introducing inter-chain accounts, we need to emphasize why not create new application standard instead? The new application standard require considerable time, research and resources, and the well-designed standards will take the long view of the ecosystem. For example, if there would be a new IBC standard for liquidity pool related functionality, then each sender and receiver chain would be able to correctly parse the packets being passed through the relevant IBC transport layers to their corresponding message types, and perform the transaction execution accordingly. For example, with this new standard, we can move the LP pair of Atom/USDC of Osmosis to the Atom/USDC on the Crescent Network with one click. Hence, considering the

rapid growth of Cosmos ecosystem over the past few years, we should consider more viable short-term solutions at the current stage, in order to boost the IBC traction for early adoption. When there are hundreds of applications and features in the Cosmos ecosystem, building such standards would bring redundant implementation and standardization for new feature/application deployments. Also, It creates a significant t development overhead for developers/ICS teams while the quality of the standards could not be guaranteed. Therefore, we decided to go with a stepping stone solution of inter-chain accounts..

An inter-chain account transaction is a non-IBC transaction of the target blockchain packaged inside an IBC package which contains instructions on what task should be submitted to the receiving blockchain (such as token swap, staking, collateral lending etc).tYou may interpret it as a letter inside an envelope of thea box The sender (Zone) sent the box to the receiver (Zone) via a relayer. The receiver's IBC module opens the box and relays the envelope to the destination which is the receiver's interchain account module. The interchain account module opens the envelope and submits the specified task to the chain. The execution of the transaction will depend entirely on the internal logic of the receiver, while the interchain account module is only responsible for relaying the encrypted transaction which is the letter. The letter itself will be a receiver's standard, which is not related to the transaction type itself.

So interchain accounts allow control of an account on one chain on  another chain, while assets are moved via interchain accounts, the user do not need to operate in multiple product interfaces back and forth. The above diagram compares an IBC interchain account transaction with a typical IBC application transaction. In the IBC application transactions, the process of handling transaction date from sender chain and receiver chain’s modules have to be defined.(e.g. Module A can be an ICS staking module, Module B can be an ICS governance module, and Module C can be an ICS CDP collateralized debt position module). In the case of IBC interchain account transactions, only the process of relaying transactions from one blockchain to the interchain account on the target blockchain needs to be defined while the transaction itself is handled by the target blockchain’s internal logic, and not by IBC module.

For example we can send Atom from Cosmos Hub to Osmosis. After Atom is sent to the Osmosis network, we can stake Atom to Cosmos Hub validators  directly in the Osmosis network/interface through the Osmosis interchain account function. We do not need to transfer assets back to Cosmos Hub and then stake the nodes via the Cosmos Hub interface. You may further use the staked position for collateral and investment purposes, such as opening the collateral on Umee, or investing in the liquid staking protocol.etc. More importantly, you do not have to leave Osmosis' interface during the process, which greatly improves the user experience. Also, interchain governance is a good topic to explore.

This provides a far more scalable solution in the short-term for fast-changing blockchain ecosystems like Cosmos, where potential architectural changes in the target blockchain can be frequent and new features can be added to the blockchain. As long as interchain accounts are implemented, new features on the blockchain can be immediately supported as IBC transactions.

This allows interchain accounts to act as a stepping stone for early stages of application interoperability for projects to test what type of integrations are possible before committing resources to create a standardized IBC application implementation.

Inter-chain accounts provides a scalable and interoperable solution in the short term for fast-changing blockchain ecosystems like Cosmos where thepotential architectural changes in the destination chain can be very flexible and frequent. New features can be quickly deployed and accessed. Through IBC's inter-chain account module, the new features on the blockchain can be immediately supported as IBC transactions.  quickly support transactions on IBC. This allows interchain accounts to act as a stepping stone for early stages of application interoperability for projects to test what type of integrations are possible before committing resources to create a standardized IBC application implementation.

. For example, the Sommelier protocol is an interchain liquidity provider built on Ethereum and Cosmos. Sommelier access the Tendermint chain via IBC and EVM-compatible chains such as Ethereum via Gravity Bridge. Cellars can be understood as the series of smart contracts  for specific Defi strategy, similar to a dynamic vault. Before the inte-rchain accounts go live, each IBC chain that deploys Cellar needs to deploy the Sommelier Cellars module. It requires a full chain upgrade for each chain, and when the module is updated, it needs to be updated accordingly. When more and more chains deploy Cellar, it will bring a lot of communication and implementation costs, which greatly limits the scalability, interoperability and efficiency of Cellar module deployment. With the launch of interchain accounts, Sommelier’s cellars can send messages back and forth the original/destination chain. The messages can execute a number of actions as defined by Cellar’s strategy such as rebalancing, reinvesting, lending and others. . For example, a Celler strategy to optimize the LP strategy of AMM on Osmosis, or a stablecoin lending strategy on Umee, can be communicated and updated with other parties in the form of IBC messages. This significantly reduces the complexity of the IBC interoperability and increases the number of the chains the Sommelier can support.

Currently existing interchain security solutions have adopted a top-down architecture while Cosmos instead uses the bottom-up approach. Unlike Ethereum 2.0 and Polkadot, Cosmos wants to build a more solid foundation on which this functionality can be built. For example, after the IBC communication protocol standard is used/adopted, Cosmos can begin to build a sharding solution on it.

Of course, the interchain security is a shared security model similar to Polkadot, which allows validators on one blockchain to produce blocks and maintain security for another chain. . In Polkadot's shared  security model, the security of all parachains depends on the security of the relay chain. However, it limits the number of slots and tradestrade synchronous communication for scalability, as do rollups and other layer-2 architectures In the L1, a global world computer vision such as Ethereum, the limit for block size and gas fee becomes the bottleneck for its scalability. All Dapps built on it will compete for the priority of producing blocks in the network and hence allthe transaction behaviors are withina single sequence (you can understand it as a congested highway). On-chain contracts interact by competing for block space, which will trigger many contracts among different applications to compete for block space. The network congestion will lead to the high gas fee and inefficient resource pricing problems.Their community has recently proposed a Dank Sharding solution for scalability. It is essentially a large engineering adjustment which will take years.. Cosmos, on the other hand, provides the flexibility by allowing Zones to have their own validators, values  and assets, and determining the security of their own network. It consists of multiple chains with multiple sets of nodes, enabling horizontal interoperability and scalability but with no competition required between chains. For example, Cosmos Hub and consumer chains are not in the competitive position but rather an aligned value to bootstrap the ecosystem. . For some AMM application sovereign chains like Osmosis, which already has a relatively secure set of validation nodes, a significant TVL (total value locked) and a high market value, there is no needs to fully rely on the security of Cosmos Hub (Full interchain security, V1). But there will be some needs for shared security later on. However, for most of the long-tail projects/early-stage startups , they don't have access to professional validators who can secure the network, and this will likely impose significant risks and limits for their early development. .With the launch of ICS, there are two points that need to be mentioned.Firstly, ICS itself is an opt- in module for all applications built on Cosmos, rather than  a mandatory one. Secondly, once the application decides to implement it, the consumer chain can choose the same validators as that of the Cosmos Hub(note that Opt in does not mean mandatory, but in v1, it is mandatory for 175 validation sets to validate blocks.There will be more flexibility provided in v2 and v3).  If it is developed further through Cosmwasm, it will be more scalable thanks to this specialized, multiple smart contract platform. Note for v1, the consumer chain distributes 75% of the gas fee to the treasury DAO managed by multi-signature wallet while the remaining of 25% will be used to incentivise the Cosmos Hub and Atom stakers.

Interchain security allows the provider chain (Cosmos Hub) to produce blocks for the consumer chain by sharing the set of validators. Participating validators need to run nodes from both sides (provider  chain and consumer chain) and receive fees and rewards from both sides. Validators need to use their staked ATOM tokens on Cosmos Hub to validate the blocks for the consumer chain. If a validator does a bad job producing blocks on either chain, they risk having their ATOM tokens destroyed by a mechanism called slashing. There will be a three versions of ICS. The first one is that the security of the consumer chain is maintained entirely by the Cosmos Hub nodes. And whether these consumer chains can be approved by the governance proposal of Cosmos Hub will vary on their risk profile (a CosmWasm contract chain vs a custom chain w/ changes at the SDK). . Therefore, Atom stakers need to consider the risk for the validators as they are exposed to the downtime and misbehavior risks for the consumer chain just as other POS chains while given the additional incentives. In the first version, all 175 validators of the Cosmos Hub must validate the consumer chains. In this case, values of all  staked Atom as well as the numbers of of validators on Cosmos Hub that are securing the consumer ensures that the consumer chain have the same security guarantees as the Cosmos Hub. f  The slashing risk here is what ensures the consumer chains inherit the security of the Cosmos Hub. Hence, the value of the $ATOM stake of the participating ICS validators and the slashing risk of those validators ensure that the Cosmos Hub validators do not act malicious towards the consumer chain and offer the same security guarantee. To sum up, In the first version, the network  ICS depends on the security of Cosmos Hub. (See the following chart for the differences between Consumer Contract Chain, Smart Contract Platform, Independent  BlockChain, Custom Consumer Chain etc).

In the second version, it will 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. And in version V3, this relationship can be further extended to enable lateral shared security agreements between large networks going both directions, where Cosmos Hub can share Atom values with any of the other Cosmos SDK project;s validator sets and the other way around. This can be understood as mutual security insurance across sovereign networks.Also notice in version V3, the Cosmos Hub validators have the right to stop verifying a chain.

Compared with V1 of full security, network security will be jointly determined by validators sets of both consumer chain and provider chain,in V2 and V3 and hence for some participating validators of Cosmos Hub, there will be the possibility of Sybil attack if the only validator on the consumers act maliciously.

The governance of interchain security will mainly follow two processes, public governance and private governance. Public governance is similar to the public discussion before a democratic election. It is an advertising activity by soliciting opinions, feedback from the public and finally deciding whether to officially proceed with the proposals. Most projects on Cosmos are governed through this way, such as Osmosis and Juno Network. Opinion is collected via theCommonwealth (Similar product to Forum). In addition, there is a private internal governance approach. ICS discusses with projects or validators regarding issues such as, when to launch consumer chains. We would like to mention here that Solana is a protocol that highly relies on private governance rather than solicit the public's opinion. The future development of the chain is decided by a few centralized nodes, which is why the community always criticizes that the chain is not decentralized enough.

As mentioned above, when the consumer chain is launched, it needs to be governed on-chain through a permissioned list. You need to know where to launch these chains (code base in Engineering design base related to the engineering, etc.), when to launch, and the potential development environment. Essentially, it will go through different steps such as development, testing, deployment, alpha testing, launch, beta testing, etc. The projects that will be implemented  include Quicksilver, a liquidity staking protocol, and Crescent Network, etc. They will be the first projects to use ICS. Note that Quicksilver intends to use ICS when it is made available, but will be launching without it. They have to have the same validators; they are secured by the atom value, so both chains have the full security of the hub. During the early phrase, nodes need to start the consumer chain manually in a governance-gated way. The second version will provide more options for validators and consumer chains. For most chains developed on Cosmos SDK, they have their own staked tokens, such as Osmosis. Its TVL and market cap have reached a secure ratio. (The security of the network is determined by TVL and the Cost of Corruption. When the total value locked (TVL) is lessr than the Cost of Corruption, the network is considered secure; Cost of Corruption Is to take the quantity of tokens needed to achieve the proportions and multiply by the current market price for the token. depends on the product between the number of tokens and value of the tokens, related to the proportion of attacked nodes (it’s 2/3in the Tendermint mechanism)

Let us take Osmosis as an example, as of June 4, 2022, its market value is $1.2 billion, and its TVL is $230 million. Theoretically, for those who want to attack, they need to get 2/3 of the Osmo tokens, which is about $800 million, to steal $230 million of TVL assets. So this attack is unprofitable, so the network is relatively safe.:We will be excited for v2/v3 cause it will allow chains like Osmosis or Axelar to borrow specific amounts of security as opposed to the full security of the Hub (rendering their native staking tokens as just governance tokens). This will be especially important as the TVL on Osmosis increases and as Axelar gains in popularity to increase its security.

The beautiful trio, all working together to ensure shared security across the interchain:

Interchain Security = shared security from the Cosmos Hub (full and partial security) < 1 year

Interfluid Staking = shared security from Osmosis liquidity pools (partial security) ~ 1 year

Celestia = shared security for EVM rollups (full security for optimistic rollups)  < 1 year

So we have seen two main advantages of ICS. One is lowering the barrier of development. It will become easier to deploy. The other is security. We have seen liquidity staking protocols such as  Quicksilver and Lidowhich require high security s are ready to launch through interchain security. Meanwhile, Rocket Pool, a derivative staking platform on Ethereum, also has plans to access IBC through a consumer chain. Although launching a consumer chain  requires governance, you will be able to exit any time and can switch to other chains or your own sovereign blockchains. For example, when the Quicksilver protocol becomes big enough and it can always switch to the sovereign chains via binary at any time and continues its vision for the sovereign blockchains with a more solid community.  So to sum up,, we can understand the ICS as a leverage tool used by the early-staged project to access the Cosmos ecosystem. Through the participating from the most secure nodes, the backing from Cosmos Hub(through approved governance, etc.)and of course the security technology and financial leverage supports it, it will eventually develop and grow into a solid sovereign app-chain.. We strongly believe that the future era of multi-chain blockchain will be dominated by these application sovereign chains.

Welcome to the IBC gang, let’s talk

Interchain Security is Coming to the Cosmos Hub

Nansen-alpha

Building with Interchain Security