Applications and use cases on the decentralized web are further developed than cryptocurrency detractors would like to think. In fact, application development in Web3 has flipped the progression set down in the history of Web2: decentralized application (dApp) developers are leaping ahead of blockchain infrastructure’s capabilities, leaving users with high fees and connectivity issues.

Blockchain infrastructure catch-up efforts to date have focused on vertical scaling: single blockchain ecosystems building a better way from the ground up. Here, I will explain what horizontal scaling is and why it presents a better path to Web3 adoption.

The thesis: How blockchain infrastructure scales horizontally

In 2017-2020, we learned how to build scalable consensus algorithms that can process thousands of transactions per second with second(s) latency in shared environments. But no matter how much you scale a stack vertically, at some point, the resource of a single shared environment will tap out once truly global applications with tens of millions of users start using it regularly.

No single database could support Web2, where even single applications are deployed in their own resource spaces. For instance, Shopify, Facebook, Netflix are operated by independent networks and multiple database instances power millions of user requests behind the scenes. And no single “database” or “network” can support all of Web3. Competing for resources with gas fees only results in painful developer experiences and won’t allow the onboarding of millions of retail users.

What can we do? After finding a product-market fit, many applications will need to find a “home chain,” where control of resources, fees, store, and compute layers can be predictable for its users. This has already begun, resulting in the tremendous growth of new Layer 1 blockchains in 2021. Can Web3 scale if these applications are limited to interoperation with local users, assets and applications? It cannot.

Communication across applications will transition to asynchronous calls over remote chains. Caching, asset and data locality techniques will be used to respond to users’ requests with short finality, while some calls might take a bit longer due to round trips “across the world” where data or assets were not previously cached.

Interoperability stacks will help us accomplish this.

The practice: Components of horizontal scaling in blockchain infrastructure

When discussing interoperability, I think it’s helpful to think about four layers: the base layer, cross-chain transport layer, authentication layer, and interface layer.

Let’s see what these layers are, drawing parallels to “traditional economics” and physical barriers. Imagine you want to travel from one country to another. What infrastructure do you need?

The base layer

To start, you need to prepare your “home base.” You need to have the local infrastructure to maintain exits and entrances: ports, airports, train terminals, etc. To maintain these, you need to assemble staff, fuel, tools and processes.

Let’s map it to blockchains. Post initial development, base layers are operated by the validators and miners, node providers, and tooling infra providers in the ecosystem that support the “blockchain country.” We can build the exits and entrances [gateways] as smart contracts at the application layer or as functions at the consensus layer. These will be used for outgoing and incoming communication.

The transport layer

We need a method of physically delivering people and goods from exits at one country to entrances at another: planes, trains, buses and cars. This layer needs to know which plane can fly where, when to take a direct flight vs. connecting flights, how to refuel, and so on. For blockchains, the transport layer is responsible for packet delivery, path discovery [knowing the connectivity map across blockchains], routing [knowing which packet should go where], fee services, and delivery. This is one of the most complex and important layers, as building it requires the orchestration of information on a global scale.

The authentication layer

Your border control/access point, this layer defines under what conditions an individual can enter a country. Is a driver’s license or passport enough? Do you need a visa? Should a further inspection or a background check be performed? Etc.

In blockchain infrastructure, the authentication layer takes a message delivered by the transport layer and decides whether the message should go through. For instance, it may verify signatures of some validating nodes, zero-knowledge cryptographic proofs or consensus proofs. We can add or remove conditions of verifications here as needed based on the level of security required by the economy and individual users / applications.

The interface layer

The interface layer defines a common interface that states how people record information: e.g., everyone needs to write their messages on paper, and put in an envelope with a stamp. In blockchains, the interface layer provides a messaging *format* that application developers can use to communicate across chains [think, IP packet header format]. It may rely on one of the multiple transport delivery layers underneath – depending on security needs, speed of delivery, and connectivity levels.

Composability and the future of Web3

Why do we need to differentiate these layers? It allows us to design composable systems. For instance, message formats can iterate until they converge on something global, as developers discover additional fields they want to communicate. An application developed on a unified message format may swap its transport layer or support multiple transport layers. Meanwhile, transport layers may evolve in parallel, increasing connectivity while preserving application integrations giving them stronger network delivery guarantees.

Where are we currently, as an industry? We’re still setting up core connectivity pipes across blockchains [somewhere at the transport layer and authentication]. I think we will converge quickly on the messaging interface, as it’s pretty straightforward; we just need to agree on a couple of fields and can iterate from there. At the transport and verification layers, it gets a little more complicated.

All interoperability protocols built to date can be classified across the four layers mentioned above [although in many systems, these layers are blurred or obfuscated]. For instance, Cosmos IBC has:

• Tendermint consensus at the core base layer.
• Permissionless pairwise relayers at the transport.
• Light-client verification for authentication.
• IBC packet semantics as the interface that allows establishing “channels” across applications.

Since IBC makes it hard to establish connections across ecosystems where light clients are not available or impractical to build, other protocols replace permissionless relayers with transport protocols with different tradeoffs. Many of them today are centralized or federated introducing great risks for the ecosystem as we see from repeated attacks. But even if IBC were to function across all ecosystems, the transport layer we need for an interoperable future is far from complete: we need routing, path discovery, trust-minimized routing, and other core network-layer functions.

The end goal is to connect millions of chains and ecosystems and give users and developers the power to control their own destinies. Blockchain infrastructure and solutions must be architected, built, and operated accordingly.

Photo by Brussels Airport, CC BY-SA 2.0.