Besides the addition and subtraction of numbers on a distributed ledger (i.e. cryptocurrencies), blockchains hold the power to provide most — if not all — of the services that centralized computing can provide. Thus, as the community of builders continues to grow, we have seen the very beginning of not only decentralized money, but also decentralized file storage, computing services, financial services, real-life asset ownership records, supply-chain management, personal identity, energy distribution, health records, governance, and more.

Critical for the success of decentralized applications (dApps), however, is the ability for developers to efficiently control the input and output of the data being decentralized. To date, there have been a limited number of options available for developers to accomplish this, but at least two new blockchain projects I’m aware of are working on a fundamentally different approach. Below, I’ll briefly describe the ongoing evolution dApp development options and explain why application-specific blockchains hold tremendous promise for the future of the industry.

Smart Contracts

Fundamentally, it is important to understand that blockchains are run by machines that essentially do three things: networking, consensus, and state management.

These machines must run application-layer software that is responsible for updating state. In the case of blockchains like Ethereum, a turing-complete(ish) virtual machine is the application layer. (For those unfamiliar, the software programs that developers deploy onto blockchain virtual machines are often called Smart Contracts.)

And therefore, to date, for the vast majority of developers out there trying to build decentralized applications, the main option has been a one-size-fits-all application layer (i.e. the Ethereum Virtual Machine, EVM), which runs on a network of computers that produce blocks only every 15 seconds or so. Not only is this painfully slow for many applications (especially given the delayed finality of state), but because of the broad-sweeping and complex nature of the EVM, it is devastatingly easy to introduce bugs (the DAO bug, the Parity bugs, etc..).

From this perspective, then, it’s not surprising that the value of pretty much every cryptocurrency on the planet has taken a ~80–90% drop this year; the hype and speculation has been way out ahead of the technology promising to give us all sorts of decentralized applications with mainstream adoption.

How do we fix this?

Many are trying.

The main approach teams are taking is to tweak, streamline, and/or simplify a blockchain’s virtual machine and governance policies to make it less maddening to develop and update reliable applications (indeed, developer adoption will be a critical metric — if not the critical metric — to watch for in 2019).

A few representative examples from among the 40+ teams working on thisinclude Tezos, Dfinity, and Hedera Hashgraph.

Tezos is introducing a new programming language called Michelson (a low-level, stack-based, strongly/statically typed, and purely functionallanguage) that is interpreted directly by the Tezos VM and allows for formal verification of the mathematical correctness of smart contracts. Michelson also has high-level features like maps, sets, lists, cryptographic primitives, and arbitrary precision integers. Designed to be more “correct” than EVM’s efficient and broad-sweeping design, the idea here is that Michelson will be significantly less error-prone than Solidity, and it will be able to handle the lightweight transaction logic needed for most on-chain smart contracts (leaving the more heavy computations to be done off-chain). Importantly, Tezos is implementing a flexible on-chain governance system to make upgrades to the protocol as needed.

Dfinity on the other hand, self-described as “Ethereum’s crazy sister”, is attempting to double-down on the Ethereum approach and create an insanely efficient/performant world computer that has its own AI-powered “Blockchain Nervous System” that can upgrade the protocol on the fly. Dfinity’s VM will be compatible with the EVM (still using Solidity as its main high-level language), and the vision is for there to be millions of computers available in the network to facilitate the building of decentralized versions of AWS, Google, Facebook, etc…

And as a final example, Hedera Hashgraph is taking a totally different approach to Distributed Ledger Technology (DLT) by not technically being a blockchain. Instead, Hedera is a DAG (Direct Acyclic Graph) that allows developers to use a Java SDK to build applications in concert with file storage and Solidity-based smart contracts, if needed. Hedera’s aim is to allow developers the flexibility and speed needed to create nano-transaction-based applications (e.g. fair and reliable pay to publishers, reduced-spam email, etc…)

Application-specific blockchains

While there are no lack of teams making tweaks to smart contract VM nuances, supporting developer architecture, and/or governance, there are at least two teams — the Cosmos Network and Polkadot — that are offering developers a fundamentally different way to create decentralized applications.

