Visions, Part 1: The Value of Blockchain Technology

One of the questions that has perhaps been central to my own research in blockchain technology is: ultimately, what is it even useful for? Why do we need blockchains for anything, what kinds of services should be run on blockchain-like architectures, and why specifically should services be run on blockchains instead of just living on plain old servers? Exactly how much value do blockchains provide: are they absolutely essential, or are they just nice to have? And, perhaps most importantly of all, what is the “killer app” going to be?

Over the last few months, I have spent a lot of time thinking about this issue, discussing it with cryptocurrency developers, venture capital firms, and particularly people from outside the blockchain space, whether civil liberties activists, people in the finance and payments industry or anywhere else. In the process of this, I have come to a number of important, and meaningful, conclusions.

First, there will be no “killer app” for blockchain technology. The reason for this is simple: the doctrine of low-hanging fruit. If there existed some particular application for which blockchain technology is massively superior to anything else for a significant portion of the infrastructure of modern society, then people would be loudly talking about it already. This may seem like the old economics joke about an economist finding a twenty dollar bill on the ground and concluding it must be fake because otherwise it would already have been taken, but in this case the situation is subtly different: unlike the dollar bill, where search costs are low and so picking up the bill makes sense even if there is only a 0.01% chance it is real, here search costs are very high, and plenty of people with billions of dollars of incentive have already been searching. And so far, there has been no single application that anyone has come up with that has seriously stood out to dominate everything else on the horizon.

In fact, one can quite reasonably argue that the closest things that we will ever have to “killer apps” are precisely those apps that have already been done and recited and sensationalized ad nauseam: censorship resistance for Wikileaks and Silk Road. Silk Road, the online anonymous drug marketplace that was shut down by law enforcement in late 2013, processed over $1 billion in sales during its 2.5 years of operations, and while the payment-system-orchestrated blockade against Wikileaks was in progress, Bitcoin and Litecoin donations were responsible for the bulk of its revenue. In both cases the need was clear and the potential economic surplus was very high – before Bitcoin, you would have no choice but to buy the drugs in person and donate to Wikileaks by cash-in-the-mail, and so Bitcoin provided a massive convenience gain and thus the opportunity was snatched up almost instantly. Now, however, that is much less the case, and marginal opportunities in blockchain technology are not nearly such easy grabs.

Total and Average Utility

Does this mean, however, that blockchains have hit their peak utility? Most certainly not. They have hit peak necessity, in the sense of peak utility per user, but that is not the same thing as peak utility. Although Silk Road was indispensable for many of the people that used it, even among the drug-using community it’s not indispensable in general; as much as it befuddles this particular author how ordinary individuals are supposed to get such connections, most people have somehow found “a guy” that they know that they can purchase their weed from. Interest in smoking weed at all seems to strongly correllate with having easy access to it. Hence, in the grand scheme of things, Silk Road has only had a chance to become relevant to a very niche group of people. Wikileaks is similar; the set of people who care about corporate and governmental transparency strongly enough to donate money to a controversial organization in support of it is not very large compared to the entire population of the world. So what’s left? In short, the long tail.

So what is the long tail? This is where it gets hard to explain. I could provide a list of applications that are included in this “long tail” of applications; however, blockchains are not indispensable, and do not even offer extremely strong fundamental advantages for each one. For each individual case, an advocate of either the “blockchain applications are overrated, it’s the Bitcoin currency that matters” or the “blockchain tech as a whole is useless” position can quite reasonably come up with a way to implement the scheme just as easily on a centralized server, replace blockchain governance with a legal contract, and apply whatever other replacements to turn the product into something much more similar to a traditional system. And on that point, they would be completely correct: for that particular use case, blockchains are not indispensable. And that’s the whole point: those applications are not at the top of the distribution, up there with Wikileaks and Silk Road; if they were, they would have been implemented already. In the long tail, blockchains are not necessary; they are convenient. They are simply marginally better than the next available tool for the job. And yet, because these applications are much more mainstream, and can benefit hundreds of millions of users, the total gain to society (which can be seen from the area on the above chart) is much larger.

