Speaking in Tongues - Profiling Cross-Chain Messaging Protocols

Key Insights

• Generalized cross-chain messaging protocols are poised to usher in a systematic shift to how we design multichain applications. Rather than exporting tokens, smart contract networks will import execution instructions to run on top of their secured assets.
• The Inter-Blockchain Communication (IBC) Protocol, Axelar, Nomad, LayerZero, and Chainlink CCIP demonstrate the wide variety of trust assumptions that cross-chain messaging protocols have.
• Because trust assumptions are inherently baked into cross-chain designs, developers must understand the unique risk profiles that each protocol contains.

“I absolutely hate broken bridges. I just can’t get over them.” - any multichain crypto user, ever.

Puns aside, crypto’s multichain landscape is a mess. A lack of tooling and basic operating standards discourage developer efforts while fractured liquidity and clunky UIs cause headaches for end users. Not to mention almost every piece of infrastructure seems to be built on weak trust assumptions obscured from the end user. We can’t even get through a calendar month without watching another bridge fall victim to a nine-figure exploit.

Despite all the ways these problems take shape, they share a common root cause: permissionless blockchains are incapable of engaging in cross-chain communications out of the box. This is a product of their trustless nature; to process any message, a blockchain needs a way to verify its authenticity. This is easy in a homogeneous ecosystem like Polkadot where each individual chain is connected to a shared hub for economic security. But for heterogeneous blockchains with differing rule sets and security guarantees, this is much harder. In fact, it’s impossible to do without involving a trusted third party or directly verifying the history of the external network.

This is where cross-chain messaging protocols come into play. Some establish frameworks for bi-directional communication agreements while others serve as third-party translators for disparate chains. Regardless of their structure, all share a common purpose to enable arbitrary messages to be passed between chains with varying trust assumptions. As we will see, these trust assumptions will dictate how risk manifests across different cross-chain models.

Understanding Cross-Chain Messaging

To date, crypto’s cross-chain efforts have primarily been focused on transferring a specific message structure: the token. But as with many speculative advancements in crypto, the long-term potential for cross-chain communications isn’t limited to only serving as a tool for gambling addicts to gain access to the hottest digital casino.

In a return to first principles, a growing number of generalized cross-chain messaging protocols are coming online to enable chains to pass any form of arbitrary data between one another. Bridges will continue to exist and will easily be rebuilt on top of these new communication rails. However, we should expand our collective imagination and consider how this could significantly alter how we approach blockchain interoperability.

Source: 0xpostman

Rather than exporting tokens, smart contract networks will import execution instructions to run on top of their secured assets. The focus can move away from pushing value from the network to instead pulling execution logic into the system. This is a big deal. Cross-chain smart contracts will reorient our understanding of the interchain operating system. Providing this crucial connection allows developers to return to what they excel at: building composable applications. In the not-too-distant future, users can expect to enjoy the following benefits:

• Unified governance systems across multiple chains (cross-chain DAOs)
• Aggregated DeFi services including (but not limited to) cross-chain yield farming and cross-chain collateralized loans
• Super wallets: one address that can control sub-accounts across various chains

This short list is by no means exhaustive. Just as application composability spawned a wave of innovations within synchronous blockchains, composability will once again breed innovation across asynchronous networks.

It’s important to note that there are numerous protocols working on cross-chain communications. As such, the following protocols are not intended to encompass all cross-chain models. The following definitions will aid in this analysis.

• Economic security ensures that the value to be lost from a system attack is higher than the value that can be gained. This can be measured quantitatively.
• Safety means that the system works as intended and is not exploited by a bad actor. Safety is jeopardized when economic security fails.
• Liveness is a state in which all components of the system are actively serving their function. Liveness can also be thought of as the opposite of downtime. It’s measured deterministically (true or false).

IBC

The Inter-Blockchain Communication Protocol (IBC) is a framework that enables heterogeneous blockchains to establish cross-chain connections without adding trust assumptions from a third party. Participating chains agree to trust each other’s security models and use a shared messaging standard to communicate and verify state changes. This allows IBC messages to inherit the lowest safety of the underlying chains.

