The blockchain landscape is still very technical. Aside from the early enthusiasts and pioneers, it is hardly comprehensible to the masses, and it will continue to be that way, unless it breaks out of its technical shell.
This isn’t unlike the predicament the Internet was stuck in, prior to the Web.
So, what if blockchain technology is more like the Internet, which means that we are still waiting for its Web layers to emerge, in order to fully exploit its capabilities?
Today, blockchain protocols, solutions, or platforms are not straightforward to work with. At least, they require a good degree of technical know-how that far exceeds what an average web developer or savvy semi-technical business person can do with the Web today.
But does it have to be that way forever?
Blockchains Have Many Common Features
If you examine the variety of available blockchains, many of them handle the same few basic functions, centered around recording (digital) value without requiring a third party to move it.
Outside of this core capability, a number of additional functions and features are typically found:
- Central nucleus: Records of Value
- Basic Features Layer: Ownerships, Balances, Transfers, Assets creation, Time-stamping, Security, Programmability.
- Interaction Layer: Verification of transactions, Proofs (of existence, or other), Movement history, Technical or Business Logic, Storage, Settlements, Identity, Naming.
If this set of functionality is generic in multiple blockchain platforms, why do we need many ways to call them up? Why not institute a common way to check identity, asset ownerships, time-stamping, etc. across any blockchain?
Note that I didn’t include cryptocurrencies, shared distributed ledgers, or even decentralized protocols in these layers because they are applications and outcomes of blockchains.
If you stand back from the nitty gritty of these layers, you will realize a key abstraction that is common to most blockchains: how they shatter the intermediary trust paradigm by enabling transactions to occur at the peer-to-peer level, without the necessity of central choke or delay points.
Since there is so much homogeneity in functionality intent, then why are there so many different and incompatible blockchain technologies and software? That’s because each blockchain implements these basic features and interaction layers in its own way.
Learning from the Web’s History
This scenario is not unlike the position the Internet was in, prior to the Web. Tim Berners-Lee described that period well, circa 1989: “In those days, there was different information on different computers, but you had to log on to different computers to get at it. Also, sometimes you had to learn a different program on each computer. Often it was just easier to go and ask people when they were having coffee…”.
Since millions of computers were already being connected to a fast growing Internet, Tim figured the way to solve this problem was to have them share information via an emerging technology he proposed, called hypertext (structured text that uses logical links between nodes containing text) that he described in a seminal 1989 document called “Information Management: A Proposal”.
“By October of 1990, Tim had written the three fundamental technologies that remain the foundation of today’s web (and which you may have seen appear on parts of your web browser):
HTML: HyperText Markup Language. The markup (formatting) language for the web.
URI: Uniform Resource Identifier. A kind of “address” that is unique and used to identify to each resource on the web. It is also commonly called a URL.
HTTP: Hypertext Transfer Protocol. Allows for the retrieval of linked resources from across the web.” [Source: http://webfoundation.org/about/vision/history-of-the-web/]
As a footnote to this backdrop, Tim’s boss originally gave a lukewarm response to the paper, handwriting on it “Vague, but exciting”. In truth, some vagueness in a protocol is a good feature, because it implies that its scope is widely encompassing, without being too restrictive. One could argue that Satoshi Nakamoto’s paper was also vague, pertaining to the fullness of its targeted applications beyond the peer-to-peer exchange of electronic money. Ethereum, for example was built specifically as a general-purpose blockchain platform environment, and didn’t want to be specific, as an original design objective.
Since their early days, the Internet and the Web have matured nicely, and today they both rely on close to 200 standards, categorized along the following segments:
- Web Layer: HTML, URI, Java, CSS and more.
- Application Layer: HTTP, DNS, FTP, SMTP, POP and more.
- Transport Layer: TCP, UDP, DCCP, RSVP and more.
- Internet Layer: IPv4, IPv6, IPsec, ICMP, IGMP and more.
- Link Layer: ARP, PPP, Ethernet, DSL, ISDN, FDDI and more.
[Derived from: Internet protocol suite, https://en.wikipedia.org/wiki/Internet_protocol_suite.]
These standards are what make the Web work so well. When you are developing Web applications, setting up an infrastructure, or building new products, you interact (directly or indirectly) with these standards, knowing exactly what to expect.
Unfortunately, blockchains don’t have that luxury yet, as each platform is made-up of its own set of technologies and methods to work with it, resulting in a balkanized learning curve and adoption behavior for software developers and architects.
Blockchain Technology is Too Fragmented
Each blockchain has its own set of technology tools, middleware and API’s that applications developers need to contend with. An engineer that knows how to program Bitcoin needs to relearn what they know, in order to develop on other blockchains. For example, exchanges that support multiple cryptocurrencies have to deal with different integration technologies for each implementation.
It is true that each blockchain platform has developed its own technology stacks and interaction methods, but these are vertically integrated to themselves, and for their own ecosystem. In fact, most blockchain platforms don’t share that much in common, resulting in choice lock-ins, lack of interoperability, and potentially dead-ends that are hard to untangle.
The state of collaboration between blockchains is even worse, and plagued by timid efforts for building bridges and lateral co-operative capabilities. One day, it shouldn’t be inconceivable to have technology that crawls entire blockchains, in the same way that search crawlers spider websites to index or categorize vast content.
Of course, many technologies start by being proprietary. What follows is that some of them get adopted widely, and they become de-facto standards. In other cases, groups get together and agree to support a given standard, to serve everybody. Today, not enough of the latter is taking place, although many leading blockchain technologies are hoping to gain enough market klout that would let them become that de-facto choice.
In hindsight, I wished we didn’t give up on Bitcoin APIs so quickly. Two years ago, Bitcoin APIs were all the rage with more than a dozen companies vying for that space, as the entry point to develop Bitcoin applications. Then, the majority of them slowly opted out of that business, or stopped highlighting it as a key offering. Today, we still have several (Bitcoin) API-based offerings from companies like Factom, Tierion, Gem, Colu, BlockCypher, Neuroware, and Coinbase (to name a few). There are benefits to seeing a multitude of APIs take hold and get adopted. Even if some of them overlap in functionality, at least they will point to the need for an eventual standardization.
Bitcoin is making progress at its own pace, via technology releases aimed primarily at solidifying its own ecosystem. Although they have the largest cryptocurrency footprint, that doesn’t negate the need for their technology to also work with other parts of the overall crypto-tech ecosystem.
The Decentralization of the Web Rewires Standards
In order to grow-up, blockchains will eventually need a lot of standards that are vendor and solutions agnostic.
So many areas are ripe for standards developments: smart contracts, tokens, security, storage, messaging, identities, naming, record-keeping, and more.
The Internet and the Web have their standards. Where are the blockchain equivalent?
A standard set of middleware interfaces would insulate participants from the hardest parts of the technology, and expose more succinctly its utilitarian features. Lowering the barriers of entries would empower more developers to enter the blockchain, similar to the roles that HTML, HTTP, URLs and Java played for the Web.
Distributed applications that run on a blockchain infrastructure are architected differently than Web applications that were built for the Web’s architecture.
In a traditional web application, you have client side Javascript code that is run by users inside their browsers and server-side code that is run by a host or company. By contrast, in a distributed application, you have smart logic running on a virtual network of computers (the peer-to-peer network), and client-side code running in a special browser (or client), with the blockchain ledger acting as a shared resource.
With this new type of rewiring, comes the need to also rewire a variety of blockchain standards and technology layers.
Conceivably, blockchains could rely on a number of standards above the Internet’s existing standards, to allow a smooth bridging from one layer to another. That would be a breakthrough.
A blockchain universal stack could resemble something like this. Basically, we would add 3 layers on top of the Internet:
- B-Browsers – Users interact with them, Apps gets plugged here.
- B-Standards – Where Trust-related standards would play, as depicted in my “Interaction Layers” diagram.
- Blockchains – Various blockchain technology and platforms serve functions.
- Internet
- Networks
- Computers
Blockchain browsers (B-Browsers) are going to be important, as we will start to see them in 2017. They will be used to launch blockchain applications, and might look like normal applications we are familiar with, except that they will carry with them some new features that are enabled by blockchain back-ends (instead of databases).
Some of the exciting new blockchain browsers to watch include MetaMask, Blockstack and Mist. These currently have a technical slant, and they are not yet geared at the casual end-user, but they will eventually evolve to become more end-user friendly. A new breed of blockchain applications will come in the form of peer-to-peer browser experiences (e.g. OpenBazaar), while another type will be bolted straight on the current Web, but with a blockchain back-end (e.g. Steemit).
A trust services layer could be that API veneer that homogenizes how we create, move, check states, inspect proofs, follow historical paths, etc.- i.e. perform the functions that blockchains handle well.
Blockchains interoperability is inevitable, but we don’t know exactly yet at what levels, unless we get closer by iterating near the real friction points.
Discrete Efforts Are Not Enough
Nothing great has ever been adopted widely all over the world, unless it was somehow homogenized to make it easily assimilated by the masses.
We need universal tools that no one owns, but that benefit everybody, similar to the Web technologies that liberated the Internet.
Tim Berners-Lee explained why this was so important for the Web: “Had the technology been proprietary, and in my total control, it would probably not have taken off. You can’t propose that something be a universal space and at the same time keep control of it.”
There are promising examples of blockchain related standards, and we need to see more of them.
In the de-facto category, two notable mentions are IPFS (Inter Planetary File System), and an Ethereum-led token issuance standard, labelled ERC20 (which is becoming a de-facto standard in Initial Cryptocurrency Offerings). IPFS is not just focused on the blockchain, although they are a good match, as IPFS has proven to be popular with blockchain applications (e.g. OpenBazaar), where permanent IPFS links get placed into a blockchain transaction.
A few consortiums have also placed blockchain standards on their working agenda, and I enumerated them in my State of Global Blockchain Consortia article.
In the industry-led camp, we will need to follow the ISO/TC 307 Blockchain and electronic distributed ledger technologies technical committee who has stated their serious intentions by partaking in the blockchain standards roll call.
On the enterprise-side, the jury is still out, as vendors place their software in open source repositories, or declare an open standard with a handful of their customers, in the hopes of letting this work become a real standard via sheer adoption, e.g. Hyperledger, Digital Assets, Chain, and R3. Placing software in the open source realm is a good practice, but there is a difference when it starts that way from Day 1 (e.g. Bitcoin, Ethereum) versus doing it a posteriori to gain more market acceptance.
Furthermore, I am a firm believer that private and public blockchains need to also share common standards. It would be inconceivable that the Internet and private Intranets wouldn’t interoperate or interconnect at the very least; yet, we are building private and public blockchain technologies and applications without due regard to the inevitability of that intersection.
Let’s Not Compete on Standards
Yes, I am seriously talking about standards. It is not too early, even if I thought last year that we shouldn’t rush blockchain standards before their time. In 2017, we will need to start seeing serious discussions about universal standards, along with real intentions from industry participants to work together for that aim to materialize.
We need to realize that, in addition to competing in the marketplace, we have to also co-operate on common technical objectives.
In an ideal world, the blockchain field would produce an orderly architecture stack that carries popular standards, commonly used by all of its participants. It would be the resulting mix of de-facto and industry-led standards.
As a side benefit, the existence of standards could also lubricate network effects, a much needed success characteristic. In turn, that would entice new marketplace entrants to focus on their differentiation, instead of building the same overlapping technology pieces.
You don’t typically win by competing on standards, yet you don’t know what is a standard initially, so you might start by competing on everything. A sign of industry maturity will be seen when we hear of companies dropping certain proprietary technologies in favor of cooperative efforts.
That said, we shouldn’t suspend everything in order to just work on standards, in a vacuum. Vendors and blockchain core developers must continue to work on their own technologies while closely monitoring adoption, and always being sensitive about opportunities for industry collaboration. We can’t force standards on the market, but the market will need to embrace standards over time.
If blockchain technologies ignore the eventuality of standards, we are going to see less adoption.
Maybe we should think of the blockchain as a public good utility, and encourage an evolution that is not unlike the Internet’s, in terms of openness and neutrality of access.
Will the collection of blockchain technologies turn into another giant Internet, or will their journey unfold into a messy and fragmented evolution, like the database market, prior to its consolidation?
We have had the blockchain for a while, and it is gaining adoption. New and exciting applications are being built on blockchain technologies. Now is the time to realize that the blockchain’s best future days ahead will depend on how well we expose its capabilities more universally, and more openly. If not now, when?
]]>