Perhaps the best analogy to this line of reasoning is to ask the following rhetorical question: what is the killer app of “open source”? Open source has clearly been a very good thing for society, and it is being used for millions of software packages around the world, but nevertheless it is still hard to answer the question. And the reason is the same: there is no killer app, and the list of applications has a very very long tail – basically, just about every kind of software imaginable, with particular emphasis on lower-level libraries that end up reused by millions of projects many times over and critical cryptographic security libraries.

Blockchains, Redefined… Again

Now, what are the specific benefits of blockchains that make the long tail worthwhile? To start off, let me provide the current description that I use of what a blockchain is:

A blockchain is a magic computer that anyone can upload programs to and leave the programs to self-execute, where the current and all previous states of every program are always publicly visible, and which carries a very strong cryptoeconomically secured guarantee that programs running on the chain will continue to execute in exactly the way that the blockchain protocol specifies.

Notice that this definition does NOT:

• Use financially-charged terms like “ledger”, “money” or “transactions”, or indeed any terms geared toward a particular use case
• Mention any particular consensus algorithm, or indeed mention anything about the technical properties of how a blockchain works (except for the fact that it’s “cryptoeconomic”, a technical term roughly meaning “it’s decentralized, it uses public key cryptography for authentication, and it uses economic incentives to ensure that it keeps going and doesn’t go back in time or incur any other glitch”)
• Make a restriction to any particular type of state transition function

The one thing that the definition does well is explain what a blockchain does, and it explains it in such a way that any software developer will be able to fairly clearly have at least an intuitive grasp of its value proposition. Now, in practice, sometimes the programming language that the programs run in is very restrictive; Bitcoin’s language can be seen as requiring a sequence of DESTROY COIN: <txid> <index> <scriptsig> statements followed by a sequence of CREATE COIN: <scriptpubkey> <value> statements, where scriptpubkey is a restricted mathematical formula, scriptsig must be a satisfying variable assignment to the formula (eg. {x = 5, y = 7} satisfies 2 * x – y = 3), and an attempt to destroy a nonexistent coin or destroy a coin without supplying a valid scriptsig for that coin’s scriptpubkey, or an attempt to create more coin value than you destroyed, returns an error. Other programming languages, on the other hand, can be much more expressive. It’s up to the software developer to analyze what programming language is right for their task, much like it is a software developer’s task today to decide between python, C++, NodeJS and Malbolge.

The one thing that the definition emphasizes extremely well is that blockchains are not about bringing to the world any one particular ruleset, whether it’s a currency with a fixed-supply monetary policy, a name registry with a 200-day re-registration time, a particular decentralized exchange design or whatever else; rather, they’re about creating the freedom to create a new mechanism with a new ruleset extremely quickly and pushing it out. They’re Lego Mindstorms for building economic and social institutions.

This is the core of the more moderate version of the “it’s the blockchain that’s exciting, not the currency” position that is so prevalent in mainstream industry: it is indeed true that currency is necessary to make cryptoeconomic blockchains work (although NOT blockchain-like data structures following the Stellar subjective consensus model), but the currency is there simply as economic plumbing to incentivize consensus participation, hold deposits and pay transaction fees, not as the center-stage point of speculative mania, consumer interest and excitement.

Now, why are blockchains useful? To summarize:

• You can store data on them and that data is guaranteed to have a very high degree of availability
• You can run applications on them and be guaranteed an extremely high uptime
• You can run applications on them, and be guaranteed an extremely high uptime going very far into the future
• You can run applications on them, and convince your users that the application’s logic is honest and is doing what you are advertising that it does
• You can run applications on them, and convince your users that your application will remain working even if you lose interest in maintaining it, you are bribed or threatened to manipulate the application state in some way, or you acquire a profit motive to manipulate the application state in some way
• You can run applications on them, and give yourself the backdoor key if it is absolutely necessary, BUT put “constitutional” limiations on your use of the key – for example, requiring a software update to pass through a public one-month waiting period before it can be introduced, or at the very least immediately notifying users of application updates
• You can run applications on them, and give a backdoor key to a particular governance algorithm (eg. voting, futarchy, some complicated multicameral parliament architecture), and convince your users that the particular governance algorithm in question is actually in control of the application
• You can run applications on them, and those applications can talk to each other with 100% reliability – even if the underlying platform has only 99.999% reliability
• Multiple users or companies can run applications on them, and those applications can interact with each other at extremely high speed without requiring any network messages, while at the same time ensuring that each company has total control over its own application
• You can build applications that very easily and efficiently take advantage of the data produced by other applications (eg. combining payments and reputation systems is perhaps the largest gain here)