Establishing this secure connection is resource-intensive for both chains. When a message is initiated on the source chain, a permissionless relayer transports a light client proof of the message request to the destination chain. For the destination chain to validate this proof, it must run a light client that reads the state of the source chain and records a copy of this state on its own ledger. This direct verification process assures the destination chain that the source chain’s request was indeed valid before executing the request into its own state.

By optimizing for safety, IBC’s design creates a few notable tradeoffs.

1. The destination chain must assume that the transaction request was finalized on the sending chain. Forks and block reorgs common on chains with probabilistic finality (such as Ethereum) would break IBC’s security promises. For this reason, IBC is only compatible with consensus mechanisms that have strong finality guarantees such as Tendermint. “Peg zones” can be used as a workaround solution to establish a finality threshold when connecting to a chain with probabilistic finality. However, this adaptation increases the system’s complexity and thus creates additional attack vectors.
2. The IBC model is cost-prohibitive for blockchains with low throughput and expensive block space. This isn’t a problem in the Cosmos ecosystem — IBC was designed to work natively within chains built on the Cosmos SDK where IBC modules run at the network level rather than the smart contract level. Further, it enables Cosmos-based chains to transfer the costs and responsibilities of maintaining other chains’ on-chain state records from applications to network validators.
3. Relayers, rather than users, bear the transaction costs to move messages between chains. However, this tradeoff allows relaying to become a public good for network users. Relayers are often operated by validators that are incentivized to keep both networks running. IBC’s economics make it rational for relayers to socially coordinate and only have one relayer service a each IBC channel at once. Should a situation occur where no relayers are servicing a channel, messages will be stuck until a relayer delivers them. While this has no effect on the overall safety of either chain, liveness can be temporarily reduced for interchain communications. For liveness to completely fail, one third of either chain’s validator set would need to collude or go offline to bring the underlying chain to a halt.

Altogether, IBC allows connected chains to function as decentralized read-oracles for one another. Its resource-intensive safety measures allow it to perform cross-chain message transfers without relying on third parties that modify the trust assumptions that secure the underlying chains. For this reason, IBC is widely accepted as the benchmark for cross-chain communication comparisons.

Axelar

Axelar facilitates cross-chain messaging by creating yet another Proof-of-Stake (PoS) blockchain built on the Cosmos SDK. The network is designed using a hub-and-spoke model to enable one-to-many cross-chain connections.

The Axelar hub connects to heterogenous chains using specialized “gateways.” These spokes can be implemented as smart contracts at the application level or may interact with network-level functions such as IBC in Cosmos or multi-party computation systems in Bitcoin. Message requests that arrive at an Axelar gateway are relayed to validators in the Axelar hub. Just as with IBC, relayers are permissionless, and the network requires at least one relayer to ensure liveness for the related connection.

Axelar’s validators are required to run a light client or full node for at least one external chain to provide a local record of its state(s). If a minimum threshold of these nodes isn’t met, the related connection would lose liveness until indefinitely. Individual Axelar validators use their knowledge of these external network states to collectively vote on relayed message requests and enact state transitions to push transactions to destination chains.

The consensus voting process combines a bonded PoS mechanism with a threshold signature scheme (TSS). Similar to a multisig, a TSS requires a minimum value of signing power for a request to be approved. One key difference of the TSS model is that private keys are assembled before signing in order to form a single signature. This allows the validator set to scale without increasing the overhead cost of signature verification associated with scaling a similar system that instead uses a multisig. New private keys that combine to produce a TSS signature are generated and distributed whenever a rotation of the validator set occurs. This adds another barrier to attack but also adds ongoing execution risk to the system. The minimum threshold to approve message requests varies depending on the destination chain, allowing each chain’s connection to have unique security parameters.

As a final note on Axelar’s structure, its blockchain only stores information associated with its gateway contracts and cross-chain transactions. This means its state will only grow with the number of cross-chain requests it facilitates rather than the size of all connected chains.

Zooming out, the Axelar network looks like a brain for all heterogeneous blockchain networks. Capable of both read and write functions, it aggregates multiple indeterminate inputs and uses them to calculate a single deterministic output that manifests as simple yes / no decisions. The network boasts an impressive set of offerings that will make it attractive for developers to leverage as a base for cross-chain applications.

