And why existing blockchain networks are still like the Internet networks in the early 80s.

Everyday, we browse websites and interact with different content from dozens of servers, networks, and geographic locations. Each web page includes links to other websites, iframes, images, video, pop-up windows connecting it to other web pages.

What makes these interactions possible? The answer is in the protocols and networks built throughout decades and APIs that sit on top of this infrastructure that make it possible for developers to send content across the globe. Protocols such as TCP, IP, BGP, and HTTP define communication standards, Internet Service Providers run the underlying networks, and interconnectivity networks, by companies like Akamai, deliver packets efficiently from one network to another. APIs such as those powered by Twilio make it easy to build on top of the stack.

Why can’t a blockchain developer offer their users the same experience? Namely, the ability to interact with other applications and assets across the entire ecosystem. Today’s blockchain ecosystem is extremely fragmented: hundreds of blockchains, dozens of bridging technologies, applications, and users scattered across the ecosystem. We’re still in the early days of ecosystem development, and several core protocols and APIs are missing that prevent us from achieving global adoption.

In the following series of blogs, we aim to understand how we got here and what we can do to solve it. We will start by understanding the history of Internet protocols and what makes computer networks tick. We will then take a look at the existing blockchain ecosystem and some of the missing protocols.

Part I. Cerf and Kahn’s principles of interconnectivity.

The need to connect networks is not new. We’ve seen it played out during the development of the Internet. Engineers figured out how to make devices talk to each other on the same network, many networks were created hosting different applications and users, so the need to connect them emerged. Routing protocols (e.g., IP, BGP), naming services (DNS), and transmission and application-level protocols (e.g., UDP, TCP, HTTP) were developed to deliver traffic across networks and autonomous systems.

Vinton G. Cerf and Robert E. Kahn laid out some of the foundations of the Internet protocols and developed the basic interconnectivity principles across networks [1, 2]. These are the essentials. You need to get them right. Building a system that actually satisfies them is a whole other ballgame.

So let’s recap the core principles that any interoperability system that connects distinct networks to the Internet must satisfy [1]:

1. No changes are required to integrate.
2. Each distinct network needs to stand on its own, and no internal changes need to be required to any such network to connect it to the Internet.
3. Best-effort intermediate communication.
4. Communication is done on a best effort basis. If a packet does not reach the final destination, it will be retransmitted shortly from the source.
5. Gateway-based connectivity.
6. Individual networks should connect to other networks via black boxes (gateways and routers). These black boxes retain no information about the individual packet flows passing through them, thereby keeping them simple and avoiding complicated adaptation and recovery from various failure modes.
7. Decentralized control.
8. There should be no global control at the operations level.

If you look at the architecture of the Internet, it resembles these principles very closely. Distinct networks speak their custom protocols offering everything from cable-based to cellular connectivity. Routers and gateways connect individual networks and route information based on IP and BGP packets. Transmission and application-level protocols are then responsible for the guaranteed delivery of specific content.

Part II. Existing Blockchain Interoperability Landscape.

Existing solutions for blockchain interoperability fit into one of these buckets:

• Centralized or federated systems. Very few, or even just a single entity is controlling and managing protocol and system development and deployment.
• “Bridges” between blockchains. We see a few centralized bridges where validators are appointed to a group of representatives, failing the decentralization objective. We also see a few decentralized systems where the state transition logic of chain A is parsed by chain B (natively or in smart contracts). These inherently fail property #1 (among others). First, they require complex engineering to develop — these are incredibly heavy protocols, and we’ve seen years for them to deploy. Second, if one chain changes, then the state transition logic on all other chains that depend on it must change. Parsing state transition logic of one network in the languages of the other and vice-versa is inherently unscalable.
• Interoperability clusters between some permissionless chain and their sister side-chains (subnets). A few projects are developing their own permissionless chains and allow clients to spin up side-chains/co-chains/para-chains that interoperate through the hub. I’m a big admirer of many of these ecosystems. They can solve interoperability between their side-chains because the side-chains speak the same language, developed and maintained by the same platform providers. But these protocols aim to grow the ecosystem around the main chain. I would classify them analogously to ISPs on the Internet that offer users good “local connectivity.” These hubs must use other technologies to communicate with other hubs and blockchains that speak different languages.

As a result, the blockchain interconnectivity protocols are at about the same state as Internet protocols were in the early 80s. In other words, there is a lot of potential for improvement! We need global naming schemes, address discovery protocols, naming protocols, scalable routing algorithms. We need those “IP” or “BGP” equivalents. We need systems that support these protocols and adhere to core principles developed and tested by Cerf, Kahn, and others for decades. Of course, blockchain protocols have their own twists and properties essential for our ecosystem, such as trust, authentication, and integrity of information.

Building the right architectures and systems that scale is challenging and incredibly rewarding at the same time. But true interoperability will unlock massive potential for the ecosystem.

In the follow-up blogs, we will dive deeper into the design principles required for blockchain interconnectivity and then discuss the approach we’re taking at Axelar.