#281 Ethan Buchman & Sunny Aggarwal: Cosmos – Launching the Internet of Blockchains (sample)


Table of contents

The Cosmos Network and its vision

The vision of Cosmos is similar to the internet in that during the early days of the internet, there were already a large number of small networks; the Internet was merely proposing a way to connect them all through a common set of protocols such as TCP/IP. Likewise, the goal of Cosmos is to be “interchain”, enabling communication and transfer of cryptoassets across siloed chains. Apart from interoperability between existing blockchains, the goal of Cosmos is also to define more modern and mature approaches to building the individual chains themselves.

That’s where Tendermint Core comes in. As a general-purpose consensus engine, it can function as a consensus algorithm for any blockchain network and acts to ensure that the same transactions are recorded in every node in the same order. The Application Blockchain Interface (ABCI), which is also part of Tendermint, enables transactions to be wrapped in any programming language. Another vital piece is the Cosmos SDK, which offers developers a set of tools and a framework for building applications on Tendermint. Lastly, we have the Inter-blockchain Communication Protocol (IBC), a vital interoperability piece that enables blockchains, hubs, and zones to communicate with one another.

:arrow_up: Table of contents

Cosmos in the context of blockchain evolution

In the first generation, there were a few dominant players such as Bitcoin, Namecoin, and Sia, which are separate, independent blockchains focused on maintaining a shared public ledger and transferring value. Ethereum, the most notable second-generation blockchain, pushed beyond the boundaries of merely carrying out simple transactions. It incorporated smart contracts, self-executing contracts stored on the blockchain that automatically execute when certain parameters are met. This, in turn, enabled Ethereum to create an ecosystem where different decentralized applications (dApps) can talk to one another. Ethereum also made it very easy for developers to write their own applications, thanks to Solidity, a programming language similar to ECMAScript (JavaScript). Whereas in first-generation blockchains, if a developer wanted to create their own blockchain, they didn’t have a general-purpose language to turn to; they would need to fork the Bitcoin code base. This was because the consensus is tied to the state machine, which in turn is connected to P2P.

Cosmos sees itself working closely with third-generation blockchains, which aim to solve issues related to [near infinite] scalability, near instant transactions, as well as governance. such as Cardano.

:arrow_up: Table of contents

How Cosmos has evolved since the white paper was originally published

The high-level vision is still very much the same; [we] still want existing blockchains to have independent state machines that are defined according to the needs of their users and stakeholders. We also want them to be relatively sovereign so that they are governed by users and interoperable such that there is a standard through which they can communicate with one another. Currently, we can define token transfers between the chains, but in the long term with advances in cryptography and cryptoeconomic design, we could do more general-purpose data exchange.

What has changed are the particulars of the implementation details as the ecosystem of blockchains and blockchain engineering have evolved. For instance, advances in cryptography can be used to make Inter-Blockchain Communication (IBC) more efficient.

:arrow_up: Table of contents

The difference between Cosmos and Polkadot

The primary philosophical differences between Cosmos and Polkadot are that Cosmos by default assumes chains to be sovereign, have their own validator sets and security models, and can communicate and interoperate with one another. There isn’t necessarily a root chain. On the other hand, Polkadot takes shared security as its default with one root relay chain and other chains all being secured by the same validator set. They also have the concept of connecting other independent chains using “bridges,” which are similar to Cosmos’ Peg Zones.

:arrow_up: Table of contents

The difference between the vision for Ethereum 2.0 and that of Cosmos

For Ethereum, everyone has to use the Ethereum Virtual Machine (EVM) which currently suffers from a lot of governance issues. For instance, different interest groups have different ideas for where Ethereum should go, but they all have to use the same blockchain design. The problem with a Turing-complete virtual machine is that it forces everyone to use the average use case. Because of this, developers are stuck with Ethereum’s account model and lose out on a lot of parallelization.

:arrow_up: Table of contents

Why the Cosmos launch took longer than expected

