Bitcoin and the 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 — from innovating on 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:
- An interoperable network of Blockchains
These are inherently irreconcilable designs and each comes with its own set of tradeoffs.
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 tradeoffs 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 this example, 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.
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 infrastructures makes it more difficult to communicate cross-platform, but technologies such as the Inter-Blockchain Communication (IBC) have the potential to solve these problems. IBC, also understood as Chain Relays, allows blockchains to read and validate events in other blockchains. Furthermore, Peg Zones or Bridges enable interoperability with live blockchain networks like Ethereum. Peg Zones fulfill special validator responsibilities across chains — subsequently generating a new genre of token, that represents the intersecting relationship, which is then transported through these Chain Relays. An example of this is the Ethermint experiment, a blockchain that interacts with the Cosmos Network over IBC. Taking a snapshot of Ethereum, the state at a point in time informs the creation of a new Zone in the IBC network.
Here’s where the usability comes into play, there are two options: build an entirely new blockchain using IBC to ensure interoperability or develop a solution with an existing IBC enabled SDK.
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.
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 three other chains, it can simply build a bridge to the hub which then routes messages to the other respective chains, without having to build three separate bridges.
The current default for blockchain applications is to build on an existing smart-contract platform like Ethereum instead of building your 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 a clear upside to choosing your own security model depending on the type of application you are building. I suspect that it will be fairly easy to bootstrap a group of validators for your blockchain if they are also stakeholders (investors, early users, power users, team, etc.) in the success of the application.
Frictionless interoperability between blockchain protocols, without needing a third party exchange to facilitate marks the next major stride in the ecosystem. Blockchain developers need to be cognizant of incorporating frameworks for interoperability during the formation of the technology in order to maintain any competitive advantage in the blockchain space.
Feature image via Pixabay.