Partly cloudy: How blockchain can become a force of nature

On Jan. 3, 2009, Satoshi Nakamoto mined the Bitcoin genesis block and launched the largest technological gold rush of the century. Bitcoin (BTC) was at once a software, a “protocol,” a network, a development team and a new thing called cryptocurrency. Simultaneously, cloud technology proved that abstractions and application programming interfaces could facilitate explosive scalability and product agility, removing all of the distractions that were prevalent in 90% of any application’s technology stack. 

Despite the onset of dozens of competitors that have appeared since Bitcoin’s inception, almost all have been vertically integrated and none have resulted in the same changes of explosions in products that the cloud has. Networks such as Ethereum and EOS broke that norm by providing a “platform” for several different public blockchain networks to emerge — but what lies beyond even that?

To answer this question, we need to identify what a blockchain is at its most atomic level. Bitcoin and its successors, such as Ethereum and EOS, provide several technical features, like peer-to-peer gossip networks, decentralized consensus mechanisms and cryptographically backed “ownership.” These are not necessarily novel technical features, having existed previously in the backends of many products that failed to create the level of value Bitcoin has.

Moreover, defining any blockchain by its purely technical features is a misstep that frames the technology as existing only for technologists. For people outside of tech, the most notable feature of Bitcoin, for example, is that it creates and operates Bitcoin, a digital currency that you can own, is scarce, and is provably resistant to duplication and counterfeiting.

Cloud on the other hand (and aptly named) is nebulous and abstract in nature. Cloud decomposed the modern application stack into functions (or the things you can do), placed them behind APIs, and offered them as services à la carte. This innovation resulted in a wonderful amount of agility in new product development. Product teams that would have crumbled under the weight of general infrastructure and system administration costs were freed from the burden of understanding what was inside the black boxes on architecture diagrams. This created a powerful idiomatic shift in the industry and eventually resulted in an explosion of customer-driven products and services.

Designing applications for the cloud leads developers away from intriguing but ultimately less valuable concerns like micro-optimizing their choice of database parameters or how they administer servers to more important questions critical to their product. Abstracting these technical details and considerations behind a set of functionalized services puts the focus on how your product is unique among its competitors rather than the rote aspects of operating a modern application stack. If this abstraction model has helped companies successfully launch more diversified products, what then are the functionalized services that blockchain applications would need to achieve the same outcome?

Functionalizing blockchain

There are many ways to answer this question, but we will focus on two potential approaches: horizontal functional layers and high-level types.

Within horizontal functional layering, a blockchain — like EOS or Ethereum — can be viewed as a computing system capable of executing hundreds or thousands of provably correct smart contracts, a storage system that provides globally consistent data, a strong authentication system, and an ordering service to resolve disputes among operations. For parity with existing blockchains, each of these layers would be independently auditable. In this view, concepts such as block production and consensus protocols do not appear as distinct layers because they offer nothing beyond the implementation details of the other layers. This suggests that, if there was another means of achieving these functionalized services, then blocks or a peer-to-peer network may be unnecessary.

The alternative approach would be to look at the higher-level concepts or guarantees and functionalize them as services. For instance, among the many problems a cryptocurrency must solve is the double-spend problem. If one person has 1 Bitcoin and spends it, they cannot spend it again. Conceptually, this sounds basic, but in a decentralized global-scale computer system, it can be hard to maintain such a guarantee efficiently. A service that provides that concept such that it can be easily integrated into any application would abstract away all of the complexity of operating a blockchain and enable the discovery of applications beyond cryptocurrencies more effectively.

As another example, many enterprise-blockchain use cases require strict immutability of data. A service that provides that concept would reduce friction in bringing these use cases to market. In fact, this quality has already seen commercial functionalization as a service: It is the core offering of Amazon’s Quantum Ledger Database. And how these services are implemented is and should be irrelevant to the product developers.

Why the cloud needs blockchain

What was less obvious about the cloud revolution than its ability to accelerate product delivery was its capacity to enable inscrutable architectures and failure modes. When cloud systems work, they work astoundingly well; but when they fail, the general phrase is: You had backups, right? This liability is a non-starter for industries that need strong auditing and end-to-end authenticity. Unbreakable rules are harder to come by in the modern cloud. Although it can be easy to imagine and launch a complex architecture in the cloud, it can be nearly impossible to fully understand the resulting moving pieces.

Blockchain, on the other hand, is something alien to the world of cloud computing: It is completely and rigidly in control of itself. This may mean that it will never be able to scale to the heights of modern cloud technology. What if we applied the same insight of the cloud at a higher level? Perhaps 90% of all application logic can be loose and inscrutable if the core and material, comprising 10%, are rigid and easy to reason about. If blockchain were functionalized and offered as a service alongside other traditional functions, would the resulting application stack be one where we were both confident enough in it to give it control over real money and agile enough that visionary product teams could still create products the world has never seen?

Into the clouds

This article seeks to challenge the industry’s normal definition of blockchain. I have never taken the term literally as a sequence of blocks cryptographically linked into a chain by a specific network of tribal token holders. Instead, I preferred to reason about the novel aspects of what made blockchain something unique against the history of computing protocols and systems.

While a literal chain of blocks may be state-of-the-art technology today, it is important to continually remind ourselves that this is just an implementation of larger concepts like end-to-end authenticity or strong ownership of data. Even if we never conceive of protocols that allow for a real abstraction between service provider and service consumer, we should strive to enable a more product-focused industry idiom. We have only begun to realize the potential of blockchain and I, for one, am excited to see that progress continue.