Comprehensive overview of Cosmos

Conversation
1

Hi all - to make sure this excellent piece that Sam Hart wrote for Maker DAO receives proper visibility - LOA Labs validator is republishing it here in the Cosmos Forum. Thank you Sam for everything.

Intro:

Hi everyone, a little on my background. I was previously on the Board of Management at the Interchain Foundation for 3 years where I did product work for the whole Cosmos stack: CometBFT, Cosmos SDK, IBC, CosmWasm, CosmJS, etc. My last project at the ICF was ATOM 2.0, which was heavily inspired by MakerDAO. Prior to Cosmos I worked independently in the Ethereum ecosystem, including some of the earliest research into EIP-1559. Today I’m Head of Product at Skip, a company that works on cross-chain UX and application-specific MEV solutions and I’m a Co-Founder of Timewave that creates tools for DAO-to-DAO agreements.

First off, I want to say I have an immense respect for the Solana architecture, the people who work on the core technology, and their vibrant ecosystem of builders. I would echo this sentiment for Arbitrum, Starkware, and many of the other L2/L3 frameworks that the MakerDAO community will certainly want to consider. What I would like to present here is a summary of what it’s like to build and maintain a Cosmos chain, some of the benefits and challenges.

Sovereign Interoperability:

As Rune has identified, the number one reason to build a Cosmos chain is sovereignty. I find it’s more accurate to describe Cosmos as a design pattern that privileges sovereign interoperability, more so than any specific combination of software. In fact, there are numerous projects that have chosen to use one or more of CometBFT, the CosmosSDK, IBC, CosmWasm in combination with other components that better suit their needs, this is broadly encouraged.

The way Cosmos achieves interoperable sovereignty is by creating a separation of concerns between validators and users, making it as easy as possible for delegators to choose an operator to run nodes on their behalf. The delegator-validator relationship is vital in Cosmos, driving much of validator’s decision-making around network upgrades, governance, and contributions to the community. There is also a belief that it should be as easy as possible for 3rd parties to verify the consensus process themselves, holding validators and the chain itself to account. For this reason CometBFT has best-in-class light client support, with implementations in Go and Rust that are continuously TLA+ model checked against a formally verified consensus spec .

This 3rd party verification process is also essential to maintaining sovereignty within an interoperable environment. Comet is in the BFT consensus family, a partially synchronous design with safety-favoring, instant finality. One block finality is important for application-specific interoperability, where it is assumed that users may want to seamlessly interact with multiple chains within a single workflow. CometBFT is “forkless” meaning there is never ambiguity about the new chain tip as the consensus process advances. This comes at the cost of halting when greater than 1/3 of stake cannot come to agreement, but also allows for fast cross-chain finality and extremely secure cross-chain communication. Chains frequently upgrade via non-contentious hardfork, which improves the app chain development experience (technology can be phased out), at which point all connected chains gracefully receive light client updates and communication is resumed. In the event of a contentious hardfork, for example if a majority of stake comes under the control of a state actor, counterparty chains would need to manually perform a client update (this is one of the motivating reasons for Cosmos chains having in-built governance). Because end-to-end 3rd party verification is the root of sovereign interoperability, the one point of contrast I would draw with Solana is validator accountability requires Solana integrators such as centralized exchanges to run full nodes in order to detect and substantiate coordinated byzantine attacks. This extends to bridges to Solana that must take the form of 3rd party committees.

Because Cosmos started with a mesh-like topology privileging sovereignty, the engineering process has biased heavily toward protocol correctness. Cosmos chains must have the highest-possible level of assurance with their counterparties to safely compose with one another. Rune mentioned the absence of a strong foundation as potentially being both pro and con. He is exactly right. Sovereignty is very much a part of the lived experience in Cosmos. It’s widely understood by developers and users that there is no “inside.” This produces a very unique solidarity economy that draws ambitious builders who want to build something truly novel. It also means that finding help or resources can be a challenge. The ecosystem as a whole pitched in to onboard dYdX, no one person or entity. This is something many of us are very proud of, however there are a lot of moving parts to building a new chain and we had to learn how to onboard them to a very deep stack and ensure their business requirements were met in the process. For instance dYdX needed very specific functionality from CometBFT and USDC, which took longer to deliver than anyone would have liked. I think we’ve improved a lot over the course of the last year but I would encourage you to speak to the dYdX team about their experience.

