Enshrined Interoperability
Why Bridges Will Die And What Comes Next
While bridges have solved the immediate needs of application developers, they can also be seen as a particularly sticky form of technical debt which impedes more innovation at the interoperability layer. With each bridge that launches, we see increasing fragmentation and a lack of standards. Let’s look to operating system design for lessons on how to improve. In operating systems, we have the concept of user space and kernel space. This concept is relevant in blockchain design as well. Interoperability was never meant to be a user space construct. This is the root cause of many of the issues plaguing the interoperability landscape. In this article, we’ll explore how these operating system concepts shape the future of interoperability.
User space vs kernel space
In an operating system, user space is where application programs live. The kernel implements common logic across user space programs. The kernel is generally responsible for managing processes, memory, storage, devices, networking and more. User space programs can communicate with the kernel through system calls or syscalls. This model greatly simplifies application development.
In a blockchain, user space is analogous to various applications running in a virtual machine (VM) or in the form of application specific modules. Kernel space is analogous to the underlying consensus mechanism and other common functionality. For example, in the cosmos stack, the Cosmos SDK is separated from its underlying consensus engine (CometBFT) by the ABCI or Application BlockChain Interface. The Cosmos SDK represents user space, CometBFT represents kernel space and ABCI represents the syscall interface. This means that the blockchain kernel should implement both consensus and interoperability where interoperability is a form of meta networking between chains. Let’s see why bridges as a user space primitive is a broken model for interoperability.
Bridges live in user space
Currently, we have an ever growing number of bridges implemented as user space applications. Each bridge has different interpretations of the interoperability model on chain and relayer implementations off chain. This is analogous to every single internet provider having an application running on your laptop that offers networking through their custom infrastructure. Every application developer would need to integrate either one or more of these internet provider applications to gain internet connectivity. The internet provider is then able to monopolize and extract value directly from the networking layer. This model is not net neutral and greatly complicates application development.
The burden on bridge developers is just as high. Conflicting bridge interpretations of the interoperability model increase integration complexities, create massive maintenance overhead and introduce varying degrees of centralization. Specifically, tightly coupling interoperability with chain user space results in the following issues:
A custom relayer is needed to communicate with the unique endpoints on every chain.
The data structure used to commit to chain state is exposed to the rest of the network resulting in custom proof verification logic for every chain.
Inefficient execution forcing bridges to compromise by not implementing the transport layer and using centralized solutions to move state from chain to chain.
Restricts further innovation which we’ll document in a later section.
These issues are mitigated by enshrining interoperability in kernel space. Bridges today are analogous to discontinued networking protocols like AppleTalk that lacked neutrality. Apple introduced and maintained the protocol from 1985 to 2009. It quickly became irrelevant in the 1990s as TCP/IP became widely adopted but Apple continued support into the 2000s. Similarly, bridges will likely be maintained for years to come by the various companies that own them as their market share fades over time.
Enshrined interoperability lives in kernel space
Bridges will die and enshrined interoperability will set the standard. Chain developers have the responsibility to provide the simplest development experience possible to application developers. This means abstracting away common logic like interoperability by enshrining it into the chain’s kernel space. User space primitives are coupled with chain execution which causes a number of the issues outlined above. Kernel space primitives can be decoupled from chain execution simplifying the integration.
The enshrined interoperability model reduces integration overhead to integrating a single interface. The transport and state layers of the interoperability model live in kernel space while the application layer lives in user space. In the kernel, the transport layer handles the encoding of network topology and routing information on-chain and the state layer handles secure communication. Having the transport layer encoded on-chain means that we can also prove this information between chains enabling multi-hop routing and chaining together packet execution. In user space, we’ll see a proliferation of applications built on top of a common standard. Now that we’ve covered some of the terminology, let’s explore the benefits of enshrining.
The case for enshrined interoperability
There are inherent tradeoffs between user space versus kernel space interoperability. At a high level, a user space approach incurs O(N) maintenance and integration costs where N is the number of unique chain types whereas kernel space approach incurs O(1) overhead. Targeting user space is a short term optimization while targeting kernel space is a long term optimization.
Enshrining interoperability into the blockchain kernel is a stepping stone towards future innovation. We can begin building towards an open and net neutral future while deprecating the AppleTalks of this space. The specific benefits can be summarized as follows:
Standardization
Complete implementation of the full interoperability model (app, transport and state)
Network topology and routing information encoded on chain
Chains have the same representation at the transport layer
Allows for decoupling of execution from chain execution
Avoids exposing the internals of every chain to every other chain
Reuses existing relayer infrastructure and proof verification schemes
Lays the foundation for future innovation
Shared mempool across chains
Replace off chain relayers with a p2p network
Leverage heterogenous paxos for cross chain atomic transactions
Form temporary chains from shared validators across chains to make atomic commits
Interchain gas tokens
Establish a consistent account model across chains
There is a clear need for enshrined interoperability. Choosing the right interoperability standard to enshrine is the next challenge. Here are some desired properties to guide our decision making:
Open standard
Clear specifications for each layer of the interoperability model (app, transport and state)
Net neutral
Not controlled by a single entity
No value capture at the protocol level
Decentralized
Permissionless protocol and infrastructure
IBC as the standard
IBC is the gold standard for enshrined interoperability. It is modeled after TCP/IP and has well defined specifications for all layers of the interoperability model. It is fully decentralized and embodies the principles of net neutrality. In contrast, bridges have varying degrees of centralization and do not encode network topology or routing information on-chain as they generally lack a transport layer.
While IBC is a great standard, one of the main complaints about it is that it is difficult to integrate into new chains. IBC is not a bridge. Integrating it entirely in user space in the form of smart contracts is not efficient as its transport layer machinery handles network topology and routing on chain. Integrating it into a chain client is complicated by various details of existing implementations. Informal Systems, the Interchain Foundation (ICF) and Polymer Labs are working on making IBC into a kernel space primitive. This means an evolution of the protocol and implementation.
Virtual IBC and IBC outposts
Virtual IBC decouples the app and transport layers. Virtual IBC differs from IBC in that the boundary between user space (application) and kernel space (transport and state) is asynchronous. Its state and execution are decoupled from the state and execution of the chain itself. This results in only a minimal interface between user and kernel space and improves integration speed and maintenance overhead. Upgrades and versioning are also handled separately as well. The IBC transport standard itself does not change allowing developers to build on top of a consistent interface and rely on IBC for routing, authentication and its suite of application standards.
An IBC outpost or sidecar implements the Virtual IBC Interface or VIBCI and enshrines IBC interoperability into kernel space. IBC outposts can be either local or remote to the chain itself. While local IBC outposts require an integration directly into a chain client, a remote IBC outpost can enable permissionless integrations of IBC without needing to modify the chain client. Both local and remote IBC outpost implementations will also be available in the near future to simplify IBC integrations for chain developers.
Acknowledgements
Thanks to Jim Chang, Yuan Han Li, Charleen Fei, Susannah Evans, Phillipe Laferrierie and the Polymer Team for all of the conversations!
Glossary
User space: Home for user facing applications. This can be the virtual machine (VM) of a chain or an application specific module on an app chain.
Kernel space: Home for infrastructure common across blockchains. This is where blockchain consensus currently lives and where interoperability protocols should live.
Bridge: An interoperability solution that lives primarily in user space. Bridges are currently implemented as smart contracts within a chain VM.
Enshrined interoperability: An interoperability solution that lives primarily in kernel space. This allows interoperability protocols to implement the full transport layer machinery required for innovative features like multi-hop routing.
IBC outpost/sidecar: Enshrines IBC interoperability into a chain or chain client over the Virtual IBC interface (VIBCI). Can be local or remote. A local IBC outpost is internal in a chain client itself while a remote IBC outpost is external.
Virtual IBC Interface (VIBCI): Separates user space and kernel space. Sits between an IBC outpost and a chain or chain client.