The Cosmos Network has proposed the use of Application-Specific Blockchains, which offer developers the ability to build out the exact application layer needed to update state, while also providing customizable software for networking and consensus (i.e. Tendermint). As you can imagine, rather than working in a one-size-fits-all VM and governance environment, with the Cosmos SDK developers can pick and choose available npm-like modules (or of course build their own) that include features like staking, slashing, tokens, accounts, inter-blockchain communication, governance, etc…

Similarly, Polkadot allows developers to create parachains, which are analogous to Cosmos’ zones, where application-specific blockchains can be built. Thus, Cosmos has zones that connect to hubs, and Polkadot has parachains that connect to relay chains.

An important difference to note here is that Polkadot’s infrastructure will provide shared security (i.e. a common set a block validators) right out of the gate by design, whereas Cosmos will be requiring developers to initially recruit their own validators from scratch. The benefit for those building on Cosmos via this approach is even more sovereignty over performance (e.g. someone else’s app can’t slow or take down the network), but this comes at the expense of needing to rally validators to participate. (That being said, the Cosmos Network is also planning to support shared security shortly after its mainnet launches, so there will be both options for developers, as needed.)

Which are more promising, new smart contract platforms or application-specific blockchains?

Like most things in crypto, the answer is that it depends and we’ll have to wait to see how the technology develops. There will likely be many applications where slow finality and a generic VM will be acceptable, whereas other applications will require a highly-tuned VM and governance environment for specific use cases.

In fact, considering the overall ecosystem, we can think of projects such as Dfinity and Hedera Hashgraph as creating blockchains that will be highly optimized for specific types of applications (e.g. a decentralized AWS, a decentralized Visa network, etc…). Polkadot and the Cosmos Network are certainly noteworthy because if such blockchains offering various forms of VMs aren’t suitable, developers can build their own blockchains without having to fork an existing chain and do the additional heavy lifting of maintaining networking and consensus software.

Thus as developers who are building decentralized applications consider all the parameters that their network will require (speed, scalability, security, governance, identity, payments, etc…), there will almost certainly be a wide range of underlying technology options available.

Personally, I’m extremely bullish on the approach of building a custom application layer leveraging your own code and open source modules (similar to how web/mobile apps are built today), where — to start — you can leverage shared security until your application warrants it’s own validator set for additional sovereignty and security.

Moreover, both Cosmos and Polkadot are planning build and deploy a zone/parachain ASAP that supports the EVM (e.g. see Ethermint). This will allow existing applications that require faster transaction speeds to port over their underlying infrastructure, and it will give the multitude of developers learning Solidity today an initial place to land.

Then, I suspect we’ll quickly see an increasing number of teams try out both the tuned-VMs on newer chains and application-specific blockchains on Cosmos, Polkadot, and any other networks that leverage this approach.

Is the blockchain community overly fractionalized?

As a final thought, it’s important to note that the number of teams out there who have the DevOps/OpSec chops to run performant and secure nodes is limited (maybe a couple hundred teams, at best?). These teams, some of whom I’ve written about previously, are currently split amongst many competing blockchains, which is undoubtedly slowing overall progress of the blockchain/DLT industry.

However, this is not the first time we’ve seen this; open source software development has already proven to be extremely powerful over time.

Consider the unix/linux world, for example. The “fractionalized” development of Ubuntu, CentOS, Debian, Fedora, etc.. (and even MacOS, Android, etc…) still collectively produced the dominant operating systems that run our computers today.

I’m certainly not alone in believing, optimistically, that we’ll see the blockchain space develop in a similar fashion.

—

Author’s note: Thanks in advance for any suggestions/corrections for this article; I very much welcome feedback. Feel free to subscribe to my personal newsletter where, in addition to crypto, I also write occasionally about health science and startup life. Special thanks to Andy, Tony, and Lorien for review and insightful conversations about the above article. And finally, before you leave, please feel free to comment below (or inline above), hit the clap button, and/or share this article with a friend. Let’s keep the conversation going. Thanks!