• Native IBC support provides another solution for the growing Cosmos ecosystem to interact with chains that lack immediate finality consensus mechanisms.
• TSS will allow the system to configure its probabilistic consensus threshold on a per-chain basis.
• The hub-and-spoke model allows the number of required connections to scale linearly with the number of supported chains. In a world where network effects fuel adoption, this is a distinct advantage over designs that rely on pairwise connections.

Axelar’s model carries a notable short-term disadvantage that may handicap its scaling potential. The bonded PoS model that secures Axelar’s hub limits the broader network’s ability to scale from an economic security perspective — should the value of its stake fall below the value of assets secured by the network, the system will be prone to an attack. However, the fact that Axelar is built on the Cosmos SDK provides a potential workaround. Cosmos’ plans to enable Interchain Security could allow Axelar to outsource a portion of its economic security to an ecosystem of Cosmos chains.

This brings us to the long-term risks that Axelar’s success could have for the broader crypto economy. Axelar’s all-encompassing structure makes it a central point of failure sitting at the heart of a multichain universe. Unlike individual nodes within a distributed network, Axelar’s hub only exists as a single instance. If its security is compromised by obtaining two thirds of its validators’ stake, malicious actors gain the ability to write to every supported chain. Since the network’s stake is separated from both the source and destination chains, there would be no way to enforce slashing once an attacker takes control (the attacker would need to slash its own value). The structural risk extends to liveness as well. If one third of Axelar’s stake goes offline and the network halts, liveness for all of its connections will fail together.

If we have learned anything from previous cross-chain exploits and the recent contagion from high-profile collapses, it’s that distributed risk is a required ingredient for resilient cryptoeconomic systems. Chain rollbacks are not feasible in a multichain world. If Axelar succeeds in gaining mass adoption, the industry could be forced to deal with its own too-big-to-fail situation.

Nomad

Nomad is an implementation and extension of Celo’s Optics protocol. While both use nearly identical models, only Nomad will be covered due to its unique partnership with Connext.

Nomad flips the game theory of cross-chain trust assumptions on its head using an optimistic model. Rather than verify that each message request is valid in a proactive manner, Nomad optimistically assumes every message request to be true while outsourcing the burden of verification to off-chain Watchers. This allows Nomad to function similarly to optimistic rollups.

Messages initiated from the source chain are hashed and inserted into the Merkle tree of the chain’s “Home” smart contract. A bonded off-chain actor known as the “Updater” signs this Merkle root and passes the proof to a permissionless relayer for transfer to a “Replica” smart contract on the destination chain. After verifying the updater’s signature, the message enters a ~30 minute challenge period. Here, off-chain "Watchers" use fraud proofs to submit challenges to the source’s Home when they witness fraudulent messages signed by the Updater. Only one Watcher is required to submit a valid fraud proof for the Updater’s bond to be slashed, thereby increasing protocol safety. Should a Merkle root's challenge period elapse without a fraud challenge, a "Processor" passes the full message and accompanying root to the Replica for execution on the destination chain.

Nomad’s innocent-until-proven-guilty model introduces a new variable into the cross-chain equation: latency. While this may seem like a bug, Nomad believes it can actually be a necessary feature for cross-chain communications. The 30 minute challenge period provides a way to limit collateral damage for applications in the case of a hostile takeover. As highlighted with Axelar, the risk of contagion must be considered upfront when choosing an interoperability solution to avoid catastrophe. However, Nomad's current implementation uses block time to measure its challenge window. This results in a system where security is coupled with liveness - if a malicious updater signs a fraudulent root just before a liveness failure, the challenge period may elapse as soon as the first block is processed after the system regains liveness. Nomad plans to fix this in the near-future by swapping block time for block number as the base unit for measuring challenge period duration.