One of the biggest reasons for the launch delay was poor time estimation. Hofstadter’s law, which states that it will take longer than you expect even after you take into account Hofstadter’s law, comes into play here. [We] didn’t appreciate the complexity of what we were building and a lot of that came to the surface as we started to build it, with a few iterations along the way. For instance, the Cosmos SDK wasn’t part of the whitepaper, but we realized that we would be needing a mature professional network for people to build blockchain applications. We started working on a new model putting object capability-based security first and thinking through how much of the Go programming language’s existing capabilities can be utilized in the security model.

:arrow_up: Table of contents

The approach to launching Cosmos

A big part of the team’s understanding of what they were doing was that they were not only building software, but also a community of network operators. What they were creating is very different from the proof of work system as they’re also concerned with storing private keys online but also hiding users’ IP. Because of this complicated infrastructure operational setup, the team was a little concerned about how mature the actual validator community was going to be by the time of the launch. However, thanks to Adrian from Crypterium, he got the ball rolling and eventually made it a self-sustaining community on its own, running testnets. When the team started doing decentralized starts, there were a lot of interruptions, especially when doing quality assurance with a distributed network of strangers over the Internet. In spite of this, the team finally got the networks up and running through the testnets, which lead to a community of operators that really understood how to run the software and how to deal with bugs and failures. During the halts, the team would have to restart the network and do so in a decentralized manner. As a result, the community really got a lot of practice through the series of testnets.

Another piece of observation was that there were a lot of people participating in the community testnets and answering questions, but they did not own any Atoms and thus did not participate in the fundraiser. Given that the Cosmos Hub was about to launch without the ability to transfer Atoms, there was some concern that some of the most competent or experienced network operators would not be able to participate. To solve this issue, the team came up with the idea of building some kind of incentivized testnet competition where people who are really participants can demonstrate their competence and thus be rewarded with some Atoms in the Genesis block. The team had a lot of support for that and some people eventually became validators from Block 1. In the Game of Stakes (GoS), it was really about making sure that the people who had put in so much time and effort into the testnet program would have some Atoms so that they could actually participate.

:arrow_up: Table of contents

The Cosmos Game of Stakes

The Game of Stakes (GoS) is a testnet designed to

  1. Test the limits of the Byzantine fault tolerance PoS protocol with 300 validators
  2. Simulate and encourage an adversarial environment with real-world attacks
  3. Expose Cosmos validators to cartel and byzantine activities

The halts from the GoS gave the Cosmos team many opportunities to test a range of behavior on the state machine. It also forced the team to test software that they weren’t testing internally, which helped them detect a lot of bugs. However, one thing that did not go so well was testing the economics of proof of stake. To resolve this issue, the Cosmos team escalated the testing process for proof of stake by increasing the rewards, pushing inflation 20,000% within a span of two months.

The team also suggested that as different projects move on and perform more incentivized testnets like this, more attention should be placed on the security of validators.

:arrow_up: Table of contents

On-chain governance in Cosmos and how does it differs from other blockchains

Let’s look at the on-chain governance processes between Tezos, Polkadot, Bitcoin, Ethereum, and Cosmos. Both Tezos and Polkadot use coin holder voting, whereby the more coins a person has, the more votes they secure. The drawback with this system is that it leaves out a lot of stakeholders. On the other hand, Bitcoin and Ethereum do not have an outlet for coin holders to signal their views. Specifically for Ethereum, it employs the unofficial carbon vote and the UX around it isn’t particularly user-friendly, leading to an extremely low voter turnout. To combat this issue, the Cosmos team has made on-chain signaling an official part of the core protocol to get more voter turnout.

There are three types of proposals in Cosmos: text proposal, software upgrade proposal, and parameter change proposal. The text proposal allows coin holders to signal whether or not they agree with a feature or idea proposed by the Cosmos team. In the second round, the software upgrade proposal, there is less emphasis on governance and more on coordination, and coin holders are merely providing an oracle to social consensus. Finally, the parameter change proposal allows for high levels code changes such as gas limit or block size in Ethereum.

:arrow_up: Table of contents

Insights and lessons gained so far from the two governance proposals

