By Seha Islam in Internet — Jul 31, 2022

Unchaining the Web

Blockchains cannot give us the Web we want and we should explore alternative protocols.

Photo by Kaley Dykstra / Unsplash

Ain't no mountain high enough, ain't no valley low enough, ain't no river wide enough.

— Marvin Gaye on the storage, latency, and throughput limitations of blockchains

The indexed Web currently contains 3.83 billion pages [1] that serve five billion people [2], with an expected data footprint of 175 zettabytes by 2025 [3]. Every second, we transmit over 150 TB of data, including over 3,000,000 emails, 100,000 Google searches, 10,000 tweets, and 1,000 Instagram posts [4].

Meanwhile, the entire Bitcoin blockchain is 420 GB [5], and an archival node of Ethereum is "units of terabytes" [6] in size.

To some, it is intuitive that blockchains cannot meet the data storage needs of the Web and that the protocols and applications based on blockchains cannot serve the processing needs of everything we want to do online at the volume and speed we want to do those things.

To others, the indefinite optimists, as Peter Thiel would call them [7], a web built on blockchains is still a possibility. Yet, blockchain-based protocols cannot give us the Web we want, even in the most optimistic scenario. So, instead, we should explore alternative protocols to serve as the foundation of the Web.

The remainder of this article covers:

the Web we want,
the blockchain,
the alternative, and
unchaining the Web.

We must defend our own privacy if we expect to have any. We must come together and create systems which allow anonymous transactions to take place. People have been defending their own privacy for centuries with whispers, darkness, envelopes, closed doors, secret handshakes, and couriers. The technologies of the past did not allow for strong privacy, but electronic technologies do.

— Eric Hughes on the Web he wants in A Cypherpunk's Manifesto [8]

The Web we want

The Web we want is:

Private: Privacy is the ability to selectively reveal information about oneself to others, whether it's another person, a vendor, or an application. Many online applications we use today collect excessive information about us. They monetize our data to bring their products to market and frequently leak our information, compromising our identities, contact information, and even physical location. The Web we want minimizes the personal data required to function and empowers individuals to disclose only the information they wish to reveal to others online. Minimizing private data collection can protect individuals, businesses, and governments from threats they may face due to cybersecurity breaches. The recent leak of one billion individuals' data in China [9] illustrates how dangerous the world can become without privacy.
Verifiable: Verifiability is the ability to ascertain the validity of some information and ensure that it has not been tampered with by unauthorized parties. Today's popular applications are full of fake accounts, which can disseminate information from sources that we cannot verify. Because most of these applications are closed source, we cannot verify the algorithms that serve us the information either. Instead, centralized parties judgmentally "verify" accounts using "checkmarks," which they can revoke at will. The web we want empowers individuals to verify the protocols, applications, and information shared in those applications while encouraging them to communicate with others in a verifiable manner.
Censorship resistant: Censorship resistance is the ability to avoid restrictions on participation in a protocol. Centralized services, whether because of the authoritarian regimes in which they reside or their policies, unapologetically censor their users at increasing rates. Some open protocols, including blockchain-based ones, have faced numerous denial of service attacks that prevent all users from participating in the protocol. The web we want does not allow any one party to prevent other parties from participating in a protocol and empowers its users to identify and defend against denial of service attacks.

In terms of its performance, the Web we want has:

High availability
High throughput
Low latency
Low cost

Today's web applications are highly performant but lack privacy, verifiability, and censorship resistance. As long as they're in the hands of a few centralized authorities, the Web today is not the web we want.

The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

— Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System [10]

The blockchain

A blockchain is an append-only data structure (a chain of sequenced blocks) containing transaction data, ranging from the movement of funds to more complex transactions embedded in "smart contracts."

A blockchain-based protocol (e.g., Bitcoin, Ethereum) is a set of communication instructions and verification rules based on these append-only data structures, which allow the protocol users to establish a common global state.

A node on a network that uses a blockchain-based protocol needs to have:

Enough data storage to store everyone's data, all the time, sequentially, since inception and
Enough computing power to process everyone's data, all the time, sequentially, since inception.

