This is one of the most important times in the history of blockchain infrastructure design. The next few years are critical.

First, I know I’m using the title of one of the latest of Vitalik’s blog post. The topic of this thread is generally in the same topic but of fundamentally different nature. However, the title, “ENDGAME”, is very much on topic.

So, why am I saying that we’re in the endgame and we’re in one of the most important times in the history of blockchain infrastructure building?

The answer is simple, but I will elaborate in detail. We’ve had years to experiment with all sorts of scalability solutions, programming languages, interoperability tools, and what have you, and it is absolutely crucial that we turbo charge blockchain adoption and usage by doing the one thing we’ve been extremely hesitant to do as a space: standardization.

Whoever takes the first step towards pushing the boundaries of this extremely important topic must have two qualifications. First, they have to have both the theoretical and practical expertise on building high performance distributed systems. Second, and more importantly, they must do so with a penchant towards unbiased technical building style and not falling for one’s own narratives, as people in this space often do. Maybe you don’t think I happen to have these qualities, but I’ll claim that I do and attempt to take a first stab at it. I’m generally mostly interested in building a sensible upgraded Internet, not in ideologies.

So, let’s talk about why standardization is so important. Let’s talk about the internet. I’ll call it “Web2”. Despite its many design faults at various layers of the stack, from the communication protocols to the execution environments, the Internet works exceptionally well. Billions of people interact with web connected devices pretty seamlessly. The way that web2 has been built is in an obvious and sensible way: it’s a collection of horizontally distributed and mostly-independent apps (I’m abstracting here, they are really servers/computers that run apps, but ignore that part; these apps are read, write, and process data). It’s so obvious in design that if we were to have independent teams that knew nothing about the internet try to rebuild it, they’d probably mostly end up in the same architectural design. Effectively, the techie version of “convergent evolution”.

These apps communicate through a global routing network of AS’s and ISPs. What makes this setup so fantastic are two properties:

  1. Property 1: These apps can come and go freely. The network scales up automatically as demand rises. This is, in large part, due to the fact that there’s not much trust requirements for these apps (as in, we just trust them to execute correctly), thus all the complexities of building Byzantine-fault-tolerant distributed systems go out of the door.
  2. Property 2: These apps have a common communication standard. This is crucial. Basically, “Web2” looks something like this:


I’m obviously hiding a few details, such as the fact that some of these apps aren’t executing on single servers but may actually be in some sort of crash-fault-tolerant setup. However, for the most part, this is basically what Web2 is.

So, what is Web3?

I will posit something so heinously boring that it is controversial. Basically, boring enough to be exciting.

From a “good” systems-design specification/abstraction perspective, Web3 MUST BE defined as follows: Web3 is an extension of Web2, wherein apps go from being crash-fault-tolerant to byzantine-fault-tolerant, while maintaining the two aforementioned properties.

So, illustration-wise, it looks something like this:


Web3 apps (or dapps) are labelled in red. Note one important part here: we abstract away the blockchain entirely, and instead focus on the applications themselves. This keeps our infrastructure abstraction entirely intact. Web3 is really just an extension of web2 with byzantine fault tolerant applications. Otherwise, they must come and go freely and must speak a common communication standard.

These dapps have various degrees of Byzantine fault tolerance. Some have little fault tolerance (for example, if they run on a centralized side-chain), and some have high fault tolerance (for example, if they run on a permissionless L1). Nonetheless, they are just applications.

In a world where financial incentives didn’t matter, this kind of design is the obvious one. The dangerous game of creating interdependencies between these dapps for the sake of attempting to add “security” violates, in more ways than one, the two critical properties that we want to never violate. This is why it is so important to not go down the rabbit hole of creating uber complex shared-security systems, or what have you, in isolation from the rest of the internet. A design where, for example, Ethereum is the only settlement layer violates both properties at once. One where blockchains force esoteric standards violates the second.

Basically, any design except for the obvious one will violate both properties. And, if it wasn’t yet obvious what this “obvious” design is, it’s just a collection of many L1s with different “levels” of security, but where otherwise they do not depend on each other for state management.

In the next few years, we need to focus on building Web3 networks that effectively look like blockchains-as-a-service, without complex tooling.

As always: keep it simple, stupid.

This is, for the most part, the most important endgame. This is the only way we’ll get to this great saying (thank you @pmarca): “Every technology becomes technically perfect at the precise moment when it becomes irrelevant.”

Our endgame is to build a network of dapps that we don’t even think about.

Written on February 1, 2022