The Cosmos Stack:

I’ll briefly describe each of these commonly used components, and a bit about their current state:

  • CometBFT (previously Tendermint): Maintained by Informal Systems - Depending on the metric, CometBFT may be the most widely deployed blockchain consensus protocol. It’s battle-tested, simple, extremely well specified, and has fantastic operator tooling for secure key management, observability and monitoring. There are hundreds of extremely high quality operators that run many CometBFT instances with near-perfect uptime. CometBFT was previously maintained by the Interchain Foundation and last year moved under the stewardship of Informal Systems, along with a shuffle of several engineers. CometBFT was previously called “Tendermint,” but renamed recently due to a name collision with Tendermint Inc. who wanted to retain the trademark. CometBFT is very mature software, and though no longer cutting edge, remains remarkably forward-thinking in its design. CometBFT is the industry standard against which other BFT consensus protocols are benchmarked. CometBFT is running in production at sub-second blocktimes on both Injective and Sei, where block production is limited primarily by the Cosmos SDK rather than CometBFT itself. The new Application-Blockchain Interface (ABCI++) is undoubtedly Comet’s most unique feature, which provides hooks for applications to directly interact with every step of the consensus process. This allows for the creation of custom mempools and fee markets, as well as multi-proposer block production, which can be used to create censorship-resistant auctions and in-protocol oracles that require validators to submit and come to consensus on fresh price feeds every block . The most common complaints about Comet typically single out the P2P layer, which is inefficient and tightly coupled with disparate parts of the codebase. This is largely unnoticed by chains that have no need to touch P2P, but is a pain for anyone attempting to innovate on that layer. There are ongoing efforts to refactor but it is a long-term project. Likewise Comet has an opinionated header format which can be a challenge to work around, again for highly custom applications. Addressing this is also on the roadmap but will take time. There are many ideas about how to evolve Comet in the future, including potentially aligning with the heterogenous paxos development effort.

  • Cosmos SDK: Maintained by Binary Builders - The Cosmos SDK is the most mature application-specific blockchain framework, matched only by Substrate. It’s hard to compare the SDK to things like the OP Stack or Arbitrum Orbit, which are very interesting projects, but have nowhere near the level of flexibility or sophistication. We typically say that Cosmos SDK development vs VM development is like programming at the linux kernel level vs. user-space. You do not want to be developing kernel modules unless you have very specific needs, but there are almost no restrictions whatsoever as to what can be done with the Cosmos SDK. Many chain development teams choose to pursue a mix of Cosmos SDK and VM development. They may have a few requirements that necessitate custom resource pricing, access to mempool information, or protocol-enforced work that is expected of validators. The remainder of the business logic might be more easily handled by the VM. Like many parts of the stack the Cosmos SDK has focused heavily on safety. Much of the work over the course of the next year will be directed toward performance improvements, simplifying the developer experience, further UX enhancements, and creating better interfaces for easily experimenting with new cryptography and P2P primitives. For a good example of the uniquely powerful things you can do with the Cosmos SDK I would encourage you to look at the Block SDK we’ve built at Skip which includes credible auctions and programmable blockspace markets. It’s also worth noting there are two rollup frameworks built with the Cosmos SDK, Rollkit from the Celestia team, and the Dymension RDK , which may be worth exploring.

  • IBC: The Go implementation is maintained by the IBC team at the Interchain Foundation, the rust implementation is maintained by Informal Systems — additionally the Go relayer is maintained by Strangelove and the Rust relayer is maintained by Informal Systems - IBC is the standard messaging protocol in Cosmos, which is composed of several layers, transport, authentication, ordering (TAO), and a set of extensible application standards including cross-chain fungible/non-fungible token transfers, remote querying via interchain queries and remote execution via interchain accounts. The TAO layer allows chains to establish connections and structure their messaging via channel and port abstractions. These may be used to send packets of any application type, along with client updates (which today are light clients, but can be trivially replaced with validity clients. Off-chain actors termed “relayers” ferry packets, however they are constrained to stateless transport of authenticated data. IBC is also very mature when compared to other messaging and cross-chain proof verification systems. IBC enables developers to build extremely sophisticated distributed programs, that autonomously execute across untrusted domains. Today the priorities within IBC are largely focused on simplified upgrades, UX/devX improvements such as standard callbacks, expanding light client support (including bilateral light client proving between Ethereum and Comet chains + Ethereum rollups and Comet chains), and maturing the relayer operator market structure. I’m aware of at least three teams building zk Comet light clients that can be proven on Ethereum, Polymer, Electron , and Union . It’s pretty remarkable what people are doing with IBC today, for instance the Cosmos Hub’s interchain security product (analogous to EigenLayer) is built on top of IBC. Challenging areas include the complexity of the protocol itself and a lack of developer tooling. Tools like Interchain Test and Starship are very encouraging but still quite early.

  • VMs - There are several VMs that are widely deployed in Cosmos. I’ll list a few here, however I’m also aware of teams building MoveVM and SVMs as well.

  • CosmWasm: Maintained by Confio - The most widely adopted VM in the ecosystem and much-loved by Cosmos developers. The VM is based on an async actor model, uses the Wasmer interpreter, and provides a rust-native developer experience. CosmWasm is likely the most widely adopted rust-based smart contract framework today, but still has a fairly nascent developer community. Confio put on the first CosmWasm-focused event this year, AwesomeWasm that had a number of great talks.

    • Ethermint : Maintained by Evmos - First EVM module in Cosmos used by Evmos, Crypto.com, and Injective.
    • Polaris : Maintained by Berachain - A newer implementation that is often said to have cleaner EVM abstractions, leveraging custom op_codes for all chain-specific functionality.

  • CosmJS / CosmosKit - Maintained by Confio and Cosmology - Popular javascript client development tooling. Last year Cosmology began collaborating with Confio to improve CosmJS and create a build system in which developers use Cosmos SDK types to autogenerate client libraries and common UI components. This is particularly important for app-specific chain development where base types may differ chain-to-chain. There is very good coverage of the base Cosmos SDK module system in CosmJS and the developer experience is rapidly improving, but developer-friendly documentation is definitely still lacking.

Cosmos’ Challenges:

  • Slightly chaotic at times
  • Developer docs and the dev toolchain is spotty
  • Knowing who to get help from can be challenging, particularly for esoteric questions about low-level technology
  • Coordinated feature/security upgrades in a decentralized ecosystem are intrinsically difficult (we are all very grateful to Amulet for leveling-up the ecosystem in this regard)
  • Not great at marketing ourselves as a wider ecosystem

Cosmos’ Strengths:

  • Great vibes actually (despite what you may hear on twitter) exceptionally bright, engaged, and ideologically invested community
  • Specs are excellent
  • People are incredibly generous with their time, they will go very out of their way to help if they know you need it
  • Technology is second-to-none
  • Literally no single point of failure, at this point the ICF and the Cosmos Hub could probably be obliterated and the ecosystem would keep going
  • Extremely differentiated set of applications that can be easily composed with your own
  • Nascent but incredibly exciting community building next generation privacy infrastructure including Anoma, Penumbra , Nym

Conclusion:

I’m leaving out a ton of important initiatives, but feel free to reply here if anyone wants more info—I’ll be keeping an eye on this forum post. I also invite anyone from the MakerDAO community to reach out to me on Twitter/Telegram at @hxrts if you have any questions whatsoever. Regardless of whether or not MakerDAO chooses to develop with the Cosmos stack, I believe there is a great deal of philosophical alignment between Maker and Cosmos and I hope to interact more with the Maker Community in the future.

Useful Resources:

2 Likes
2

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.