The first proposal saw some parameter changes in how inflation in the block reward is calculated and the second proposal was about the activation of transfers. When the Cosmos team launched the Cosmos Hub, it lacked the ability to transfer tokens; the team left it up to the community to decide when they think the activated transfers will be ready. The way the second proposal was framed, it basically asked if users want to activate the transfers. If so, the code would be signed by All in Bits, the company behind Tendermint. With signatures from three key base accounts (Ethan Buchman, Jae Kwon, Jack Zampolin), then the Cosmos team would go ahead and run the code. However, this gave people the impression that the Tendermint company could do whatever they wanted. Eventually, the proposal shifted to a “no,” and a new one is in the process of being written for enabling transfers.

:arrow_up: Table of contents

The balance between validators and delegators

This is still very much part of a massive experiment, so there is still an element of uncertainty as to how things are going to shake out. The benefit of having automated governance for delegators is that as long as the validator is voting, then all of the stake is coming with them, leading to high turnout numbers. Nonetheless, the downside lies in that this depends on who the delegators are, what they care about, how technical they are, and how much they understand the network.

The hope is for people who hold Atoms will become interested and involved in the maturation of the technology and network. Even if they are not validators themselves, the hope is that they are building businesses around the network and pushing it in a direction that makes sense for them as active stakeholders.

How can we actively make blockchains a more democratic system when there is actually participation?
It really depends on the community’s stakeholders’ engagement–how much people care about the system, how much they want to participate–as well as building incentives around governance. From a stakeholder’s point of view, they’re always thinking about what they’re getting out of this. If they simply do not care about the outcome that they’re supposed to vote on, they’re not going to vote.

Ideally, the closer the actual state machine of the blockchain is closer to the stakeholder, the more likely they’re going to pay attention and vote. This issue has always been paramount to the Cosmos’ design decisions–to not have shared security by default, but to have interoperability and sovereignty as defaults.

Initially, during the development process of Cosmos Hub, if a validator doesn’t vote, he or she would get slashed. Because of this, everyone started to write scripts that would auto-vote “abstain.” This made the team realize that forcing voting behavior was not effective. To respond to this issue, Sunny Aggarwal of Cosmos is working on a proposal called Subkeys, which would allow validators to designate one and only one key with the ability to vote in governance, but not move their tokens to someone else. Voters would then have their main key on their ledger in cold storage and governance key on their phones. This process is easier as there are already a number of mobile wallets such as Rainbow Wallet and Cosmos Station that support governance functionality.

:arrow_up: Table of contents

The long-term role and function of validators

The team sees validators in the long run as the planting the “seeds of the physical internet infrastructure for new kinds of digitally cooperative communities.” As middlemen, a big part of their responsibility is to connect local communities so that they share the same vision for interoperating, sovereign, independent blockchains.

:arrow_up: Table of contents

How to measure decentralization in the Cosmos Hub

This is something the team is still trying to figure out. Very early on in the development of Tendermint, they were only two guys–one with 99% of the stake and the other with 1%. As the team moves forward, they are in favor of pushing for a community of stakeholders and Atom holders who cherish and value decentralization. Until then, they will have to wait after transfers are enabled to see how larger, interested parties can get involved.

One solution Dan Robinson, Sunny Aggarwal, and Vitalik Buterin have discussed is partial slashing, in which the larger a validator is that faults with the system, the more they get slashed. This encourages validators from an economical, rational standpoint to help decentralize the network and not congregate everything into a centralized system.

:arrow_up: Table of contents

Sikka’s (Sunny’s validator) position of adopting low commission fees

Sikka, the name of the validator run by Sunny and Dave, started at zero percent commission while there were a couple of validators whose commissions ran up to 15%. The goal was for both sides to meet somewhere in the middle, to reduce the overall commission fee downwards, no more than 5%. There was a lot of criticism that both Sunny and Dave were price gouging, but they’ve both received zero in VC funding. They were running their validator through the UC Berkeley Data Center, which enabled them to keep the cost low. As for taking a long-term view of the Cosmos network, they’re charging 0% on the Cosmus Hub to earn delegation and reputation. The goal is to charge a nonzero percent commission rate on the Iris Hub to earn more delegation.