All of those things are valuable indirectly to billions of people around the world, potentially particularly in regions of the world where highly developed economic, financial and social infrastructure currently simply does not work at all (though technology will often need to be combined with political reforms to solve many of the problems), and blockchains are good at providing these properties. They are particularly obviously valuable in finance, as finance is perhaps the most simultaneously computationally and trust-intensive industry in the world, but they are also valuable in many other spots in internet infrastructure. There do exist other architectures that can also provide these properties, but they are slightly to moderately less good than blockchains are. Gavin Wood has started describing this ideal computing platform as “the world computer” – a computer the state of which is shared among everyone and which a very large group of people, which anyone is free to join, are involved in maintaining.

Base Layer Infrastructure

Like open source, by far the largest opportunity for gains out of blockchain technology are out of what can be called “base-layer infrastructure” services. Base-layer infrastructure services, as a general category, are characterized by the following properties:

• Dependency – there exist many other services that intimately depend on the base-layer service for functionality
• High network effects – there are substantial benefits from very large groups of people (or even everyone) using the same service
• High switching costs – it is difficult for an individual to switch from one service to the other

Note that one concern that is not in there is any notion of raw “necessity” or “importance”; there can be fairly unimportant base layers (eg. RSS feeds) and important non-base-layers (eg. food). Base-layer services have existed ever since even before the dawn of civilization; in the so-called “caveman days” the single most important base-layer service of all was language. In somewhat more recent times, the primary examples became roads, the legal system and postal and transportation systems, in the 20th century we added telephone networks and financial systems, and at the end of the millennium emerged the internet. Now, however, the new base-layer services of the internet are almost entirely informational: internet payment systems, identity, domain name systems, certificate authorities, reputation systems, cloud computing, various kinds of data feeds, and perhaps in the near future prediction markets.

In ten years time, the highly networked and interdependent nature of these services may make it such that it is harder for individuals to switch from one system to another than it is for them to even switch which government they are living under – and that means that making sure that these services are built correctly and that their governance process does not put a few private entities in positions of extreme power is of utmost importance. Right now, many of these systems are built in a highly centralized fashion, and this is in part simply due to the fact that the original design of the World Wide Web failed to realize the importance of these services and include defaults – and so, even today, most websites ask you to “sign in with Google” or “sign in with Facebook”, and certificate authorities run into problems like this:

“A solo Iranian hacker on Saturday claimed responsibility for stealing multiple SSL certificates belonging to some of the Web’s biggest sites, including Google, Microsoft, Skype and Yahoo.

Early reaction from security experts was mixed, with some believing the hacker’s claim, while others were dubious.

Last week, conjecture had focused on a state-sponsored attack, perhaps funded or conducted by the Iranian government, that hacked a certificate reseller affiliated with U.S.-based Comodo.

On March 23, Comodo acknowledged the attack, saying that eight days earlier, hackers had obtained nine bogus certificates for the log-on sites of Microsoft’s Hotmail, Google’s Gmail, the Internet phone and chat service Skype and Yahoo Mail. A certificate for Mozilla’s Firefox add-on site was also acquired.”

Why shouldn’t certificate authorities be decentralized at least to the point of an M-of-N system again? (Note that the case for much more widespread use of M-of-N is logically separable from the case for blockchains, but blockchains happen to be a good platform to run M-of-N on).

Identity

