One of the inquiries that has arguably been pivotal to my own studies in blockchain technology is: ultimately, what is its actual utility? Why do we require blockchains for anything, what sorts of services ought to be operated on blockchain-like systems, and why specifically should services be conducted on blockchains rather than just residing on traditional servers? Precisely how much value do blockchains offer: are they entirely necessary, or are they just a nice addition? And, perhaps most crucially, what is going to be the “killer application”?
In recent months, I have devoted considerable time pondering this matter, engaging in discussions with cryptocurrency developers, venture capitalists, and particularly individuals from outside the blockchain realm, such as civil liberties advocates, persons in the finance and payment sectors, or others across various fields. Throughout this process, I have reached several significant and meaningful conclusions.
Firstly, there will be no “killer application” for blockchain technology. The rationale for this is straightforward: the principle of low-hanging fruit. If there existed a particular application for which blockchain technology is vastly superior to any alternatives for a considerable portion of the infrastructure of contemporary society, then people would be vocally discussing it already. This may appear akin to the old economics joke about an economist who finds a twenty-dollar bill on the ground and concludes it must be counterfeit because, otherwise, it would have been picked up, yet in this instance the context is subtly distinct: unlike the dollar bill, where discovery costs are minimal and thus retrieving the bill is sensible even if there is only a 0.01% chance it is authentic, here search costs are notably high, and numerous individuals with billions of dollars of motivation have already been searching. Thus far, there has not been a singular application that anyone has conceived of that has significantly distinguished itself to overshadow everything else on the horizon.
In fact, one might reasonably contend that the closest examples we will ever realize as “killer apps” are exactly those applications that have already been executed, repeated, and sensationalized to the point of exhaustion: censorship resistance for WikiLeaks and Silk Road. Silk Road, the online anonymous drug marketplace that was dismantled by law enforcement in late 2013, processed over $1 billion in sales during its 2.5 years of operation, and while the payment-system-orchestrated blockade against WikiLeaks was in effect, donations via Bitcoin and Litecoin were responsible for the majority of its revenue. In both instances, the need was evident, and the possible economic surplus was substantial – before Bitcoin, individuals had no option but to acquire drugs in person and contribute to WikiLeaks through cash in the mail, and thus Bitcoin offered a considerable convenience boost, leading to swift adoption. However, that scenario is now far less prevalent, and incremental opportunities within blockchain technology are not nearly as easily attainable.
Total and Average Utility
Does this imply, however, that blockchains have reached their peak utility? Most certainly not. They have reached peak necessity, in terms of peak utility per user, but that is not synonymous with peak utility. Although Silk Road was crucial for many of its users, even within the drug-using community, it is not universally indispensable; as much as it puzzles this particular author how ordinary individuals are supposed to make such connections, most people have somehow found “a guy” from whom they can buy their cannabis. Interest in consuming cannabis appears to correlate strongly with ease of access. Consequently, in the broader context, Silk Road has only managed to become relevant to a very specific group of individuals. WikiLeaks shares similarities; the number of people who care about corporate and governmental transparency enough to financially support a controversial organization in its favor is relatively small compared to the overall global population. So what remains? In summary, it is the long tail.
What, then, is the long tail? This is where explaining becomes challenging. I could present a list of applications that fall within this “long tail” of services; however, blockchains are not essential and do not even provide exceptionally robust fundamental advantages for each instance. In each specific scenario, a supporter of either the perspective that “blockchain applications are overrated, it’s the Bitcoin currency that matters” or that “blockchain technology as a whole is ineffective” can reasonably devise a method to execute the plan just as easily on a centralized server, substitute blockchain governance with a legal contract, and apply whatever other modifications to transform the product into something more akin to a traditional system. And on that front, they would be entirely correct: for that particular use case, blockchains are not indispensable. And that is the crux of the matter: those applications are not at the forefront of the distribution, alongside WikiLeaks and Silk Road; if they were, they would have already been established. In the long tail, blockchains are not mandatory; they are advantageous. They are simply marginally superior to the next most suitable tool for the task. Nevertheless, due to the fact that these applications are much more mainstream and can benefit hundreds of millions of users, the overall benefit to society (which can be observed from the area on the prior chart) is significantly larger.
Perhaps the most fitting analogy to this line of logic is to pose the following rhetorical inquiry: what is the killer app of “open source”? Open source has undeniably been a tremendous benefit to society, and it is utilized for millions of software packages worldwide, yet it remains difficult to address the question. The reason aligns closely: there is no killer app, and the catalogue of applications boasts an extensive long tail – essentially, just about every type of software conceivable, with particular focus on lower-level libraries that end up reused across many projects repeatedly and essential cryptographic security libraries.
Blockchains, Redefined… Again
Now, what are the particular advantages of blockchains that justify the long tail’s value? To begin, allow me to provide the current definition that I utilize for what constitutes a blockchain:
A blockchain is a magical computer to which anyone can upload programs and allow the programs to execute autonomously, where the currentand all historical conditions of every application are perpetually visible to the public, and it possesses a robust cryptoeconomic assurance that the programs operating on the chain will persist in executing precisely as delineated by the blockchain protocol.
Be aware that this definition does NOT:
- Utilize finance-related terminology such as “ledger”, “currency” or “transactions”, or any terms tailored for a specific use case
- Refer to any specific consensus mechanism, nor touch upon the technical characteristics of blockchain functionality (aside from stating it’s “cryptoeconomic”, a technical phrase approximately meaning “it’s decentralized, it employs public key cryptography for verification, and it incorporates economic incentives to ensure continuity and prevent regressions or other malfunctions”)
- Impose limitations on any specific kind of state transition function
One aspect that the definition articulates effectively is what a blockchain achieves, conveying it in such a manner that any software developer should possess a clear intuitive understanding of its value proposition. In practice, the programming language utilized by the applications might be quite limiting; for instance, Bitcoin’s language can be interpreted as demanding a sequence of DESTROY COIN: commands followed by a series of CREATE COIN: commands, where scriptpubkey is a constrained mathematical formula and scriptsig must provide a valid assignment to the formula (for example, {x = 5, y = 7} fulfills 2 * x – y = 3), and any endeavor to destroy a nonexistent coin or obliterate a coin without a valid scriptsig for that coin’s scriptpubkey, or to generate a greater coin value than was destroyed, results in an error. Conversely, other programming languages can exhibit much greater expressiveness. It is up to the software developer to evaluate which programming language is suitable for their task, much like a current software developer must decide between Python, C++, NodeJS, and Malbolge.
The definition excellently underscores that blockchains do not aim to introduce any specific ruleset to the world, whether it be a currency with a fixed-supply monetary framework, a name registry featuring a 200-day re-registration duration, a distinct decentralized exchange model, or anything else; rather, they focus on enabling the freedom to create new mechanisms with novel rulesets swiftly and disseminating them. They function as Lego Mindstorms for constructing economic and social entities.
This is the essence of the more tempered viewpoint of “it’s the blockchain that’s thrilling, not the currency” that is widely accepted in mainstream sectors: indeed, it is true that currency is essential for the functioning of cryptoeconomic blockchains (although NOT for blockchain-resilient data frameworks following the Stellar subjective consensus model), yet the currency exists purely as economic infrastructure to incentivize consensus involvement, maintain deposits, and cover transaction fees, rather than serving as the focal point of speculative hype, consumer interest, or excitement.
So, what makes blockchains advantageous? In summary:
- You can store information on them, which is guaranteed to be highly accessible
- You can operate applications on them, ensuring extremely high availability
- You can run applications on them, and be guaranteed extremely high availability well into the future
- You can execute applications on them, and reassure your users that the application logic is genuine and functions as promised
- You can operate applications on them, making your users confident that the application will continue to function even if you lose initiative in maintaining it, you are bribed or coerced to alter the application state, or you develop a profit incentive to change the application state
- You can run applications on them, and provide yourself with the backdoor key if absolutely necessary, BUT impose “constitutional” restrictions on your use of the key – for instance, mandating that a software update undergo a public one-month waiting period before implementation, or at the very least promptly informing users of application changes
- You can run applications on them, and allocate a backdoor key to a specific governance protocol (for example, voting, futarchy, or other complex multicameral parliament configurations), convincing your users that the governance protocol in question genuinely oversees the application
- You can execute applications on them, and those applications can communicate with one another with absolute reliability – even if the foundational platform exhibits only 99.999% reliability
- Multiple users or organizations can operate applications on them, which can interact with each other at incredibly high speeds without needing any network messages, while simultaneously ensuring that each organization retains complete control over its own application
- You can create applications that efficiently leverage data produced by other applications (for instance, merging payment and reputation systems is arguably the most significant advantage here)
All these facets provide indirect value to billions globally, particularly in regions where advanced economic, financial, and social frameworks are often ineffective (although technology usually needs to be amalgamated with political reforms to address many issues). Blockchains excel at delivering these attributes. Their worth is particularly evident in finance, as it arguably represents the most computationally and trust-reliant industry worldwide, yet they also hold significance in various other areas of internet infrastructure. Other architectures that can offer similar properties exist, but they tend to be somewhat to moderately less effective compared to blockchains. Gavin Wood has begun to characterize this ideal computingplatform as “the global computer” – a computer whose state is collectively shared among all users and which a vast community of individuals, open to anyone, collaborates to sustain.
Fundamental Layer Infrastructure
Much like open source, the most significant opportunities for benefits derived from blockchain technology arise from what can be termed “fundamental layer infrastructure” services. This category of infrastructure services is generally characterized by the following attributes:
- Interdependence – numerous additional services closely rely on the fundamental layer service for their functionality
- Significant network effects – there are considerable advantages when extensive groups of individuals (or even everyone) utilize the same service
- High switching costs – it can be challenging for a person to transition from one service to another
It’s important to note that one concern not mentioned is any concept of raw “necessity” or “significance”; some base layers can be considered relatively unimportant (e.g., RSS feeds), while there exist meaningful non-base layers (e.g., food). Base-layer services have been in existence even prior to the inception of civilization; during the so-called “caveman era”, the most vital base-layer service was communication. In somewhat more recent history, key examples included highways, the legal framework, and postal and transit systems. The 20th century introduced telephone networks and financial frameworks, followed by the internet emerging at the turn of the millennium. Presently, however, the emerging base-layer services of the internet predominantly encompass informational elements: internet payment systems, identity verification, domain name systems, certificate authorities, reputation mechanisms, cloud infrastructure, various forms of data feeds, and potentially, in the near future prediction markets.
In a decade, the highly interconnected and interdependent nature of these services may make it more difficult for individuals to change from one system to another than it would be for them to switch the government they reside under – hence, ensuring these services are properly constructed and that their governance does not empower a handful of private entities with excessive authority is paramount. Currently, many of these systems are created in a highly centralized manner, partially due to the failure of the original World Wide Web design to recognize the importance of these services and incorporate defaults – thus, even in contemporary times, numerous websites request users to “sign in with Google” or “sign in with Facebook”, and certificate authorities face issues like this:
“A lone Iranian hacker on Saturday took credit for stealing multiple SSL certificates belonging to some of the largest sites on the Web, such as Google, Microsoft, Skype, and Yahoo.
Initial responses from security analysts were mixed, with some believing the hacker’s assertion, while others were skeptical.
Last week, speculation had centered on a state-sponsored intrusion, possibly financed or executed by the Iranian government, which targeted a certificate reseller associated with U.S.-based Comodo.
On March 23, Comodo confirmed the breach, stating that eight days prior, attackers had acquired nine fraudulent certificates for the login pages of Microsoft’s Hotmail, Google’s Gmail, Internet phone and chat service Skype, and Yahoo Mail. A certificate for Mozilla’s Firefox add-on site was also compromised.”
Why should certificate authorities not be decentralized to at least the extent of an M-of-N system? (Note that the rationale for much broader application of M-of-N is logically distinct from the case for blockchains, though blockchains serve as a suitable platform to implement M-of-N).
Identity
Let’s explore a specific scenario, “identity on the blockchain,” and delve deeper. Generally, what is needed to establish an identity? The simplest answer, which we are already familiar with, is you need a public and private key. The public key is published, becoming your identifier, and every message you transmit is digitally signed using your private key, enabling anyone to confirm that those messages were generated by you (where, from their perspective, “you” signifies “the entity that possesses that particular public key”). Nonetheless, some challenges arise:
- What occurs if your key is compromised, and you must change to a new one?
- What transpires if you misplace your key?
- What if you prefer to identify other users by their names instead of a random 20-byte string of cryptographic data?
- What if you wish to adopt a more sophisticated security approach, such as multisig, instead of relying on a single key?
Let’s attempt to address these challenges one at a time. We can begin with the fourth. A straightforward resolution is this: rather than needing one specific type of cryptographic signature, your public key can function as a program, and a valid signature becomes a string that, when input into the program alongside the message, outputs 1. In theory, any single-key, multi-key, or any other kind of ruleset can be encapsulated within such a framework.
However, this introduces a complication: the public keys may become excessively lengthy. This can be mitigated by storing the actual “public key” in a data repository (for instance, a distributed hash table if we want decentralization) and utilizing the hash of the “public key” as the user’s identifier. This does not inherently necessitate blockchains – although, in modern designs, the fundamentally scalable blockchains are quite similar in structure to DHTs, suggesting that, within the next decade, every kind of decentralized system employed for various purposes may inadvertently or purposefully converge into some type of scalable blockchain.
Now, consider the first issue. We can think of this in terms of the certificate revocation dilemma: if you wish to “revoke” a specific key, how can you ensure that the information reaches everyone who needs awareness of it? This concern can also be resolved through a distributed hash table. However, this leads to the following issue: if you need to revoke a key, what do you replace it with? If your key has been stolen, both you and the intruder possess it, rendering both parties equally unable to assert authority. One potential solution is to maintain three keys; if one is revoked, a signature fromtwo or all of them to endorse the subsequent key. However, this brings about a “nothing at stake” dilemma: if the intruder ultimately succeeds in acquiring all three of your keys from some moment in the past, then they can fabricate a history of designating a new key, continually assigning additional new keys from that point, and your own history no longer holds greater authority. This represents a timestamping issue, and in this context, blockchains can indeed provide assistance.
Regarding the second issue, maintaining multiple keys and reassigning also functions relatively well – and in this scenario, blockchains are not required. Actually, re-assigning isn’t even necessary; through the ingenious application of secret sharing, you can effectively recover from key losses simply by storing your key in “shards”, ensuring that if you lose any single shard, you can always utilize secret sharing mathematics to retrieve it from the others. For the third issue, blockchain-based name registries offer the most straightforward solution.
Nonetheless, in reality, the majority of individuals are not adequately prepared to securely store multiple keys, and incidents are bound to occur, which is where centralized services can be significantly beneficial: assisting people in restoring their accounts in case of an error. In this situation, the blockchain solution is straightforward: social M-of-N backup.
You select eight entities; these could be friends, your employer, a corporation, a nonprofit, or potentially a government in the future, and if anything goes amiss, a combination of five of them can retrieve your key. This notion of social multi-signature backup is arguably one of the most potent mechanisms to employ in any decentralized system design, offering a substantial level of security affordably and without dependence on centralized trust. It is worth noting that blockchain-based identity, particularly utilizing Ethereum’s contract model, simplifies all of this programming: in the name registry, register your name, direct it to a contract, and manage the current main key and backup keys related to the identity as well as the protocol for updating them over time. An identity system that is secure and user-friendly enough for grandma, managed without any singular entity (apart from you!) in control.
Identity is not the sole challenge that blockchains can mitigate. Another element, closely linked with identity, is reputation. Presently, what is regarded as “reputation systems” in contemporary society is invariably either insecure, due to their inability to confirm that an entity has rated another entity after actually interacting with them, or centralized, associating reputation data with a specific platform and having that data remain under the control of that platform. Transitioning from Uber to Lyft means your Uber rating does not transfer.
An ideal decentralized reputation system would comprise two distinct layers: data and evaluation. Data would involve individuals providing independent ratings about others, ratings connected to transactions (for example, with blockchain-based payments, you can establish an open system such that one may only rate merchants if a payment has been made), alongside a variety of other sources, and anyone can implement their own algorithm to assess this data; “light-client friendly” algorithms capable of quickly evaluating a proof of reputation from a specific dataset might emerge as a key area of research (many basic reputation algorithms involve matrix math, which generally has nearly cubic computational complexity in the foundational data, making decentralization challenging). “Zero-knowledge” reputation systems that enable a user to furnish a type of cryptographic certificate demonstrating that they possess at least x reputation points according to a certain metric without disclosing any additional information are also promising.
The scenario with reputation is intriguing as it integrates multiple advantages of blockchain as a platform:
- Its function as a data repository for identity
- Its role as a data repository for reputational records
- Inter-application interoperability (ratings linked to proof of payment, capacity for any algorithm to operate over the same core dataset, etc)
- A promise that the foundational data will remain portable into the future (companies may voluntarily issue a reputation certificate in an exportable form, yet they lack the capacity to pre-commit to maintain that capability in the coming years)
- Utilizing a decentralized platform generally to ensure that the reputation was not tampered with at the point of calculation
However, for all these advantages, there are alternatives: we can rely on Visa and Mastercard to provide cryptographically signed receipts confirming that a particular transaction occurred, we can preserve reputational records on archive.org, we can have servers communicate with one another, we can have private firms stipulate in their terms of service that they agree to be courteous, and so on. All these alternatives are fairly effective, yet they are not nearly as appealing as merely making everything public, running it on “the world computer” and allowing cryptographic verification and proofs to complete the process. A similar rationale can be applied to every other use case.
Reducing Expenses
If the greatest value from blockchain technology arises from the long tail, as this thesis proposes, then it leads to a significant realization: the gain per transaction from employing a blockchain is exceedingly minimal. Consequently, the quest for reducing consensus expenses and enhancing blockchain scalability becomes critical. With centralized solutions, users and businesses have become accustomed to paying effectively $0 per “transaction”; while individuals willing to contribute to Wikileaks might pay a fee of $5 to process their transaction, someone attempting to upload a reputation record may be only inclined to pay a charge of $0.0005.
Thus, the challenge of making consensus more affordable, both in absolute terms (e.g. proof of stake) and in the per-transaction context (e.g. through scalable blockchain algorithms where at most a few hundred nodes process each transaction), is critically important. Furthermore, blockchain creators should remember that the past four decades of software engineering has been characterized by a trend towards increasingly inefficient programming languages and paradigms solely because they permit developers to be less knowledgeable and complacent. Similarly, efforts should be made to craft blockchain algorithms that operate under the assumption that developers may not be particularly savvy or discerning regarding what they include on the blockchain and what should be omitted – though a well-structured system of transaction fees will probably encourage developers to learn the crucial aspects through firsthand experience.
Thus, there is considerable optimism for a future that could, to a significant extent, be more decentralized; however, the era of easy profits has concluded. Now is the moment for a considerably more challenging and prolonged effort of examining the tangible world, and understanding how the advancements we’ve made can truly enhance society. During this phase, it is likely we will encounter an inflection point, where most examples of “blockchain for X” will not originate from blockchain advocates seeking meaningful applications, stumbling upon X, and attempting to implement it, but rather from X advocates who perceive blockchains as a quite beneficial means for addressing certain aspects of X. Whether X pertains to the Internet of Things, financial frameworks for developing nations, grassroots social, cultural, and economic institutions, improved data aggregation and security for healthcare, or merely contentious charities and uncensorable marketplaces. In the latter two instances, the inflection point may have already been reached; many of the initial group of blockchain advocates became interested in blockchain due to political motivations. Once it manifests in other scenarios, however, we will genuinely understand that it has entered mainstream consciousness and that significant humanitarian advancements are soon to follow.
Moreover, we will likely learn that the notion of “the blockchain community” will lose its significance as any sort of quasi-political movement in its own right; if any label applies at all, “crypto 2.0” is likely to be the most justifiable one. The rationale is akin to why we do not have a notion of “the distributed hash table community”, and while “the database community” exists, it essentially comprises computer scientists who specialize in databases: blockchains represent merely one technology, and ultimately the most significant advancements can only be realized by integrating with a comprehensive array of other decentralized (and decentralization-friendly) technologies: reputation systems, distributed hash tables, “peer-to-peer hypermedia platforms“, distributed messaging protocols, prediction markets, zero-knowledge proofs, and potentially many more yet to be uncovered.