The latency period also allows other protocols to build on top of Nomad to service user demand for faster cross-chain finality. In January 2022, Nomad entered into a partnership with Connext to enable a “modular interoperability stack.” Connext acts as a liquidity layer on top of Nomad’s messaging system. It provides users with instant liquidity for asset transfers and is capable of executing certain smart contract calls on their behalf without introducing additional trust assumptions to the system. In return for inheriting the risk that an application’s message is proved fraudulent, Connext collects a small fee per transaction. It’s important to note that not all messages can benefit from this expedited service. Permissioned calls, or messages that must come from a specific entity (such as a DAO-authorized contract upgrade), are forced to wait through the optimistic challenge period.

Aside from latency, Nomad’s design choices carry a few other notable tradeoffs.

• The use of a singular Updater reduces overhead resources required to verify state. Should the Updater suffer downtime, there will be a liveness failure on the outbound channel. Nomad has plans to mitigate this by adding downtime slashing for Updaters along with an Updater rotation model to allow standby Updaters to step in.
• The Watcher role carries both a trusted and untrusted element due to how Nomad handles fraud. Theoretically, anyone can play the Watcher role and slash Updater fraud permissionlessly on the source chain. This is because the source chain has knowledge of the original message request which it can use to verify the fraud proof against. However, since the destination chain has no way to verify the original message request (since it was created on the source chain), it must trust that every fraud proof it receives is valid. A malicious actor can exploit this to censor messages on the destination chain by spamming it with invalid fraud proofs, therefore requiring the Watcher role to be carried out by a permissioned entity.
  
  For this reason, Nomad emphasizes that a Watcher must have incentives aligned with the applications it services. Assuming Nomad or any protocol built on top of Nomad is willing to run an honest Watcher, this shouldn’t be an issue considering their existence depends on applications successfully passing transactions through the system. However, a limited watcher set naturally makes it easier for an updater to bribe its Watchers to permit. Ultimately, the system will need at least one honest Watcher (likely Nomad) to be online and resist any such bribe attempts.
• Nomad is focused exclusively on connecting EVM-based chains and Ethereum scaling solutions. This limits its total addressable market in a similar way to IBC with instant finality chains. Nomad’s Home contracts are generalized so that source chains may send messages to any Replica contract from a single outpost. However, destination chains require a unique Replica contract to receive messages from every supported source chain. As with IBC, this results in a pairwise relationship for scaling connections.

Overall, Nomad’s Ethereum-centric focus is a concentrated bet that the network will continue to be the Schelling point for application development. By enabling other cross-chain protocols to service latency demand on top of its optimistic messaging infrastructure, it could establish a moat similar to rollup ecosystems with significant application integrations. As new Ethereum scaling solutions continue to come online, Nomad will be perfectly positioned to capitalize on their natural demand for cross-rollup messaging.

LayerZero and Chainlink CCIP

Due to close overlap, LayerZero and Chainlink’s Cross-Chain Interoperability Protocol (CCIP) will be discussed together.

LayerZero

LayerZero is the modular framework for generalized interoperability. It allows applications to choose their trust assumptions on a per-transaction basis and leverages a simple model composed of only one off-chain oracle, one off-chain relayer, and a set of on-chain Endpoint smart contracts. The protocol shifts the responsibility of declaring specific oracle and relay providers from the protocol itself to the applications running on its framework. To aid in the decision process, LayerZero recommends that applications outsource oracle responsibilities to Chainlink while operating its own relayer as a public good. In its current implementation, LayerZero relies on an oracle operated by FTX, Polygon, and Sequoia.

Applications send transactions to a chain’s Endpoint to initiate a message transfer request. The Endpoint then requests the selected oracle provider to retrieve the corresponding block header from the source chain and pass it to the Endpoint on the destination chain. The source chain’s Endpoint will simultaneously produce a transaction proof for the relayer to pass to the destination chain’s Endpoint. The oracle’s block header and the relayer’s proof are then matched and verified in conjunction by the destination chain’s Endpoint before the message is submitted on-chain. Both the oracle and relayer are paid on a per-transaction basis by the requesting user on the source chain.

The protocol advertises itself as the first “trustless interoperability protocol.” This claim is justified on the basis that the oracle and relayer don’t collude to compromise the safety of the sender’s message. However, this can be misleading because an attacker that successfully compromises the oracle network can simply run its own relayer to “collude” and force transactions through the network and compromise safety. Therefore, the message sender is forced to trust the oracle provider for safety. While the application could run its own relayer to ensure proper delivery, this negates the cost benefit of using a third-party service in the first place.

