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
One of my former colleagues, Rob Marianski, and I used to have a running joke -- we would be building and debugging something, and he'd finally say, "Oh, so you just want me to set just_work = true?".
That was over 10 years ago, but it still gets me every time for some reason. (as an aside, I have always thought justworkequalstrue.com would make a great blog name, and actually bought the domain for Rob a few years back -- still waiting for that first post, Rob...).
But the idea of things "just working", automatically, and without friction, is magical and exciting. I mention it because of where we are today in the crypto/blockchain space. 99% of the attention recently has been on ICO hype and the financial use cases of crypto (fundraising, trading, payments, tokenized assets, etc) -- but I believe we are about to turn the corner and get a taste of what kinds of new online user experiences will become possible because of this technology.
This is where it's going to get fun. just_work = true will be the foundational element of this experience. Here is what I mean, by way of a few examples:
1) Browsers with identity and money built-in: the browsing experience will be directly tied to identity and payments, and any app will be able to natively, frictionlessly, tap into both. Users of Toshi, or Brave, or Metamask, or Blockstack are already getting a taste of it. Because all cryptonetworks are built around
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
One of my former colleagues, Rob Marianski, and I used to have a running joke -- we would be building and debugging something, and he'd finally say, "Oh, so you just want me to set just_work = true?".
That was over 10 years ago, but it still gets me every time for some reason. (as an aside, I have always thought justworkequalstrue.com would make a great blog name, and actually bought the domain for Rob a few years back -- still waiting for that first post, Rob...).
But the idea of things "just working", automatically, and without friction, is magical and exciting. I mention it because of where we are today in the crypto/blockchain space. 99% of the attention recently has been on ICO hype and the financial use cases of crypto (fundraising, trading, payments, tokenized assets, etc) -- but I believe we are about to turn the corner and get a taste of what kinds of new online user experiences will become possible because of this technology.
This is where it's going to get fun. just_work = true will be the foundational element of this experience. Here is what I mean, by way of a few examples:
1) Browsers with identity and money built-in: the browsing experience will be directly tied to identity and payments, and any app will be able to natively, frictionlessly, tap into both. Users of Toshi, or Brave, or Metamask, or Blockstack are already getting a taste of it. Because all cryptonetworks are built around
The Slow Hunch by Nick Grossman
Investing @ USV. Student of cities and the internet.
The Slow Hunch by Nick Grossman
Investing @ USV. Student of cities and the internet.
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.
, and the private key is both your identity and your wallet, when you have a public/private keypair built into the browser, you can do lots of things -- be "logged in" everywhere, control & provision your own data, make seamless and flexible payments and payment arrangements (e.g., subscriptions). Imagine the entire web working as seamlessly as Amazon and Apple do today. As you surf the web, there will be less logging in, fewer passwords to remember, fewer forms to fill out -- it will just work.
2) Portable digital assets: I wrote about this previously, but the interoperability of blockchain-based digital assets is going to be a big thing. Because assets on blockchains are public, open and available, they can exist across many websites and applications. The suit of armor you build in world of warcraft could be used as collateral for getting a blockchain-based mortgage -- maybe that's a ridiculous example, but the idea is that these assets are open, interoperable, and natively portable -- which means things will "just work", across the web, in ways that aren't possible today.
3) Automatic dev / deploy environments: my colleague Albert described a story recently where his son participated in a Solidity hackathon -- the time from setup to deploy was vanishingly short, since all of the deployment infrastructure is part of the open Ethereum network. No need to set up accounts at amazon, heroku, stripe, etc to get started -- just write a contract, buy some ether for gas, and publish it, and you're online. We've never had a development / deployment environment this drop dead simple, and as blockchain dev tools mature further, it will get even easier.
I mention all of the above just as a thought exercise. It is easy for folks in this space to focus on issues like privacy and "freedom" -- and while these things do matter to some users (especially technically-minded power users), I don't believe this technology will unlock mainstream opportunity until we begin to surface the magical capabilities that make everyday users feel like "wow, it just works".
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.
, and the private key is both your identity and your wallet, when you have a public/private keypair built into the browser, you can do lots of things -- be "logged in" everywhere, control & provision your own data, make seamless and flexible payments and payment arrangements (e.g., subscriptions). Imagine the entire web working as seamlessly as Amazon and Apple do today. As you surf the web, there will be less logging in, fewer passwords to remember, fewer forms to fill out -- it will just work.
2) Portable digital assets: I wrote about this previously, but the interoperability of blockchain-based digital assets is going to be a big thing. Because assets on blockchains are public, open and available, they can exist across many websites and applications. The suit of armor you build in world of warcraft could be used as collateral for getting a blockchain-based mortgage -- maybe that's a ridiculous example, but the idea is that these assets are open, interoperable, and natively portable -- which means things will "just work", across the web, in ways that aren't possible today.
3) Automatic dev / deploy environments: my colleague Albert described a story recently where his son participated in a Solidity hackathon -- the time from setup to deploy was vanishingly short, since all of the deployment infrastructure is part of the open Ethereum network. No need to set up accounts at amazon, heroku, stripe, etc to get started -- just write a contract, buy some ether for gas, and publish it, and you're online. We've never had a development / deployment environment this drop dead simple, and as blockchain dev tools mature further, it will get even easier.
I mention all of the above just as a thought exercise. It is easy for folks in this space to focus on issues like privacy and "freedom" -- and while these things do matter to some users (especially technically-minded power users), I don't believe this technology will unlock mainstream opportunity until we begin to surface the magical capabilities that make everyday users feel like "wow, it just works".