Further, each node needs to store and process the necessary data with:

High enough throughput to accommodate the volume and
Low enough latency to accommodate the speed at which we interact online.

Storing only cryptographic hashes of data on blockchains instead of the underlying raw data and processing proofs of each computation on blockchains instead of the underlying computations does not alter the need for everyone to store and process that data all the time, sequentially, since inception.

As long as there are non-zero storage and processing costs required for the things we want to do online, it is infeasible to use a data structure that requires everyone to agree on a common global state of everything we do online. Then, we should consider the limited set of applications where it would make sense for society to bear the costs of a blockchain's inefficiencies. One such application is global, digital, sound money, i.e., Bitcoin. It makes sense to incur this cost for Bitcoin because we have not stumbled on a more efficient way to ensure global, digital, sound money exists. All nodes on the Bitcoin network must store and process everyone's transactions, all the time, sequentially, since inception, to establish account balances and validate the total money supply. The storage, computation, throughput, and latency requirements are tolerable enough to subject ourselves to the limitations of a blockchain for this one application as it has the chance to serve the role of money with a total addressable market of $420 trillion or more [11, 12].

Satoshi started with a particular problem and settled on a blockchain as a means to solve that problem. Thanks to his work, we now have global, digital, sound money. But, what application besides money needs a blockchain to be private, verifiable, and censorship-resistant? The use cases to date are typically new forms of limited purpose monies or securities issued without being subject to the necessary disclosures. Putting questions of ethics and economic viability aside, these applications cannot give us the Web we want.

Governments are good at cutting off the heads of centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.

— Satoshi Nakamoto on centralized vs. p2p protocols [13]

The alternative

With a blockchain-based protocol, the following limitations apply to nodes so that they may determine the common global state, i.e., consensus:

Everyone must store and process the data: Every node using a blockchain-based protocol must store and process data. If an application doesn't need every user to store and process data, it shouldn't be on a blockchain. If not every user needs to store and process data (or hashes, pointers, proofs of the underlying data), it also does not need to be built using peer-to-peer (p2p) protocols, a superset of blockchain-based protocols.
Everyone's data must be stored and processed: Nodes using a blockchain-based protocol must store and process data for every user. "General purpose" blockchains like Ethereum are further limited in their scalability as users of one application must also incur the burden of storing and processing data for users of all other applications on the protocol. It is unlikely that any application needs this level of storage and processing.
Data must be stored and processed all the time: Nodes using a blockchain-based protocol must store and process data all the time to verify the most current global state. Since everyone must store and process everyone else's data, a node cannot stay in sync with the consensus reached every block and serve other users unless it is storing and processing data all the time. In applications that don't have an inherent double-spend problem, there's no need to introduce a double-spend problem, and users can verify information without the need for an always-on node.
Data must be stored and processed sequentially: Nodes using a blockchain-based protocol must store and process all data sequentially. The reason for doing so is again to prevent the double-spend problem per the protocols' rules. Non-monetary applications don't need to be constrained tools specific to solving monetary issues if they are setting out to provide solutions to other problems.
Data must be stored and processed since inception: Nodes using a blockchain-based protocol must store and process all data since inception. In most non-monetary applications, this is too high of a burden to bear. Furthermore, as time goes on, the ability to scale applications on blockchain-based protocols worsens.

It would be prudent for every user of a global, digital, sound money to store and process all data (i.e., run a full node) such that they don't need to trust another node to verify their balance or the total money supply. Money is an application that everyone in the world needs to use multiple times every single day.

If an application does not require any of the above, it doesn't need to be burdened by a blockchain, and alternative protocols should be developed and used.

An example of a protocol that embodies an alternative to build the Web we want is nostr (Notes and Other Stuff Transmitted by Relays) [14], initially developed by fiatjaf.

With nostr:

