Cross-Chain Communication Fundamentals
In the last post, we discussed the existing blockchain interoperability landscape and looked at the core principles of network interconnectivity developed by Cerf and Kahn during the evolution of the Internet. In this post, we’ll focus on understanding properties of cross-chain communication from the ground-up.
Achieving scalable cross-chain communication is a complex endeavor. Interoperable systems and networks need to understand multiple existing blockchain systems, their consensus rules, virtual machine environments, security models, governance rules, etc. Can we even hope to build elegant and simple cross-chain protocols? We have a reasonable understanding of how to evaluate distributed consensus protocols : understand the network model, liveness and safety assumptions, as well as the underlying cryptographic assumptions. So how should we evaluate a cross-chain network?
If we follow the core principles of network interoperability, coupled with excellent engineering and deployment, even cross-chain communication can be secure, scalable, and elegant.
Properties of Blockchain Interconnectivity
Let’s recap the core properties that an interoperability system must satisfy from our previous blog, and translate them into the language of blockchains.
- Plug-and-Play Connectivity. Each distinct network needs to stand on its own, and no internal changes should be required for any such network to be connected to other ecosystems. In the context of blockchains, it means that platform developers should not be forced to perform any heavy engineering tasks to plug-in to other ecosystems. Of course, given Turing-complete smart contracts on some chains it’s tempting to code complicated logic to understand the state of other platforms, but this ultimately puts developers in a grid-lock where no one can upgrade without coordination with other stakeholders they’re connected to. For instance, suppose blockchain A and blockchain B would like to interoperate. Suppose blockchain A must observe every action on blockchain B and vice versa. Setting up transaction parsing rules and logic around it is a heavy undertaking upfront, but it gets even worse if, say, blockchain B wants to upgrade. For instance, if blockchain B wants to add new transaction types to its consensus, then its developers need to coordinate with blockchain A developers on such upgrades and then upgrade the transition logic accordingly. And this problem scales if blockchain B maintains N such connections to different networks. Imagine having to run a software upgrade on each one of your peripheral devices (keyboard, mouse, ipad), after each upgrade of your main laptop or workstation. Instead, the integration connectors should be as light as possible, and work as a “plug-and-play” model.
- Best-effort intermediate communication. 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. For blockchain systems, the source is often a user or an application smart contract, and a destination might include a destination chain and a contract address that the user/application wants to invoke. For blockchains, satisfying this property is tricky since we always want to achieve atomicity of asset and state transfers and avoid double-spending. So if a cross-chain packet is dropped, no user/application should lose their funds, and they should be able to re-send from their origins.
- Gateway-based connectivity to all blockchains. Individual blockchains should connect to other blockchains via black boxes (gateways and routers). For blockchains, this means that each chain needs to host “gateway accounts” (smart contracts). All information from applications on one chain should be routed to these accounts. Underlying routing and delivery protocols should parse the information from these accounts and deliver it to the corresponding destination blockchains. These gateways should be easy to instantiate, as discussed above, and they should not depend on the state of N networks.
Achieving the above 3 properties is ideal, but it’s relatively straightforward to satisfy them with a centralized system: put a central database between a few networks and an API/interface that users can query.
Our ultimate goal however should be to power all decentralized applications with decentralized cross-chain communication protocols. Otherwise, any centralized entity that is in the middle will eventually be able to censor and control who can use the systems and how they’re used. So what security properties should a decentralized cross-chain system try to maximize?
To simplify the discussion, let’s fix some notation. Assume a sequence of blockchains (X_1, …, X_n) want to interoperate, and assume that an interoperability network Y powering a decentralized protocol is responsible for interoperability between X_i’s. Let F be the corruption threshold that Y can tolerate (for instance, standard Byzantine protocols have 1/3 corruption threshold — in other words, if 1/3 of node operators collude, they can break the network).
- Decentralization. As we discussed, the network needs to include as many validators as possible for maximum security. There needs to be both economic and utility incentives to participate in the protocol. The community and node operators must govern the protocol. Malicious behavior needs to be identifiable and addressed at the protocol level.
- Maximum Safety. In many blockchain systems only a few miners or validators can collude to break the safety of the protocols. Since interoperability networks secure and transmit large amounts of funds, safety should be maximized on these networks such that almost all node operators would need to collude to break it. A protocol must support high safety thresholds (e.g., F > 0.9) to increase the cost of attacks. High safety thresholds combined with maximum decentralization creates a network that’s hard to compromise.
- Cross-Chain Liveness. Liveness of interoperability networks must ensure that requests from a source X_i to a destination X_j are executed atomically. So, for any two chains X_i and X_j and an interoperability network Y in the middle, assuming X_i, X_j, and Y make progress following their consensus rules, then there is a time in the future such that any request from X_i ->X_j is properly finalized within a set timeframe.
- Fall-Back Mechanisms. When threshold F is maximized, then an immediate question that arises is what happens when > (1-F) of interoperability node operators go offline. Traditional blockchains stall in these cases, however for interoperability networks we have an opportunity to do better. Interoperability fall-back property states that if Y stalls, then there is a different protocol P that can be invoked by a different (and potentially much larger) set of operators to:
a) recover any assets that might have been locked by Y, or/and,
b) fix the state of blockchains X_i.
It is important that a much larger and a potentially “stronger’’ (economically or technically) set of operators can invoke P. Otherwise, there is the potential for a direct attack on the network where an adversary might attempt to stall the network Y itself, compromise operators of P, and steal the funds.
- Shared Governance. Another attack vector that we must consider when we allow chains to interoperate is what happens when some chain X_i breaks its rules. For instance, assume that a “large” blockchain X_1 such as Ethereum talks to a small blockchain X_2. What should happen if X_2 breaks its security assumptions and, say, forks? A combination of on-chain rules, community and social governance rules must be applied to decide what happens when the trust assumptions of X_2 are violated. Should its state be frozen on X_1? Should it be disconnected from interoperability with X_1? If X_2 is connected to other blockchains X_3, … X_n, then consistency between X_2’s state across different platforms should be encouraged.
It’s easy to see how complicated the problem quickly becomes. But if you meet the core interoperability design principles and the additional properties outlined above, then:
a) There is a constant amount of work to build an interoperability protocol, followed by a constant amount of work to plug-in every new blockchain B_i. In other words, the work to scale interoperability is linear.
b) The benefits of the right architecture are quadratic: any application on any chain X_i can communicate with X_j via Y using a unified API/gateway approach.
c) The work needs to concentrate on maximizing decentralization, safety, liveness, and governance of one unified network.
By combining simple design principles with scalable architecture, we can not only meet basic functionality requirements, but can also build elegant protocols and networks that will continue to serve applications and users for decades.
The Foundation of Cross-Chain Communication was originally published in Axelar on Medium, where people are continuing the conversation by highlighting and responding to this story.
