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
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.
On to the Next Hackathon