Only some users (i.e., relays) must store and process data: Instead of everyone storing the data, only relays offer to store data. If a relay attempts to censor a user, the user can choose a different relay or use multiple relays at any time.
Only some users' data can be stored and processed by any given relay: Instead of storing everyone's data, every relay is free to store only the data it wishes to store. Additionally, a user can run a relay that only serves their data.
No relay needs to store and process data all the time: Multiple relays can store data such that no single relay has to store and process data all the time. It is sufficient for there to be at least one operational relay for each user to serve the queries from the network.
No relay needs to store and process data sequentially: The sequential nature of blockchains and the rules embedded in the protocols using those blockchains prevent double-spending. There isn't a double-spend problem we need to solve with "tweets" or any application other than money (i.e., value storage and transfer), so the precise sequence of all "tweets" worldwide is not a concern to any given user or relay.
No relay needs to store and process data since inception: Since we don't have the problem of calculating account balances or total money in circulation, relays are free to choose how far back to store and transmit data.

Unlike a blockchain-based protocol, more flexible protocols like nostr have a chance of working and satisfying the attributes of the Web we want:

Private: No user needs to disclose any information about themselves that they don't wish to reveal. Anyone can anonymously run a relay. Users may anonymously compensate the relays that serve them using global, digital, sound money, and both users and relays can build reputations based on their public keys.
Verifiable: Every user can hold their private keys and communicate in a verifiable manner using cryptographic signatures. Further, separating the protocol from the user interface allows a user to select an interface where they can verify the algorithms used by the application in presenting the queried information.
Censorship-resistant: Every user is free to run a relay or provide their data to any relay willing to host it. While any relay can censor as it pleases, users only need one third-party willing to relay their data or self-host for their followers to continue receiving their broadcasts.
High availability: Bitcoin is highly available because it has extreme redundancy. Bitcoin's excessive redundancy is necessary as any one of the eight billion people across the globe may need to communicate with others on the Bitcoin network at any given time. On the other hand, a redundancy of a handful of relays should be more than sufficient for most applications using nostr, even for the most influential of influencers to reach their followers. More importantly, anyone can run a relay and self-host if needed or desired. Thus, nostr applications can achieve sufficient availability with ten relays as opposed to ~50,000 Bitcoin nodes [15] and ~5,000 Ethereum nodes [16].
High throughput: Bitcoin's throughput is at most 4 MB every 10 minutes [17] or 0.053 Mbps, and Ethereum's throughput is at most 1.875 MB every 15 seconds [18, 19] or 1 Mbps. In comparison, the throughput for a user of nostr is constrained only by the user's download speed and the upload speed of his relays. With a median fixed broadband speed of 64.70 Mbps [20], nostr provides three orders (1,213x) more throughput than Bitcoin and one order (65x) more throughput than Ethereum.
Low latency: The median latency of fixed broadband users is 10 ms [20], while two confirmations (~20 minutes = 1,200,000 ms) are standard practice to confirm settlement on Bitcoin, and equivalent settlement (finality) assurances currently require 3x as much time (3,600,000 ms) on Ethereum [21]. Nostr, limited only by the latency of the users' and relays' Internet connections, is five orders faster than Bitcoin (120,000x) and Ethereum (360,000x).
Low cost: The cost of storing and processing data on Bitcoin and Ethereum depends on the supply and demand for bitcoin and ether, whereas the cost of storing and processing data with nostr is more likely to rely on the cost-plus pricing of the underlying commodities (data storage and bandwidth) similar to cloud service providers. At the current fees of 3 sat/vB on Bitcoin [22] and average gas price of 35 Gwei on Ethereum [23], it would cost ~0.03 BTC ($635) and ~0.56 ETH ($753) to store 1 MB of data on Bitcoin and Ethereum, respectively. With the price of a 10 GB DigitalOcean droplet at $4/month and assuming a 100-year data storage duration, the marginal cost of 1 MB of data for a single nostr relay is $0.48. With ten relays, the fees are $4.80: two orders cheaper than both Bitcoin (136x) and Ethereum (157x). Of course, this assumes one needs to store data that long to begin with, which is not a choice when it comes to blockchain-based protocols but is a choice for alternative protocols such as nostr.

Performance comparison

