A funny thing happened on the way to the hackathon. Late last October, as San Francisco Blockchain week was approaching, we were busy preparing some hackathon challenge bounties for Inter-Blockchain Communication (IBC), a protocol that’s a collaboration between Cosmos, Agoric, and others.

We were excitedly discussing how IBC enabled rapid innovation where parties could stand up a new zone (an independent blockchain attached to a central blockchain) with a new protocol. I realized that most zones wouldn’t be able to talk to them because they couldn’t understand their new protocols. Their innovations couldn’t connect.

Hence Dynamic IBC (dIBC). dIBC is, in essence, the idea of using a smart contract or VM platform to deploy new contracts that support new protocols, all on an existing chain without having to wait for chain upgrades. The tl;dr is: There shouldn’t need to be a platform upgrade or chain governance vote every time someone wants to roll out a new protocol.

It then became obvious that dIBC is critical to early growth of IBC because it removes obstacles to innovation. There is a point when a solution isn’t merely addressing a problem. The solution is, instead, something that deserves first-class characterization; it’s a feature that is worth naming, and noting, and calling out.

And so dIBC was born. Before we get into it, first some background on IBC:

The Two Layers of IBC

IBC is like TCP for blockchains. It, too, is a layered protocol with two major groups: the TAO layer and the App layer.

TAO Layer: TAO stands for Transport, Authentication, and Ordering. Christopher Goes (the lead IBC engineer) coined the term at a presentation, and I think it beautifully captures the intent of IBC. It abstracts the best practices for interchain communication.

App Layer: The App layer contains definitions of application-specific packets for application-specific protocols. It is where most of the future innovation will lie, enabling new kinds of cooperation between chains. Here is where blockchain groups will define app protocols such as cross-chain staking, rich credential and authentication support, proof-of-location, cross-chain DAOs, or participation credits for decentralized gaming.

The Innovation Challenge

Many already-deployed chains will not be able to communicate those new application protocols. The reason is that they were built and deployed with code for a specific set of protocol packet types, but they don’t include code to consume the new application protocol packets. To support new protocols, they may require new code, new chain versions, chain governance actions to roll out upgrades, etc. Because on-chain governance and upgrade coordination is slow and permissioned, this overhead impedes protocol deployment, experimentation, and adoption and thus stifles a key dimension of innovation with IBC.

How dIBC Works

We proposed Dynamic IBC (dIBC): the ability to deploy new code that supports a new IBC App protocol to an existing chain. In Agoric, developers will be able to deploy new smart contracts and components that parse IBC app protocols using typical JavaScript libraries for e.g., ProtoBuf.

Agoric will implement support for IBC channel endpoints to be routed to smart contracts deployed in Agoric, where the new application protocol packets will be parsed and processed in JavaScript. Because new contracts can be deployed essentially permissionlessly on a running chain, newly launched zones can create and deploy their own counterparty smart contract on Agoric. Those smart contracts can fully interoperate with the rest of the Agoric ecosystem and so, for example, provide new digital assets into the marketplace powered by their new application protocol and zone.

The implementation work is primarily plumbing of IBC channels up through the layers of JavaScript, parsing of existing packet types (e.g., fungible token transfer), and providing general support for parsing new packet types (e.g., ProtoBuf parsing).

Systems that support uploading new wasm code will be able to provide a similar solution, and indeed could then interoperate with Agoric using these new protocols, with no chain upgrade required on either side.

We believe that the ability to rapidly and permissionlessly deploy counterparties is crucial to encouraging the development of new application protocols, which in turn is crucial to the healthy and rapid growth of an IBC ecosystem.

A Proof of Concept

Here’s an example of dIBC in action: Take Alice, who has a new chain with a new app protocol — you know, for her magic item NFTs, or proof of location, or oracle proofs, or a new authentication infrastructure, whatever she may choose. There needs to be a counterparty on another chain for Alice to communicate with. That other chain then needs to go through a process to deploy code that can understand her new app protocol. This doesn’t necessarily require system-wide change; this is specific to support her app.

But if Alice has a platform with dIBC available, she can connect much more easily: with the Agoric platform, she could write a smart contract in JavaScript, deploy it, and immediately bring her digital assets or new functionality to other contracts there. Similarly, a third party on the Agoric platform could add code to leverage Alice’s new app protocol and service without requiring coordination or permission from anyone else.

On to the Next Hackathon

Given that dIBC arose initially from us prepping for a hackathon, it’s fitting that we would test our dIBC at a hackathon. We are working to have dIBC available for the virtual Gitcoin Cross-Chain Hackathon, starting on April 20 (through May 11), complete with prizes (we’re collaborating with Cosmos and Band Protocol). Here’s an example hackathon challenge: an asset from one chain must be sold in a JavaScript contract on the Agoric chain for money from yet a third chain. Another potential challenge: a new and useful application protocol must be defined, deployed in a zone, and then utilized from a smart contract on the Agoric chain. That kind of activity will make the value of dIBC self-evident.

Thanks for reading! You can join the Agoric community on Twitter, Telegram, and LinkedIn, and subscribe to our monthly newsletter.