Let us take a particular use case, “identity on the blockchain”, and run with it. In general, what do you need in order to have an identity? The simplest answer is one we already know: you need to have a public and private key. You publish the public key, which becomes your ID, and you digitally sign every message you send with your private key, allowing anyone to verify that those messages were produced by you (where, from their point of view, “you” means “the entity that holds that particular public key”). However, there are a few challenges:

1. What happens if your key gets stolen, and you need to switch to a new one?
2. What happens if you lose your key?
3. What if you want to refer to other users by their names, and not just a random 20-byte string of cryptographic data?
4. What if you want to use a more advanced approach for security such as multisig, and not just a single key?

Let us try solving these challenges one-by-one. We can start off with the fourth. A simple solution is this: instead of requiring one particular cryptographic signature type, your public key becomes a program, and a valid signature becomes a string that, when fed into the program together with the message, returns 1. Theoretically, any single-key, multi-key or whatever other kind of ruleset can be encoded into such a paradigm.

However, this has a problem: the public keys will get too long. We can solve this by putting the actual “public key” into some data store (eg. a distributed hash table if we want decentralization) and using the hash of the “public key” as the user’s ID. This does not yet require blockchains – although, in the latest designs, in the limit scalable blockchains are really not that different in design from DHTs and so it is entirely possible that, in ten years time, every kind of decentralized system used for anything will accidentally or intentionally converge into some kind of scalable blockchain.

Now, consider the first problem. We can think of this as the certificate revocation problem: if you want to “revoke” a particular key, how do you ensure that it gets around to everyone who needs to see it? This by itself can once again be solved by a distributed hash table. However, this leads to the next problem: if you want to revoke a key, what do you replace it with? If your key is stolen, you and the attacker both have it, and so neither of you can be convincingly more authoritative. One solution is to have three keys, and then if one gets revoked then require a signature from two or all of them to approve the next key. But this leads to a “nothing at stake” problem: if the attacker eventually manages to steal all three of your keys from some point in history, then they can simulate a history of assigning a new key, assigning further new keys from there, and your own history is no longer more authoritative. This is a timestamping problem, and so here blockchains can actually help.

For the second problem, holding multiple keys and reassigning also works reasonably well – and here, blockchains are not needed. In fact, you do not need to re-assign; with clever use of secret sharing you can actually recover from key losses simply by keeping your key in “shards”, such that if you lose any single shard you can always use secret sharing math to simply recover it from the others. For the third problem, blockchain-based name registries are the simplest solution.

However, in practice most people are not well-equipped to securely store multiple keys, and there are always going to be mishaps, and often centralized services play an important role: helping people get their accounts back in the event of a mistake. In this case, the blockchain-based solution is simple: social M-of-N backup.

You pick eight entities; they may be your friends, your employer, some corporation, nonprofit or even in the future a government, and if anything goes wrong a combination of five of them can recover your key. This concept of social multi-signature backup is perhaps one of the most powerful mechanisms to use in any kind of decentralized system design, and provides a very high amount of security very cheaply and without relying on centralized trust. Note that blockchain-based identity, particularly with Ethereum’s contract model, makes all of this very easy to program: in the name registry, register your name and point it at a contract, and have that contract maintain the current main key and backup keys associated with the identity as well as the logic for updating them over time. An identity system, safe and easy-to-use enough for grandma, done without any individual entity (except for you!) in control.

Identity is not the only problem that blockchains can alleviate. Another component, intimately tied up with identity, is reputation. Currently, what passes for “reputation systems” in the modern world are invariably either insecure, due to their inability to ensure that an entity rating another entity actually interacted with them, or centralized, tying reputation data to a particular platform and having the reputation data exist under that platform’s control. When you switch from Uber to Lyft, your Uber rating does not carry over.

A decentralized reputation system would ideally consist of two separate layers: data and evaluation. Data would consist of individuals making independent ratings about others, ratings tied to transactions (eg. with blockchain-based payments one can create an open system such that you can only give merchants a rating if you actually pay them), and a collection of other sources, and anyone can run their own algorithm to evaluate their data; “light-client friendly” algorithms that can evaluate a proof of reputation from a particular dataset quickly may become an important research area (many naive reputation algorithms involve matrix math, which has nearly cubic computational complexity in the underlying data and so is hard to decentralize). “Zero-knowledge” reputation systems that allow a user to provide some kind of cryptographic certificate proving that they have at least x reputation points according to a particular metric without revealing anything else are also promising.