In discrete terms, the average nostr user can achieve 65 times the throughput, 360,000 times faster, and 157 times cheaper per unit than the average Ethereum user. All in, nostr is ten orders (1.98e10 = 1,213 * 120,000 * 136) more performant than Bitcoin and nine orders (3.68e9 = 65 * 360,000 * 157) more performant than Ethereum when considering throughput, latency, and cost.

Scalability comparison

Now consider that a nostr user needs only fetch data directly relevant to him, while the blockchain user needs to fetch everyone's data, all the time, sequentially, since inception. Split equally among the five billion Internet users, and assuming the average Internet user fetches the data of 5,000 other users, the average nostr user would require six orders of magnitude less data than the average blockchain user. By design, the raw performance demand on a nine-order less performant system like Ethereum would be six orders more than the alternative, making Ethereum fifteen orders less scalable than nostr to achieve the same objectives.

Best case scenario for blockchains

Vitalik Buterin suggests that Ethereum can scale 10,000-fold (four orders) using rollups and sharding [24]. Assuming he can deliver on this promise, Ethereum would still be eleven orders less scalable than nostr.

Suppose we further eliminate the need for settlement assurances and assume that Ethereum is a single node with a latency of 10 ms. Ethereum would gain an additional five orders of performance while destroying any remaining hope for privacy, verifiability, and censorship resistance. In such a scenario, Ethereum would still be six orders less scalable than nostr without the privacy, verifiability, and censorship resistance benefits of nostr.

Further, we can expect the cost of storing and processing one unit of data on blockchain-based protocols to increase as the number of users increases, resulting in increases in their token prices and on-chain fees. In contrast, we can expect the cost of storing and processing the same data using protocols like nostr to decrease due to improvements in the underlying hardware and infrastructure (Moore's law).

The above estimates are point-in-time with embedded assumptions. As such, they should be considered illustrative rather than precise comparisons of performance and scalability. Nevertheless, whether the exact difference in scalability ends up being six or fifteen orders of magnitude, it is clear that blockchains are not the tool for the job.

Since blockchains cannot give us the Web we want, we need alternative protocols. More specifically, we need protocols that don't require everyone to store and process everyone else's data, all the time, sequentially, since inception.

Let us proceed together apace. Onward.

— Eric Hughes, A Cypherpunk's Manifesto

Unchaining the Web

Today's Web relies on centralized services that lack privacy, verifiability, and censorship resistance. An alternative web built on blockchain-based protocols would be limited in scale and performance. Without a quantum leap, blockchain-based protocols cannot reach the scale and performance of today's centralized services without falling back to the same trappings of centralization.

The Web we want is private, verifiable, and censorship-resistant. It has high availability and throughput and low latency and cost. A peer-to-peer protocol with a blockchain is an excellent tool to establish global, digital, sound money. We haven't been able to develop a better alternative, and it has a good chance of working. The characteristics that make a blockchain necessary for this one application also make it inefficient and unsuitable for building the Web we want. While another limited application for a blockchain-based protocol may emerge, these protocols cannot provide us with every application we want to use online at the volume and speed we want to use those applications.

The Web we want requires scalable protocols. Luckily, the development of these protocols is in-flight today, and they have a good chance of working to give us the Web we want. In addition to nostr, protocols and applications are being developed by bluesky [25], Holepunch [26], Impervious [27], Synonym [28], and TBD [29], to name a few. We should support, use, and improve those protocols so that one day, we may have the Web we want.

Acknowledgments: I thank all contributors to the nostr protocol for their work, which inspired me to write this article. I also thank Baris Sarer, Cem Kozinoglu, fiatjaf, Jack Ronaldi, rhinovesting, and other anonymous individuals for their time reviewing and commenting on earlier drafts.

References:

Additional reading:

Don't trust, verify: This article is based solely on my personal views and does not represent my employer's views nor the views of reviewers of earlier drafts of this article. This article is for informational purposes only and does not constitute an endorsement of any products and services discussed or investment, financial, or trading advice. I do not guarantee the reliability of the content in this article and shall not be held liable for any errors, omissions, or inaccuracies.

The Web we want

The blockchain

The alternative

Performance comparison

Scalability comparison

Best case scenario for blockchains

Unchaining the Web

Subscribe to Carbon Copy