This is the second part of a 3-piece blog series on the key ideas behind the Cosmos Network.
The previous part covered the basic ideas behind early Tendermint, an approach to building a cryptocurrency without Proof of Work mining. Early Tendermint merged together a consensus algorithm based on Practical Byzantine Fault Tolerance (PBFT) with the concept of security bonds, in order to enable construction a permissionless cryptocurrency with low operating costs. These ideas were in place by the end of 2014, and early technical work on Tendermint had begun.
The logical next step would have been to conduct an ICO, and attempt to launch a currency based on the Tendermint design. Ethereum trod that path in 2014, so a precedent for that path existed. This was a fork in the road the Tendermint team did not take! It’s journey over the next two years was much richer, and the vision evolved alongside major developments in the blockchain industry. This article tells that story, and will familiarize the reader with the concept of separating out consensus and application logic, leading to application-specific blockchains.
Reading this article will immerse you into the novel possibilities of application-specific chains. The view at the end of the road is spectacular; join us on the journey!
2015 was a unique year — this was the depth of the bear market in cryptocurrency; bringing deep skepticism about the value proposition of cryptocurrency. A few, hitherto fringe, ideas came into prominence. Two of them — decentralized applications and Bitcoin sidechains — will be critical to the Cosmos vision. But we’ll postpone the ripple effects of Bitcoin sidechains to the next article in the series.
The first is the wave of decentralized applications (DApps). Inventors had been adding new applications to Bitcoin — futures contracts, gambling contracts and proof of existence applications for a while already. The Ethereum whitepaper and vision burst onto the scene, popularized the concept of a DApp, and the implementation of Ethereum as a platform for hosting DApps. A DApp can be imagined as open data and code, that lives on a decentralized network (a blockchain or a BitTorrent like network) beyond a corporation’s ownership and delivers some utility to its users. A practical example is the Ethereum Name Service (ENS), which is a decentralized registry of human meaningful names (like meher.eth) that can be owned by Ethereum accounts. A hyperbolic example, which we simply do not have the capacity to implement today, is decentralized Uber — an application with the functionality of Uber, but with all of its data, processing logic and user accounts operating on a blockchain network.
Adherents of the decentralized applications vision were making a radical leap — they were casting away new monetary instruments, like the currency bitcoin, as the centerpiece for leveraging blockchain technology and put applications — exchanges, domain names, social media, prediction markets etc. — as the theater of operation for blockchains. The launch of Ethereum in July 2015 was a seminal event, since Ethereum actually delivered the ability to build decentralized applications like ENS, albeit with a lot of constraints. The constraints were that all of the application data needed to be public, each interaction with the application required the user to bear significant transaction costs in ether and the quantity of data and processing power at an application’s disposal was reminiscent of the 1970s, rather than modern computing. Nonetheless, it was a powerful proof of concept.
Ethereum is built as a general purpose blockchain. In principle, one can write any software application to run on Ethereum. This is the key point of differentiation between the Ethereum vision for DApps, and the Cosmos vision for DApps. Sometime in 2015, the Tendermint team questioned whether a single blockchain ought to host all of the DApps, or whether each DApp ought to be hosted on its own dedicated blockchain. Is the future one of a single dominant DApp hosting platform (Ethereum), or one of a myriad blockchains, each tailored to a specific application? The Tendermint team bet on the latter vision.
This bet altered the demands from Tendermint. Early Tendermint had been developed with the goal of building cryptocurrencies. Now, the need was a deliver a general platform that allowed others to build their own blockchain hosting specifically their own application aka an application-specific blockchain. The focus shifted from the pure accounting of cryptocurrencies to hosting general application logic and data.
Node software for various blockchain networks can be divided into three functional components, each playing a different role. These components are: Networking, Consensus and Application Logic — and they can be thought of as independent modules that work together to make a blockchain node:
Until this point, Bitcoin mixed the subcomponents of these modules into an interwoven codebase. Two projects, Tezos and Tendermint, initiated the effort to separate these components neatly, so that they could be built and upgraded in parallel. Their motivations for such separation are radically different, but that’s a topic for a different day. Over time, other projects have also adopted the design pattern of separating these modules, so much so that it isn’t a particularly unique idea anymore!
Tendermint combined consensus and networking into Tendermint Core. The Application module would run concurrently, on the node, entirely separate from Tendermint Core. A protocol, called ABCI, was developed to facilitate communication between Tendermint Core and the Application module. The following diagram illustrates this new Tendermint architecture.
This concept, and its utility, is better understood via analogies. Let’s consider two analogies — your personal computer and DNA. Ponder this question: What makes a computer “your computer”? All computers share thousands of hardware and software components — cores, buses, BIOS, operating systems etc. What makes your computer yours is the data you input into the computer, and the software you configure on it. Tendermint Core is analogous to the systems that are common to all of the computers — it concerns itself with lower-level tasks like networking and consensus that all blockchains need to perform. If the reader, as an entrepreneur, launches their blockchain for a decentralized exchange and I, launch a different blockchain for a decentralized Twitter application; both our chains can be powered by Tendermint Core. Tendermint Core is akin to an operating system for blockchains.
Let’s zoom in to a blockchain running decentralized Twitter. This specific blockchain requires tailor-made logic and needs to store user data. This logic might, for instance, implement the restriction of tweet length to 140 characters; with each tweet being a transaction on the blockchain. The application data would store a giant list of all historical tweets in a query-able format. It’s the combination of application data and application logic that gives a decentralized Twitter blockchain its “Twitteriness”. Similar to how your data and the software you install make your computer uniquely yours. The new Tendermint design allowed the separation of the Twitter specific items, implemented as an application, from the other, more mundane parts of the blockchain (Tendermint Core).
This design also has inspiration from biology. If one considers the difference between one of your cells and one of mine; the majority of the machinery — amino acids, lipids, organelles etc. — are all common between the two. What differentiates our cells are the differences in our DNA. The Application logic and data, in the diagram, is analogous to DNA while Tendermint core is akin to all of those pieces that are somewhat immaterial to our specific identity.
The value proposition of this design is that future entrepreneurs, launching application-specific blockchains will need to focus only on their application logic. This is powerful in itself, but the Tendermint team went a step further with Cosmos SDK — a framework for writing blockchain applications.
While each application-specific chain has its unique data and logic, many decentralized applications tend to require similar pieces of logic, or base components. For instance, consider tokens and token transfers. Many applications — decentralized exchanges, stablecoins etc. — will require the issuance, transfer, accounting logic and delegations of token rights on the blockchain. To make the creation all of these token operations a cinch, the Cosmos SDK contains a “bank” module with prebuilt logic for token functionality. In a similar vein, the SDK contains modules for governance operations, staking operations etc. Future modules will add functionality like auctions, exchange operations, reputation operations, registry operations etc. The result will be a rich toolset of components to combine in building blockchain applications.
These SDK modules allow for the simplification of developer experience when developing blockchain applications. The aim of the SDK is to be the Ruby on Rails of blockchain applications. If this approach pans out; imagine dozens of application-specific chains hosting disparate functionality, and their own individual tokens.
This incipient world of application-specific chains, each containing their own staking token and validator community, is a powerful alternative to the Ethereum vision of DApps written as smart contracts and hosted on the Ethereum chain. While it remains to be seen how this new model shall fare, the contours of its advantages and disadvantages are already visible.
The first advantage of the application-specific model is community sovereignty — each chain is able to make design decisions tailored for the specific application at hand, independent of the choices made by other applications in their own chains. This serves to avoid contention between different application communities. We’ve seen this kind of contention emerged in the Ethereum ecosystem when the DAO was hacked, and Ethereum holders were forced to make radical decisions to repair the accounts of DAO investors. It emerged again in the Parity multisignature episode. Future upgrades to the Ethereum platform have the potential for affecting different applications differentially. This can become a bone of contention, when different application communities seek fundamentally different upgrades to the Ethereum protocol.
The second feature of the model are the better scaling and performance characteristics of each application-specific chain. Each chain need not specialize in general purpose computation, and can restrict operations to a very small set of transactions. Application logic can be implemented “closer to the metal” making it operationally cheaper. Applications also get their own dedicated capacity, and need not share that capacity with other, high transaction volume, applications. This is an important feature, since ICOs on the Ethereum platform have crowded out capacity for other applications.
However, this model creates some specific downsides. The primary downside is weaker security. Imagine thousands of chains, each carrying their own staking tokens and applications. It is likely that the majority of these tokens will have low market capitalizations (<$100 million), and therefore be vulnerable to alterations of their history. There are a few potential solutions — replicated security and sortition based security — to securing hundreds of application chains. We shall cover these methods in the blog later; but these methods will invariably encroach upon the community sovereignty of application-specific chains.
Some proponents of the Cosmos Internet of Blockchains vision believe that small market capitalization chains (aka small chains), secured by Tendermint, will be secure enough for practical purposes. Their argument is that really egregious attacks on small chains require the attacker to buy up 66% of the voting power in a relatively illiquid staking token. Such large purchases ought to drive up the market capitalization to higher levels, and reduce the incentive to attack the chain once a majority of the tokens are bought by the attacker. Another defense, available to small chain communities, is to (hard) fork out the attacker and disregard their blockchain, similar to what Ethereum did to the DAO attacker. It remains to be seen whether these arguments will survive contact with reality in the next decade.
The second downside is the potential to create application silos, where data and tokens on one application chain are unable to be synergistically used with logic on a different chain. Just as Uber drivers find it really hard to migrate to Lyft, and carry their own reputation; the blockchain sector risks the creations of similar economic incentives for the percolation of silos. Thankfully, the Tendermint team has worked out beautiful concepts, which are the subject of our next article, to route around some of these impending issues.
In this article, we’ve covered the story of how Tendermint responded to the prominence of decentralized applications, by presenting and implementing the toolsets for entrepreneurs to build application-specific chains. These application-specific chains, are potentially, better base layer infrastructure for the realization of decentralized exchange, stablecoin, prediction market, decentralized social media and other incipient technologies.
This vision naturally raises the specter of data and value silos that prevent applications from inter-operating with each other seamlessly. This will be subject of the next article in our series, which covers the development of IBC — a protocol for blockchains to send authenticated value carrying messages to each other — and of the Cosmos Hub. The next article will be last in the series and completes our exposition of the key ideas behind the Cosmos Network.
If you want to discuss Cosmos further, stop by our Chorus One Telegram and say hi. And, of course, we’re happy to answer any questions about delegating to Chorus One.