The case of reputation is interesting because it combines together multiple benefits of the blockchain as a platform:

• Its use as a data store for identity
• Its use as a data store for reputational records
• Inter-application interoperability (ratings tied to proof of payment, ability for any algorithm to work over the same underlying set of data, etc)
• A guarantee that the underlying data will be portable going into the future (companies may voluntarily provide a reputation certificate in an exportable format, but they have no way to pre-commit to continuing to have that functionality going into the future)
• The use of a decentralized platform more generally to guarantee that the reputation wasn’t manipulated at the point of calculation

Now, for all of these benefits, there are substitutes: we can trust Visa and Mastercard to provide cryptographically signed receipts that a particular transaction took place, we can store reputational records on archive.org, we can have servers talk to each other, we can have private companies specify in their terms of service that they agree to be nice, and so forth. All of these options are reasonably effective, but they are not nearly as nice as simply putting everything out into the open, running it on “the world computer” and letting cryptographic verification and proofs do the work. And a similar argument can be made for every other use case.

Cutting Costs

If the largest value from blockchain technology comes at the long tail, as this thesis suggests, then that leads to an important conclusion: the per-transaction gain from using a blockchain is very small. Hence, the problem of cutting costs of consensus and increasing blockchain scalability becomes paramount. With centralized solutions, users and businesses are used to paying essentially $0 per “transaction”; although individuals looking to donate to Wikileaks may be willing to pay even a fee of $5 to get their transaction through, someone trying to upload a reputation record may well only be willing to pay a fee of $0.0005.

Hence, the problem of making consensus cheaper, both in the absolute sense (ie. proof of stake) and in the per-transaction sense (ie. through scalable blockchain algorithms where at most a few hundred nodes process each transaction), is absolutely paramount. Additionally, blockchain developers should keep in mind that the last forty years of software development has been a history of moving to progressively less and less efficient programming languages and paradigms solely because they allow developers to be less experienced and lazier, and similarly work to design blockchain algorithms that work around the principle that developers are really not going to be all that smart and judicious about what they put on the blockchain and what they keep off – though a well-designed system of transaction fees will likely lead to developers naturally learning most of the important points through personal experience.

Hence, there is substantial hope for a future that can be, to a substantial degree, more decentralized; however, the days of easy gains are over. Now is the time for a much harder, and longer, slog of looking into the real world, and seeing how the technologies that we have built can actually benefit the world. During this stage, we will likely discover that at some point we will hit an inflection point, where most instances of “blockchain for X” will be made not by blockchain enthusiasts looking for something useful to do, coming upon X, and trying to do it, but rather by X enthusiasts who look at blockchains and realize that they are a fairly useful tool for doing some part of X. Whether X is internet of things, financial infrastructure for the developing world, bottom-up social, cultural and economic institutions, better data aggregation and protection for healthcare, or simply controversial charities and uncensorable marketplaces. In the latter two cases, the inflection point has likely already hit; many of the original crowd of blockchain enthusiasts became blockchain enthusiasts because of the politics. Once it hits in the other cases, however, then we will truly know that it has gone mainstream, and that the largest humanitarian gains are soon to come.

Additionally, we will likely discover that the concept of “the blockchain community” will cease to be meaningful as any kind of quasi-political movement in its own right; if any label applies at all, “crypto 2.0” is likely to be the most defensible one. The reason is similar to why we do not have a concept of “the distributed hash table community”, and “the database community”, while existent, is really simply a set of computer scientists who happen to specialize in databases: blockchains are just one technology, and so ultimately the greatest progress can only be achieved by working on combination with a whole set of other set of decentralized (and decentralization-friendly) technologies: reputation systems, distributed hash tables, “peer-to-peer hypermedia platforms“, distributed messaging protocols, prediction markets, zero-knowledge proofs and likely many more that have not yet been discovered.