:arrow_up: Table of contents

The vision of the Cosmos SDK

From a lower level, it’s easier to understand if we start off with Tendermint ABCI. Tendermint was designed in such a way to abstract the state machine from the replication. What this means when we talk about blockchains as replicated state machines is that you have a separate replication piece, which is peer to peer. The team invented what they call the ABCI, the application blockchain interface, which takes away all the concerns of the state machine from the underlying replication engine machine. This flexibility permits users to build their own state machine in any programming language and to architect it however they like.

Despite being a low-level interface, there were a lot of common concerns related to concurrency, state management, and module structure. During the testing phase, the team built a few applications and realized that they needed another layer of abstraction to simplify all these concerns. This would allow developers to build more directly using the key pieces of their state machine without having to think about the ABCI. The Cosmos SDK was thus designed as a framework for building applications and state machines on top of Tendermint.

The lowest layer, also known as the base layer, is a thin wrapper around the ABCI that gives developers a flexible framework as to how they would store things in the state machine as well as how transactions are going to access and manipulate that state. The principles of Cosmos SDK fit here nicely because its object-based capability security: things are will only get access to the store if they are given an explicit capability that enables them to access the store. The base application layer is very general-purpose in that it does not force a particular serialization algorithm, it does not force a particular Merkle tree, nor does it force any notion of using coins.

The next layer, which a lot of people know as the Cosmos SDK, is where the Cosmos Hub is built on. It handles signatures, nonces, fee collections, and the cryptocurrency system. On top of that is another layer where the actual module for building custom logic for executing transactions rests in. Within the Cosmos Hub, there is a certain set of modules that define governance, proof of stake, slashing, fee distribution, and so on.

:arrow_up: Table of contents

The main differences between Substrate (Polkadot SDK) and the Cosmos SDK

These frameworks are generally very similar, with the main difference lying in people’s preferences for the programming language. If a developer wants to write a state machine, they would need to program it in Rust, which is what Substrate is written in. On the other hand, Cosmos is written in Golang and has another framework called Notion, which is JavaScript-based. The team simply wants there to diversity in the Cosmos ecosystem, whether it’s Cosmos SDK, Weave, Notion, and give developers the opportunity to use whichever one they feel most comfortable with.

Personally, Sunny Aggarwal thinks that Rust is a little bit too esoteric for most developers while JavaScript is a bit too loose; Go is the programming language that hits the sweet spot for security, ease of use, and ease of access.

:arrow_up: Table of contents

The current status of IBC and its roadmap

The team is currently trying to split the IBC spec apart into all of its constituent pieces and really define each piece according to what it is, what its properties are, what requirements are needed to satisfy particular needs, etc. Developers can follow the work in the GitHub repository (github.com/cosmos/ics), where ICS stands for interchain standards. In Cosmos/ICS, there are a large number of issues, each numbered ICS number 3, number 4, etc.

The team wants to ensure that the IBC is defined in a very general purpose way, has a specification that really focuses on some of the key data types, and has the properties and requirements of the protocol so that it becomes easy to implement in many different languages.

:arrow_up: Table of contents

Why someone would choose to build on Cosmos over Ethereum

If a developer wants direct interoperability with the rest of the Ethereum ecosystem, they should definitely build on Ethereum. The downside is that development and debugging contracts take place using Solidity. However, if the developer prefers independent sovereignty, a mature programming language, and debugging tools, Cosmos is probably a better option.

:arrow_up: Table of contents

The role of the Interchain Foundation with regards to Cosmos and Tendermint

The Interchain Foundation was set up in 2017 and addresses the key elements of the Cosmos Hub and Cosmos Network. Right now, attention is turned towards the grant program, which would be used to deploy capital and treasury funds. In the long-term, one of the goals is to figure what sustainability really looks like for a non-profit as this hasn’t been addressed in the blockchain space.

:arrow_up: Table of contents

closed #2