Bitcoin and other early cryptocurrencies were not Turing-complete by design, and could only execute a small set of operations that were specific to the goals of each blockchain. This led to Ethereum, which as described by Vitalik Buterin, arose from a desire to expand the functionalities of blockchains by building a general-purpose “World Computer.”
Fast-forward to today, we have seen many different designs of blockchains — innovating on different aspects ranging from privacy to scalability and governance. However, there has fundamentally been two classes of approaches on how to facilitate a world with thousands of decentralized applications.
- The ultra-powerful World Computer:
- Ethereum, Thunder, Algorand, Dfinity
- A super-fast blockchain which hosts tens of thousands of decentralized applications
- Strong security, very expensive to take over the entire chain
- Use “Layer 2” techniques for scaling like Lightning Network or Plasma
- An interoperable network of Blockchains
- Polkadot, Cosmos Network
- Many different blockchains, but can communicate with each other
- Application-specific blockchain (blockchain which runs a single type of application)
- Different security models, not 1 set of miners for the whole network such as in Bitcoin (although this is not entirely true for Polkadot)
These are inherently irreconcilable designs and each come with their own set of tradeoffs. This blog post illustrates the case for interoperability, and why a single “World Computer” may not be desirable. It will not explain specific technical implementations of interoperability such as the IBC (Inter-Blockchain Communication) protocol, which can be found here instead.
One Size Doesn’t Fit All
To build a truly robust platform for smart-contracts, the architecture of the platform has to be designed in such a way to cater to the broadest set of applications. For example, if the Ethereum core developers believe that many applications will require the use of a specific cryptographic primitive, they could upgrade the Ethereum protocol to include a precompiled contract that does the computation more efficiently. However, there may be applications that require a different set of cryptographic primitives, and those developers are beholden to the design and progress of the Ethereum protocol.
This is not just limited to niche cryptographic primitives — all applications built on any smart-contract platform are subject to the rules of the system, which include everything from transaction fees to the cost of computation (gas). Since these fixed rules cannot accommodate every use-case, certain applications are forced to make trade-offs with their design, such as 0x having on-chain settlement and off-chain order books. Having your application built on your own chain grants self-sovereignty, where the application developer can change and upgrade the underlying state machine however they see fit and are not tied to a specific design or architecture.
Lastly, being subject to a single economic measurement unit creates suboptimal results for the system. Is Ether simply a way of measuring computation, or is it a Store of Value? If we believe that Ether is a Store of Value, we will be less willing to spend it on paying for gas for applications, which makes the price of Ether significantly detached from the value of the utility it creates by powering computations. Instead, having a distinct money blockchain and a computation blockchain which can talk to each other may be able to yield better outcomes as a whole.
Decentralized systems are effectively controlled by markets. The Bitcoin blockchain is a market that matches sellers of security (miners) and buyers (users) who demand a monetary unit which is backed by the security provided by miners. The relationship between the buyers and sellers on a smart-contract platform like Ethereum is less clear because there are many different “products” being demanded. For example, exchanging digital cats for fun has dramatically different security requirements than trading a security token, however they both pay the same fees for transactions. Users of Cryptokitties are likely overpaying for the security of the Ethereum blockchain, effectively subsidizing high-stakes transactions on a decentralized exchange.
In an ideal situation, the supply and demand for a specific good or service should track each other as closely as possible. For the example above, one would question why the transfers of Cryptokitties need to be secured by thousands of mining farms in China. Instead, we could imagine a specific group of stakeholders (maybe early Cryptokitties supporters or investors) providing just enough security to support the system, whereas another application like MakerDAO can be supported by a completely different set of security providers.
Through this, we can create more efficient markets, which generally translates to cheaper fees and faster transactions for users. Since not all applications need the same amount of security, uniform security will usually be uneconomic for a large group of users. However, the drawback to this is that each application chain will require its own validator set, which may be difficult to bootstrap from scratch for certain applications. The inability to recruit a large and diverse validator set on a blockchain could compromise decentralization.
To build a “World Computer” that is scalable requires engineering ingenuity. Many designs have been proposed, primarily sharding and various cryptographic techniques. This is difficult because the platform has to be able to accommodate the “worst-case” application instead of the “average-case” application. This means that if the average application requires 10 transactions per second, but one application requires 10,000 transactions per second, for the blockchain to accommodate it, it needs to be able to facilitate a throughput of more than 10,000 transactions per second.
Instead, if we build blockchains which are application-specific, we would have more efficiency — where every chain is only as fast as it needs to be. For example, a game that requires many transactions per second is run on an entirely separate infrastructure from another blockchain which is used for settling payments once every month. Having separate infrastructure makes it more difficult to communicate cross-platform, but technologies such as the IBC and the Cosmos Hub solve these problems, which we will expound upon next.
It is difficult to imagine that only a single blockchain will exist in the far future, since different chains have different trade-offs in decentralization, governance and even functionality. In this vision of the world, how do we make sure that these blockchains are able to interoperate with each other? For example, an application like MakerDAO does particularly well with as many different types of assets as possible. However, since it lives on the Ethereum blockchain, it is difficult to get BTC used as collateral in the system, leading to initiatives like Wrapped Bitcoin being built. Fundamentally, Wrapped Bitcoin is simply a bridge between the Bitcoin blockchain and the Ethereum blockchain. Bridges are difficult to build because it requires a lot of coordination and trust from parties on both chains.
Direct communication between blockchains vs Indirect communication via hubs
The problem with the first approach is that it does not scale very well since new bridges need to be instantiated each time to connect two chains. Because of this, routing all the cross-chain communication through a single hub is a much more efficient structure.
For example, if a chain wanted to communicate with 3 other chains, it can simply build a bridge to the hub which then routes messages to the other respective chains, without having to build 3 separate bridges. This is the fundamental design of the Cosmos Hub. Using the example above, if we were to build a MakerDAO chain on the Cosmos Network, we can easily have access to many other assets without having to build individual bridges to other chains — just one to the Cosmos Hub, which will already be a plug-and-play component of the Cosmos SDK, given that the SDK is designed to be a modular framework.
The current default for blockchain applications is to build on an existing smart-contract platform like Ethereum instead of building their own chain from scratch. However, this will likely change as tools to build your own blockchain become as easy and unrestrictive as writing a web application, and the interoperability between chains become seamless. The “World Computer” vision does have some significant strengths such as shared security which reduces the mental overhead of building a new chain from scratch, but there is also clear upside to choosing your own security model depending on the type of application you are building. We suspect that it will be fairly easy to bootstrap a group of validators for your blockchain if they are also stakeholders in the success of the application (investors, early users, power users, team, etc).