On January 3, 2009, Satoshi Nakamoto mined the Bitcoin Genesis block and started the largest technological gold rush of the century. Bitcoin (BTC) was a piece of software, a “protocol,” a network, a development team, and a new thing called cryptocurrency all at the same time. At the same time, cloud technology has proven that abstractions and application programming interfaces enable explosive scalability, product agility, and remove any distractions that prevailed in 90% of an application’s technology stack.
Despite the appearance of dozens of competitors that have emerged since Bitcoin was founded, almost all of them have been vertically integrated, and none have resulted in the same explosion changes in products as the cloud. Networks like Ethereum and EOS have broken this norm by providing a “platform” for the emergence of several different public blockchain networks – but what is beyond that?
To answer this question, we need to find out what a blockchain is at its most atomic level. Bitcoin and its successors such as Ethereum and EOS offer various technical functions such as peer-to-peer gossip networks, decentralized consensus mechanisms and cryptographically secured “property”. These are not necessarily novel technical features that were previously present in the backends of many products that did not reach the value that Bitcoin has.
In addition, the definition of a blockchain due to its purely technical characteristics is a misstep that frames the technology as only existing for technologists. For people outside of tech, for example, the most notable characteristic of Bitcoin is that it creates and operates Bitcoin, a digital currency you can own that is scarce and has been proven to be resistant to duplication and counterfeiting.
Cloud, on the other hand (and aptly named), is nebulous and abstract in nature. Cloud broke the modern application stack down into functions (or the things you can do), placed them behind APIs, and offered them as services à la carte. This innovation resulted in wonderful agility in the development of new products. Product teams that would have collapsed under the weight of the overheads of infrastructure and systems administration were relieved of the burden of understanding what was in the black boxes on architecture diagrams. This led to a major idiomatic change in the industry and ultimately an explosion of customer-oriented products and services.
Designing applications for the cloud removes developers from interesting but ultimately less valuable problems like micro-optimizing database parameter selection or managing servers on more important issues critical to their product. When you put these technical details and considerations behind a set of functionalized services, the focus is on how unique your product is among its competitors, rather than the red aspects of running a modern application stack. If this abstraction model has helped companies successfully bring more diverse products to market, which functionalized services do blockchain applications need to achieve the same result?
There are many ways to answer this question, but we’re going to focus on two possible approaches: horizontal functional layers and high-level types.
Within the horizontal functional stratification, a blockchain – like EOS or Ethereum – can be viewed as a computer system that can execute hundreds or thousands of verifiably correct smart contracts, a storage system that provides globally consistent data, a strong authentication system, and an ordering service for disputes between operations to solve. For parity with existing blockchains, each of these layers could be checked independently. In this view, concepts like block production and consensus logs are not shown as different tiers as they do not offer anything beyond the implementation details of the other tiers. This suggests that blocking or a peer-to-peer network may not be necessary if there is some other means of achieving these functionalized services.
The alternative approach would be to look at the overarching concepts or guarantees and functionalize them as services. For example, one of the many problems a cryptocurrency has to solve is the problem of double spending. If a person has 1 bitcoin and spends it, they cannot spend it again. Conceptually this sounds basic, but in a decentralized computer system on a global scale it can be difficult to efficiently maintain such a guarantee. A service that provides this concept in such a way that it can be easily integrated into any application would abstract away the entire complexity of operating a blockchain and enable the detection of applications beyond cryptocurrencies more effectively.
As another example, many enterprise blockchain use cases require strict immutability of the data. A service that provides this concept would reduce the 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 developer.
Why the cloud needs blockchain
What was less obvious about the cloud revolution than its ability to accelerate product delivery was its ability to enable unfathomable architectures and failure modes. When cloud systems work, they work amazingly well. but when they fail, the general proposition is: You had backups, right? This liability is a no-starter for industries that require rigorous testing and end-to-end authenticity. Unbreakable rules are harder to find in the modern cloud. While it’s easy to imagine building and launching a complex architecture in the cloud, it can be next to impossible to fully understand the resulting moving parts.
Blockchain, on the other hand, is something alien to the world of cloud computing: it has complete control over itself. This can mean that it will never be able to scale up to the height of modern cloud technology. What if we applied the same insights into the cloud at a higher level? Possibly 90% of all application logic can be loose and unfathomable if the core and material that comprise 10% are rigid and easy to think about. If blockchain were functionalized and offered as a service alongside other traditional functions, the resulting application stack would be one where we were both confident enough to put it in control of real money and agile enough that visionary product teams could still develop products over and above which the world has never seen?
In the clouds
This article attempts to challenge the industry definition of blockchain. I never took the term literally as a sequence of blocks cryptographically linked in a chain by a particular network of tribal token holders. Instead, I preferred to think about the novel aspects that made blockchain something unique against the history of computer protocols and systems.
While a literal chain of blocks may be state of the art these days, it’s important to constantly remind ourselves that this is just an implementation of bigger concepts like end-to-end authenticity or strong ownership of data. Even if we never envision protocols that allow a true abstraction between service provider and service consumer, we should strive to enable a more product-oriented industry language. We are only just beginning to see the potential of the blockchain and I am pleased that the progress is continuing.
The views, thoughts, and opinions expressed here are the sole rights of the author and do not necessarily reflect or represent the views and opinions of Cointelegraph.
Bart Wyatt is Director of Solutions Architecture at Block.one and leads the company’s core blockchain engineering team. With over 18 years of experience in IT and the past seven years devoted to asset tokenization and decentralized identity, Bart has experience overseeing technology teams at multiple companies focused on privacy solutions, deniable attestations , specializing in degradable cryptographic evidence, gaming and advertising technology.