Preface

Just prior to the Interchain Conversations, a gregarious gang of cross-blockchain interoperation aficionados from Tendermint Inc, the Interchain Foundation, and Agoric gathered together in Berlin for an intense two-day work session focused on the IBC protocol. The session consisted of specification review, multi-color protocol whiteboarding, and vigorous design debates, and resulted in many useful conclusions as to both the desired form of IBC v1 and compelling directions in which to take the protocol in the future, to which I shall attempt to do justice in summary here.

Day One

Day one started out with a recap of the protocol architecture designed thus far, as outlined in the IBC architecture document. We discussed the host state machine requirements (ICS 23, 24), client (ICS 2), connection (ICS 3), and channel (ICS 4) abstractions, relayer requirements (ICS 18), and higher-level module-facing interfaces (ICS 25 & 26), and drew out the whole dataflow system on the whiteboard.

IBC protocol architecture

Once we had a collective understanding of how each individual IBC component worked, we examined what would happen if a certain one didn’t. We categorized failures into five distinct groups, and considered how best to architect consensus equivocation detection, packet acknowledgements & timeouts, and connection/channel closure & recovery into the protocol in order to provide applications with clear ways of handling different failure cases.

Categories of failure

Handling packet & channel failures

The day concluded with a discussion of two advanced inter-blockchain communication feature-sets: multi-hop routing and directed-acyclic-graph cross-chain partial packet ordering. Three kinds of multi-hop routing, with various trust requirements and storage / execution / latency cost tradeoffs, were outlined: application-layer multihop, validity-proxy multihop, and routing-layer multihop:

We decided to prioritize shipping v1 of IBC, and thus omit these features (sans application-layer multihop, which is already supported) for now, but both in-protocol multi-hop routing and directed-acyclic-graph ordering are fascinating research directions that will add useful capabilities — perhaps to IBC v2! Discussion has continued on Github (multi-hop routing, DAG packet ordering), and IBC v1 will appropriately choose channel & connection data structures to facilitate future multi-hop support.

Day Two

The second day of the workshop started with a deliberation on acknowledgements: how best to inform senders that their packets had been received and executed upon (or that they had not), while minimizing the amount of computation and storage necessary (both, of course, being rather expensive on a blockchain). We discussed whether acknowledgements should be solely an indicator of packet receipt or whether they should be synchronous with packet execution (conclusion: the latter, for now) and whether they should happen only on failures or also on success (conclusion: both, with success acknowledgements configurable by the application).

How best to acknowledge packet receipt?

Day two continued with a presentation by Mark Miller on Agoric’s object-capability stack, partitioned into two parts (we paused for a lunch siesta): relative routing and e-rights pegging. After the presentations, we discussed Agoric-IBC integration possibilities and came up with a plan to merge Agoric’s VatTP cross-machine transport layer and IBC (which, conveniently, were already almost isomorphic):

IBC <-> Agoric Integration options

Finally, we listed out planned IBC implementations in various languages (if we missed one, let us know) and discussed how best to coordinate between implementers, construct language-agnostic specification-compliance test-suites, and safely deploy the IBC protocol into production.

IBC implementations & testing strategy

Conclusions

Following the workshop, conclusions were summarized and partitioned into separate issues, the subset of which required for IBC v1 have been collected in a milestone. Joon & I are now back to monkeys-on-keyboards finalizing the v1 specification and prototyping the implementation — we look forward to future collaboration between the Tendermint company, the Interchain Foundation, and Agoric, and we invite help from anyone who shares our vision of a versatile, modular, secure and permissionless inter-blockchain communication protocol.

Get Involved

To track progress on IBC, follow this issue on the ICS repository. If you are considering utilizing or planning to utilize IBC in your own sovereign chain, join our biweekly IBC ecosystem calls (in which we’ll also announce any future workshops) — reach out to cwgoes@tendermint.com for a calendar invite. If you have questions, clarifications, or concerns about the protocol, open an issue on the ICS repository and ask away.

See you on the interchain.

The views and details expressed in this blog post are those of All in Bits Inc (dba Tendermint Inc), and do not necessarily represent the opinions or actions of the Interchain Foundation.