Picking back up the series on what decentralization is good for (part 1, part 2), today I want to focus on one of the most exciting aspects of decentralization: growth.
In this case, when I say "decentralized", what I really mean is "open and non-proprietary". The two often go hand-in-hand.
Ok, so why are open, decentralized systems especially good for growth? When a technology is open (anyone can use, extend, modify, build on) and decentralized (no one party or company is in full control), it has the potential to spread like wildfire, for exactly those reasons. Since it is free to use without restriction, permissionless innovation is possible -- meaning anyone who feels like it can pick it up and run. And because open, decentralized systems reduce platform risk, developers can feel comfortable building on them with less of a risk of getting the carpet pulled out from under them.
When this works, it works really well. Many of the technologies we use every day -- like HTTP, SMTP, WiFi, USB and Bluetooth -- have become ubiquitous precisely because they are open, nonproprietary and decentralized in nature (in addition to being useful!).
Everyone knows that it's safe to build to the Bluetooth standard without platform risk. And what that means is that anyone, no matter what company they are with, or what country they live in, has the potential to grow the platform. This kind of omni-directional growth is really only possible with open, un-owned, decentralized technologies.
Often times, however, a single company drives the development of these open, un-owned, decentralized technologies. For example, the General Transit Feed Specification is on open data format that powers most of the public transit industry. As I have written about before, this standard came to market in large part because of Google's initial efforts, and was then adopted and grown by a large community of others (including our work at OpenPlans back in 2009-2012). Or, to go farther back, we can look at the role that Mozilla/Firefox played in bringing modern web standards (includuing Cascading Style Sheets) to market. Or to today, and Apple's and Google's role in bringing USB-C to market (of course, Apple does not have the best track record on this topic). The point is, it can be difficult for open, nonproprietary, decentralized technologies to take off -- they need some sort of catapult. Historically that has come from companies with some self-interest -- this has been a good thing (generally speaking).
Today, in addition to companies driving open technologies, we have the potential to use cryptocurrencies to drive initial adoption. We seen this work to great effect with Bitcoin, Ethereum and other platforms, and while the specific mechanics are still being explored and experimented with, the basic concept is clear: we can use cryptocurrencies and tokens to bootstrap new open, non-proprietary, decentralized technology platforms. It doesn't work every time -- and we will no doubt continue to see a parade of flameouts -- but when it does work, it has the potential to work in a massive, exceedingly rapid, and global way.
Continuing on the theme of what decentralization is good for, this week I would like to focus on one of the most powerful drivers in the near-term: Platform Risk.
Platform Risk is is the risk that the tech platform that you build your product/app/business/life on will become a critical dependency, will become unreliable, and/or worse, will screw you in the end.
Here is a post from a few years back that details many different flavors of platform risk, many of which are benign, and some of which are malicious. And here are some examples, to make it more concrete:
Microsoft Windows: withholding APIs & documentation from competitors, and blocking distribution
ISPs / Telcos: blocking / throttling certain kinds of traffic (especially video & VoIP)
Google: determining the fate of sites reliant on search traffic and therefore at the whim of the algorithm
Apple / iOS: blocking competitive apps, withholding APIs, taking a 30% cut, to the point that app developers have formed a union
Amazon: competing with third-party sellers and manipulating search results
This is not to say that any of these acts are necessarily illegal, or even immoral. But if you are investing serious time and money -- especially dropping everything to build a business on a platform -- these kinds of risks are of grave concern.
So, what does decentralization have to do with platform risk? When the platform is a protocol (i.e, decentralized) rather than a company (i.e., centralized), the rules of engagement are known up front and can't change on a whim or because of a business decision.
If we think about the original internet protocols (TCP/IP, HTTP, SMTP, FTP, SSL, etc), they are a set of networking, communications and data exchange protocols that ultimate form the platform we know of as the web. While there are certain forms of platform risk on the web (e.g., stability, speed, security), the web on the whole has become a very stable and reliable platform, generally absent of the flavors of risks detailed above.
Cryptonetworks (i.e., public blockchains and cryptocurrencies) combine the architecture of the original internet protocols with the functionality of today's corporate applications platforms (data management & transactions). While there are still major issues to solve before these systems collectively become a mainstream platform, they are gaining major adoption from developers in large part because developers are so keenly aware of platform risk, and see cryptonetworks as a type of platform they can trust.
As an illustrative example, let's compare downloads of the Truffle framework (a popular dev tool for Ethereum):
source: Truffle Dashboard
... with the price of ETH over the same time period:
source: Messari
Developers are the canary in the coal mine when it comes to platforms. And at the moment, they are pointing to the desire for platforms with less inherent risk, more reliability and more trust.
A central concept on the internet is Layering. Each of the protocols in the internet stack talks to the layer directly above and below it -- new protocols can be added as long as they speak the language of their layer. Protocols at one layer can be upgraded so long as they don't break compatibility with the layer above or below it. This architecture maximizes interoperability and allows for a great deal of flexibility. The shape of the layers has been described as an hourglass, like this:
(credit: University of Calgary)
Beyond layering at the protocol level, we have gone on to build layers at the infrastructure and application levels. Infrastructure like AWS and Cloudflare, software libraries like Node, Rails, and jQuery, services like Twilio and Stripe. To build an application today, you do not need to go build a data center (or many of them), think about how to manually process HTTP requests, or write bare-metal adapters to the payments or telecom systems. In the crypto/blockchain space, we are just at the very beginning of establishing layers. I think it's safe to say that today's blockchain landscape looks more like the early days of AOL, Prodigy and Compuserve (standalone, disconnected networks) than like the open, interconnected internet. A major reason for this is the introduction of cryptocurrencies and tokens, which provide a strong incentive -- for now at least -- for starting new networks and maximizing value of existing networks. But, as teams continue to build, and continue to build the same things over and over again, layering seems both inevitable and needed. Within blockchains, layers delineate networking (libp2p as a leading tool), consensus (tendermint, hashcash and others), applications/smart contracts, and perhaps indexing/search (something everyone is doing on their own right now, but that thegraph is looking to solve as a layer). Perhaps the most interesting question is how different blockchain systems may layer together. Cosmos and Polkadot are building systems for interoperable blockchains via a hub-and-spoke model, with shadow assets pegged to outside chains for interoperability. Interledger is attempting to be a more universal cross-ledger (ledger, meaning blockchains and otherwise) protocol, akin to TCP/IP in the core internet stack. How these systems interconnect, and layer atop one another, seems like a fundamental question as we move from the speculative phase to the functional phase. We are just now beginning to get glimpses of it.