A Cosmos Thesis

On Ethereum, all applications run on a shared state machine. In Cosmos, many application-specific blockchains pass assets and other messages between one another. If Ethereum is a mainframe computer, Cosmos is a protocol for networking independent servers.

The mainframe approach works well while applications remain local to the platform. However, there is a limit to the number of applications each of these blockchains can support, and they are not designed to talk to one another.

Today, congestion on the Ethereum mainchain drives applications to resettle on alternative L1’s and L2’s because they can’t afford to pay Ethereum’s metropolitan premium. Each new L{1,2} needs awkward middleware—“bridges”—to communicate with the others.

Cosmos offers a different vision for an interchain future: one built around interoperability as a first principle. Cosmos believes that giving sovereign chains a shared communication standard is a natural step in the evolution of protocol design. This vision is inclusive, not competitive. Ethereum and other platforms will be able to integrate this interoperability model, too.

What is Cosmos?

Cosmos is not itself a blockchain—it is a blueprint for designing application-specific blockchains, called Zones. A world of many blockchains would not be realistic if each had to implement all of the networking and consensus code from scratch, so Cosmos provides template software to handle those functions, the Cosmos SDK.

Years of work on the SDK has made launching a Zone as easy as deploying a smart contract. However, the approach is not unique to Cosmos: other projects that incorporate the idea of application-specific chains also give developers a “blockchain in a box” (for example, Polkadot’s Substrate framework, which is analogous to Cosmos’s SDK).

Cosmos is unique because it achieves practical interoperability without enshrining a shared security layer. These features are best explained in contrast to Ethereum’s architecture.

Security Models

Ethereum’s security model is uniform. Every application deployed on Ethereum shares the same security level: that of the Ethereum ledger broadly. Because all Ethereum applications exist within a shared runtime, they are tightly coupled and interoperable by default.

Cosmos’s security model, in contrast, is non-uniform. Each Zone (and roughly speaking, each application) must choose the level of security sufficient for its purpose and incentivize a rational market of validators to provide that security. Each Zone exists in its own runtime, so they are not interoperable by default, and communication requires a shared message-passing protocol.

Interoperability

Cosmos deals with the non-uniformity of security assumptions across Zones by treating interoperability as an opt-in market process: Zones, and their users, choose their level of exposure to the security risks of other remote Zones.

Uncoupled Zones will not even pass assets. Fully coupled Zones may each be shards of a single consensus process. The integral of these pairwise relationships over an ecosystem of Zones is an emergent security topology – an interchain.

The Inter-Blockchain Communication (IBC) protocol is a general communication standard devised to enable every necessary flavor of interoperability. IBC can be applied to everything from simple asset transfers, to cross-Zone data availability proofs, to slashing validators on remote Zones (i.e., fully shared security).

Additionally, any blockchain that uses a consensus mechanism with finality can implement IBC and can join the Cosmos Network. For example, ETH2’s Gasper, Polkadot’s GRANDPA, and Libra’s HotStuff are all IBC-compatible. Everything is a Cosmos Zone, by design.

IBC works in production today. The first standardized application, cross-Zone asset transfers, went live last week. This composability model is already sufficient for most DeFi applications; see Vitalik’s argument which covers many notable examples (AMM’s, lending, etc.).

Cosmos’s Pitch

To recap, in Cosmos, every application is encouraged to deploy as a sovereign Cosmos Zone. Cosmos provides the core software substrates needed to develop these blockchains and make them interoperable (the SDK, IBC, etc.). Cosmos treats interoperability as a spectrum and allows every chain on the network to choose how it interacts with the others. Collectively, these relationships form the Interchain.

So, why might you find Cosmos’s model attractive?

Advantages of Sovereign Chains

1. Scalability: networks of application-specific chains are more scalable than chains where everything has to be secured by all validators; even sharded platforms have upper limits. Cosmos Zones scale out “horizontally” through dynamic setpoints on acceptable counterparty safety assumptions.
2. MEV Resistance: a sovereign application-specific chain has access to powerful MEV mitigations and fine-grained control over the incentives it is exposed to.
   • Transaction ordering mechanisms can be tailored to specific use-cases (e.g., the Cosmos Hub’s AMM enforces batching of all trades in a block).
   • Each Cosmos Zone secures only a single application, so they are less likely to accumulate MEV over time than platforms that offer arbitrary programmability. In this sense, Cosmos Zones are closer to Bitcoin than they are to Ethereum.
   • Additionally, Zones get to choose who they interoperate with, so they’re not exposed to the externalized incentives of arbitrary applications as on a shared platform.
   • See “MEV and Me” for a deeper discussion.
3. Developer experience: a Cosmos Zone can optimize its runtime for a specific application, rather than trying to build general-purpose optimizations (e.g., for the EVM). Developers can use whatever languages and tools they want; many already have SDK bindings available.
4. Defensibility: since Zones are responsible for their own security, their tokens and value capture mechanisms are more difficult to fork out, and races-to-the-bottom are less likely.

Disadvantages of Sovereign Chains

1. Security: smart contracts on Ethereum can rely on the platform for protection from safety failures like rollbacks or invalid state transitions. On Cosmos, each chain is responsible for its own security, so applications may fail more often.
   • Counterargument 1: by nature, every Ethereum application either overpays for security or does not contribute its fair share, and all applications share the risk of a catastrophic correlated security failure (MEV’s death-by-a-thousand-cuts). It is healthier for applications that are unable to pay for their own security to fail quickly.
   • Counterargument 2: in practice, many applications on Ethereum (such as Maker and Compound, though not Uniswap) already trust governance tokens for safety. They might as well use them for consensus, too. Scoping governance token permissions is a similar problem to designing application-specific shared-security layers.
   • Counterargument 3: Cosmos will enable a wide variety of shared-security options in the future. IBC can be used to couple the consensus sets of multiple Zones. Zones like LazyLedger will enable sovereign execution environments to share security via rollups (much like the rollup-centric Ethereum design).
2. Synchronous interoperability: while Cosmos chains can transfer assets to each other and interact in other asynchronous ways, it is not possible to make synchronous calls from one Cosmos chain to another.
   • Counterargument: synchronous interaction is still possible within a single Cosmos chain. Synchronous interaction with all other applications is ultimately impossible to maintain at scale. As a result, sharded platforms like Ethereum 2.0 and Polkadot trade synchronous communication for scalability, as do rollups and other layer-2 architectures.
3. Mental overhead: application developers are required to grok arcane details of blockchain protocol design, like MEV.
   • Counterargument: this is probably inevitable. Application developers are not insulated from front-running behavior on Ethereum. They will be forced to consider these dynamics regardless of whether they deploy to a shared platform or their own blockchain, and the latter generally admits more powerful mitigations. Both architectures can abstract some complexity with advanced tooling and middleware.

In Summary

Blockchain protocol design is nebulous. There is no “correct” level of scalability or security. Qualities like credible neutrality cannot be exhaustively defined.

Today, application platforms enshrine static setpoints on those design decisions. Cosmos is the first which allows developers to explore the full trade-off space without giving up simple composability.

Free markets frequently find better solutions to highly multivalent problems than any we could manually enshrine. Cosmos is testing that hypothesis in the context of blockchain application design.

With IBC’s launch, the capital-I Interchain emerges.

Acknowledgments: Arjun Balaji, Dave White, Fiskantes, Fred Ehrsam, Hasu, Georgios Konstantopoulos, Lakshman Sankar, Matt Huang, Zaki Manian