Chainlink Cross Chain Interoperability Protocol (CCIP)

Source: Chainlink

Chainlink’s CCIP is positioned to be a direct competitor to LayerZero given the latter’s reliance on decentralized oracle networks for system security (and its specific recommendation for applications to use Chainlink as their default provider). Even though CCIP is still under development and public details of its technicalities are rather limited, we have enough information to draw some basic comparisons against LayerZero.

CCIP is an even simpler model than LayerZero, composed of only Chainlink’s existing decentralized oracle networks (DONs) and messaging router smart contracts (MSRCs) comparable to LayerZero’s Endpoints. Unlike LayerZero, CCIP’s oracle and relayer functions are combined and handled by Chainlink’s DONs. As highlighted above, this design decision doesn’t carry a material impact on the system’s safety or liveness in practice.

Comparative Analysis

Head-to-head, LayerZero and CCIP’s similar models should shift the grounds of competition to the basis of network effects rather than tradeoffs in trust assumptions. Both protocols are capable of connecting to any smart contract network using Endpoints and MRSCs. Whichever one of these environments supports the easiest connection for developers to plug into should gain a significant advantage. LayerZero has the head start on the implementation side, but CCIP can tap into Chainlink’s existing chain integrations as soon as it comes online.

Further, CCIP’s ability to leverage the Chainlink network’s broader service offerings creates a competitive advantage. Specifically, access to Chainlink’s wider Anti-Fraud Network will provide CCIP with a backup security blanket to track fraudulent actions from Chainlink’s primary DONs. In theory, applications running on LayerZero could also create a similar secondary security layer on their own. The application would need to incentivize relayers with its native token to protect against any malicious relayers colluding with the oracle. However, unlike CCIP’s native access to the Chainlink Anti-Fraud Network, this would incur an additional operating expense for the application using LayerZero.

Compared to other cross-chain protocols that force applications to trust new external entities, LayerZero and CCIP can both leverage the existing oracle providers that their applications trust within their systems. Since cross-chain communication is just a subset of the oracle problem, this would allow applications to kill two birds with one stone. Once again, however, increased efficiencies create concentrated points of risk in a multichain environment. All forms of external communication, both with the real world and with other blockchains, will have shared safety risks that developers must be aware of before building on either protocol.

Tying It All Together

A multichain universe capable of generalized messaging is the missing feature that public blockchains need if they are to become as ubiquitous as the internet. Networks governed by disparate forms of security and rule sets require a framework for direct communications or a third-party system to enable arbitrary message processing. Protocols that connect these individual synchronous chains with the wider asynchronous world provide crucial infrastructure for the next wave of composable application development.

IBC, Axelar, Nomad, LayerZero, and Chainlink’s CCIP offer a unique set of approaches to address the innate trust requirement present in cross-chain communication systems. Similar to the crucial understanding of risks needed to choose a home base for L1 security, developers must carefully weigh the assumptions and tradeoffs that come with using these protocols. These can be summarized as follows:

• IBC maintains the security of the underlying system but is expensive and offers limited compatibility.
• Axelar’s unique combination of multiparty computation and TSS enables the widest range of chain compatibility. However, its design could create a single point of failure in a multichain environment.
• Nomad’s optimistic model assumes the presence of at least one honest actor to facilitate secure connections between EVM-based chains. By introducing latency into the system, applications can protect against risk contagion but will be forced to wait through challenge periods for certain types of transactions.
• LayerZero gives developers a framework to declare trust assumptions at the transaction level. However, its recommendation to use Chainlink’s DONs will put it in direct competition with Chainlink’s CCIP. The likely outcome for these competitors is that applications will combine their cross-chain security assumptions with that of their existing oracle provider.

Unlike the Tower of Babel, which may have fractured a single human language into millions of divergent tongues, cross-chain messaging protocols will unite discrete blockchains into an orderly asynchronous system. This is the true multichain future we’ve been waiting for.

Credits to @0xpostman for inspiring many ideas throughout this report.