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:
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:
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):
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:
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.
In June, the SEC gave some of its most concrete guidance to date that cryptoassets can start out as centralized projects, possibly initially sold under securities laws, and eventually become "decentralized" and thus no longer sponsor-controlled, and no longer sold or transferred under securities laws. It makes sense that a decentralized protocol does not fit the definition of a security. There's not a clear single issue or promoter (for purposes of reporting, etc); tokens are often generated on an ongoing basis (which would constitute a "continuous offering" and related registration requirements); tokens are generated on a fully peer-to-peer basis in the protocol (potentially implicating independent nodes as transfer agents or broker dealers, or requiring those as middlemen); not to mention how all of the above are complicated by new issues like forking. Of course, all of this leaves some open questions on what exactly constitutes decentralization, but I am confident we will work through those to come to a usable definition. For example, "is the network forkable" is one simple (but incomplete) heuristic. Another is: "would the network continue operating if the initial sponsor went out of business". This second one is perhaps the most concrete, and I believe the the net effect of the SEC guidance is that we will begin to see protocol development companies (the initial "sponsors" of cryptonetworks) set a course to intentionally self-destruct. How this is done, exactly, will remain to be seen. Already we have seen a company / foundation split as one way of setting the protocol in the hands of a long-term custodian that is not the initial sponsor. Some projects may bake self-destruction into their initial charter (and any associated coin offerings or distributions); others may make self-destruction part of the protocol software development roadmap. But regardless of mechanism, I believe many projects will begin to contemplate their "path to decentralization" -- that is the takeaway from the SEC guidance, and a self-destructing company (leaving behind only an autonomous, decentralized protocol) is the logical result. This is going to be a messy process. For example, the recent launch of the EOS network demonstrated some of the challenges of handing off a protocol and network to the community. But luckily we will get to see many more real-world experiments as projects move out of the fundraising phase and into the build->ship->decentralize phase.
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):
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:
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.
In June, the SEC gave some of its most concrete guidance to date that cryptoassets can start out as centralized projects, possibly initially sold under securities laws, and eventually become "decentralized" and thus no longer sponsor-controlled, and no longer sold or transferred under securities laws. It makes sense that a decentralized protocol does not fit the definition of a security. There's not a clear single issue or promoter (for purposes of reporting, etc); tokens are often generated on an ongoing basis (which would constitute a "continuous offering" and related registration requirements); tokens are generated on a fully peer-to-peer basis in the protocol (potentially implicating independent nodes as transfer agents or broker dealers, or requiring those as middlemen); not to mention how all of the above are complicated by new issues like forking. Of course, all of this leaves some open questions on what exactly constitutes decentralization, but I am confident we will work through those to come to a usable definition. For example, "is the network forkable" is one simple (but incomplete) heuristic. Another is: "would the network continue operating if the initial sponsor went out of business". This second one is perhaps the most concrete, and I believe the the net effect of the SEC guidance is that we will begin to see protocol development companies (the initial "sponsors" of cryptonetworks) set a course to intentionally self-destruct. How this is done, exactly, will remain to be seen. Already we have seen a company / foundation split as one way of setting the protocol in the hands of a long-term custodian that is not the initial sponsor. Some projects may bake self-destruction into their initial charter (and any associated coin offerings or distributions); others may make self-destruction part of the protocol software development roadmap. But regardless of mechanism, I believe many projects will begin to contemplate their "path to decentralization" -- that is the takeaway from the SEC guidance, and a self-destructing company (leaving behind only an autonomous, decentralized protocol) is the logical result. This is going to be a messy process. For example, the recent launch of the EOS network demonstrated some of the challenges of handing off a protocol and network to the community. But luckily we will get to see many more real-world experiments as projects move out of the fundraising phase and into the build->ship->decentralize phase.
