In part 1 we looked at some frameworks for understanding cross chain protocols and assessing their security. In this post, we’re going to apply these ideas to IBC, Nomad, LayerZero and Axelar. Together, these cover a nice range of cross-chain protocol types. Taking requests to add more.
IBC (Inter-Blockchain Communication Protocol)
IBC is the gold standard of cross-chain security. It works by turning existent blockchains into cross chain protocols themselves, giving them “read” ability. IBC is theoretically compatible with most instant finality chains, but often requires prohibitive engineering work to integrate. IBC is part of the Cosmos SDK, and Celo and Polkadot are in the process of building IBC solutions for their chains too.
Base layer = Light client modules that connect the consensus layer of one chain to another. Instant finality chains only.
Auth = Both chains undergo a handshake via their light client/IBC modules. The modules can then verify cross-chain messages.
Transport = Relayers open and maintain pair-wise channels between blockchains. Routing between the IBC module and the smart contract virtual machine or other modules is written into the blockchains’ protocols and depends on the contents of the cross chain message.
Interface = IBC packet semantics, defined by protocol.
Security
Messages transported through IBC carry the safety of the base chains they connect, no less. There is a mild reduction in liveness guarantees, especially in practice.
Base layer assessment:
IBC allows any two compatible chains to act as decentralised read-oracles for each other, thus requiring no intermediary consensus environment for cross-chain communication. For this reason, IBC is hailed as the most trustless cross-chain solution.
Light clients allow nodes of a destination chain to participate in the consensus of the source chain, and hence carry similar security. If a light client is not available at the base layer, IBC offers no alternative. IBC makes no compromises and hence limits its solution to compatible chains.
Malicious attacks:
Attacks would be limited to bugs in the IBC modules and the way these modules are integrated with other modules and consensus.
DDoS or Liveness attacks:
IBC inherits the safety and liveness characteristics of the underlying networks. Liveness is usually very good, as IBC works with instant finality Proof of Stake chains, (a DDoS or targetted down-time attack does not compromise security).
Currently, it’s economically rational for relayers to socially coordinate so only one relayer is servicing an IBC channel at once. This results in slightly poorer liveness, since if a relayer fails or is attacked, we rely on social coordination for another relayer to take their place. Liveness is never truly lost, however, as relaying is open and permissionless.
Number of Nodes down to lose liveness:
1/3 of the registered validators of one of the connected chains. At this point, the validators stop producing blocks.
Node set permissionless?
Yes
Axelar Network
Axelar is a permissionless Proof of Stake protocol leveraging IBC where possible, but with added generalisability to communicate with IBC-incompatible chains at the smart contract layer or directly at the protocol layer.
Generally, this means light clients/full nodes for cross-chain read, and multi-party crypto for write. Axelar applies Cosmos’ vision of an internet of blockchains and extends it to any consensus type.
Base: Protocol or App layer. Gateways installed on source and destination chains, controlled by a permissionless validator set. These gateways can be in the form of smart contracts for suited chains, or interact with other protocol functions via multi party crypto etc, as for Bitcoin, also adopt the relevant native cross-chain protocol, such as IBC, for that leg.
Auth: Permissionless PoS validator set with:
- Read: Each validator checks messages against light clients or full nodes.
- Write: Messages collectively signed by Axelar network are verified by a “gateway” (smart contract or simply an account) on dest chain.
IBC auth support is native to the chain, but only available for connected chains which support IBC.
Transport: Hub and spoke model, adding chains with linear increase in complexity rather than quadratic. Routing is managed at the protocol layer. Trustless relayers pass messages from Source → Axelar and from Axelar → Dest.
Interface: Defined by protocol; gateways include interfaces for sends/receives, token transfer, etc.
Security
Light clients, full nodes and TSS/multisig are controlled by a permissionless validator set, allowing strong safety for both read and write. In my opinion the most secure and decentralised model after IBC, but with the ability to plug into any chain.
Auth layer assessment:
The permissionless validator set is the killer feature, and what makes Axelar a standout protocol to other cross-chain models. It’s pretty hard to engineer permissionless addition and removal of validators, slashing and smoothly updating threshold crypto private key shares and light clients at the same time.
In the spirit of Cosmos, the system can be “customised” for needs of a particular ecosystem it connects.
Malicious attacks:
As a Cosmos chain, Axelar leverages the real-world battle testing of Tendermint and the Cosmos SDK, and inherits the bulk of their security characteristics.
Compromising ⅔ of the validator set would be necessary to break safety.
I’m excited by Cosmos’ Interchain Security as a solution to the old cross-chain economic security issues of scaling the value of the tokens staked with the value of assets secured by the network. An Axelar chain could leverage the economic security of multiple networks (including some connected networks themselves) to secure its own.
I’m interested to see if the complexity around rotation of validators causes issues in the future, as the protocol needs to rotate private key shares and full nodes when a validator joins or leaves.
Other attacks on Axelar which are not possible in IBC may be attacks on the threshold crypto scheme, or to the Axelar PoS network itself.
DDoS or Liveness attacks:
Compromising ⅓–⅔ of the validators will break liveness, but not break safety. What this means is the system stops, but no one will lose funds.
All relaying is fully permissionless and decoupled from security, which allows the liveness of the system to align with the liveness of the auth and base layers (validator sets of source, Axelar and dest). No extra liveness assumptions are introduced.
Number of Nodes down to lose liveness:
⅓ of Axelar’s nodes down to lose liveness. Relaying is permissionless and a tool is being built to allow users to relay messages themselves using their web browser.
Thresholds for multi-party crypto are adjusted via governance. For example either all validators must sign each cross-chain message for Avalanche, 70% of validators. Votes can be weighted by stake or weighted by count.
Node set permissionless?
Yes, via delegated proof of stake.
Nomad
Nomad is an optimistic cross chain protocol where write-oracle “update” transactions are posted on an underlying chain. These updates are verified by “watchers”, who are given 30 minutes to alert for fraudulent updates. Think of it like a cross chain rollup.
Nomad:
Base layer = Messages for cross-chain transfer are queued in a Nomad-deployed data-structure on the source chain. This data-structure is replicated on all destination chains after passing the optimistic time-window. For now, they must always utilise a virtual machine like the EVM.
Auth = Updaters, Watchers and Relayers maintain optimistic consensus, settled on smart contracts on source chain. A message is valid if no watcher rejects the update within 30min of posting, i.e., optimistic consensus.
Transport = Pair-wise connections between chains. All parties maintaining Nomad’s protocol work together to open and maintain a new connection. “Processors” monitor for authenticated messages on the source chain and execute them on the destination chain.
Interface = Nomad works at the smart contract layer. Each application builds its own messaging protocol, and deploys “router” contracts.
Security
There are a few attacks possible on optimistic protocols. They’re mostly around liveness.
Auth layer assessment:
With an especially short proving period of 30 min (compared with 7 days for Arbitrum/Optimism), Nomad is more fragile to these attacks. Nomad is working on an economically incentivised node solution to rectify some of these liveness vulnerabilities. I wonder why not use a PoS validator network from the beginning if you’re going to rely on a set of nodes, but it’s good for the ecosystem to have multiple trees of innovation! Optimistic protocols should be useful in a cross-chain context at some layer in the stack.
I’ve noticed in Nomad’s materials that they distinguish themselves from “externally verified” cross chain models. I disagree with this. The optimistic protocol that the Updaters, Watchers, Relayers and Processors are carrying out is an external process to each connected chain. IBC is the only option on this list which could claim it isn’t “externally verified”. Nomad does utilise “internally verified” smart contracts on the two underlying chains, but extra trust assumptions are introduced with the node set submitting transactions to these contracts.
A 45 min transaction time seems very long to me, especially if we want to build a highly capital efficient financial system. Connext has partnered with Nomad to offer faster execution on token transfers, utilising centralised market makers, but I’d prefer a faster decentralised solution — especially during liquidity squeezes or coordinated attacks such as we’ve seen with Terra recently.
Malicious attacks:
Fraud is possible on the destination chain. A hostile (currently permissioned) updater is able to post a Replica update containing malicious transactions on the destination chain which cannot be falsified. This possibility of fraud is a compromise made in order to reduce gas costs, and Nomad is working on guards for this.
In case the above attack happens, watchers elected by the cross-chain app developers will have time (30min, if caught early) to de-authorise all messages from Nomad to that particular application, hence blocking the execution of hostile messages from these malicious updates. It sounds a bit like app devs need to build a centralised off-switch for every cross-chain app built with Nomad. Sounds censor-ey, but I may be wrong. I also wonder if DDoS etc could censor the set of watchers from providing safety in this case.
Nomad’s protocol currently works only with EVM chains, and in the medium-term, must run via smart contracts on a virtual machine such as CosmWasm or a Substrate Pallet. This means it cannot connect to cosmos chains via IBC, or Polkadot Parachains via the XCM. There are some security and predictability issues with the newer virtual machines, a similar issue was responsible for the Wormhole hack.
DDoS or Liveness attacks:
Optimistic protocols are pretty fragile to censorship, in that a hostile watcher can flag a valid update as fraudulent and thereby prevent it from transacting. This is called “griefing”. Nomad currently solves this by making watchers trusted. Nomad has noted (and I tend to agree) that in its consensus model, a watcher alone can never cause a safety issue, only a liveness issue.
That being said, with Nomad, a liveness issue can break safety. i.e. an attacker can use DDoS or control of this trusted set of watchers as a method to help them push an attack through the system. This crossover between liveness and safety is usually a no no.
A hostile updater could post a fraudulent update just before a network crash, update or failure, then once the network comes back online 31 minutes later, the update would be considered valid on the destination chain. In reality, watchers have had no chance to flag the message. A fix to this is being developed where block height is used instead, see this issue. Block height is slightly less stable for longest chain consensus protocols like proof of work, but it seems like a better option to me than block time.
Number of Nodes down to lose liveness:
Theoretically only 1: the Updater. The updater might be a decentralised network, but in this case why not use a PoS network from the beginning?
1 compromised watcher can break liveness, by griefing.
Node set permissionless?
Permissioned Updaters, Permissioned watchers. Nomad is working on a model for permissionless updaters.
Layer Zero
When it comes down to it, Layer Zero is a 2/2 multisig for cross chain messaging, with a host of application layer software on top of it to assist devs building cross-chain apps.
I see LayerZero primarily as a base layer. It is auth layer agnostic. While in marketing materials they have claimed to be more than they are, the protocol itself nicely highlights a particular part of the auth stack in plain smart contract english. Logic which in other cross-chain models is hidden deep amongst the base layer engineering.
Base = Application-layer software specified by LayerZero.
Auth = Undeclared: 2 of 2 Multisig between the chosen oracle and relayer. Block header (1) and transaction proof + message (2) verification. The application developer elects two parties to handle authentication (like 1. Chainlink, and 2. Bank of America :p ).
Transport = Undeclared: Handled by chosen auth layer. Trusted/trustless based on choice.
Interface = Message format is defined by endpoint smart contracts on source and destination chain.
Security
LayerZero doesn’t declare a Transport layer or an Auth layer, it’s just a Base layer & message Interface. The elected auth layers — the “Oracle” and the “Relayer” — are in an && statement, a 2 of 2 multisig. Safety and liveness characteristics are derived from this.
Auth layer assessment:
The recommended auth layer consists of a decentralized oracle that signs a header and a “relayer” that submits a transaction + proof. LayerZero indicates (but doesn’t insist) ChainLink for the oracle, however ChainLink has a announced a competing product. LayerZero leaves the door open for users/developers to select their relayer, or operate it themselves.
Malicious attacks:
Attacks on LayerZero depend on the security of the chosen Oracle and Relayer. That said, below is an analysis on the use of the 2 of 2 multisig LayerZero uses in comparison with Proof of Stake:
If there is a safety assumption of 51% on the N nodes of the oracle, then the overall safety assumption states that to compromise the system, the adversary must compromise (51% * N) && (1) — that is, the (one) “Relayer.” If the adversary can corrupt 51% of N, it might as well corrupt (51%+1) nodes, especially given it has the option to run its own +1. So the “1” node doing transaction relay doesn’t buy more economic security. Instead, it introduces poorer liveness characteristics, since the whole system loses liveness if one node is compromised. It would be better to change the 2/2 multisig into a 1/1 and to strengthen the oracle’s own security with an extra node. We know Proof of Stake can carry better security and liveness than a multisig (otherwise all these blockchains would be running on simple multisigs!)
Note that there was a recent bridge hack where 5/8 multisig signers were compromised by North Korean hackers. The relayer being trusted and only an oracle for additional security points to this protocol being extremely low security.
DDoS or Liveness attacks:
Attacker has the option to DDoS or otherwise attack the weaker of the Oracle or the Relayer. Successful attack on either will cause a liveness failure. Ideally both Oracle and Relayer are permissionless node sets, in which case a PoS network with cross-chain read and write capability would be better than using L0 anyway.
Number of Nodes down to lose liveness:
Depends on oracle/relayer chosen, possibly 1.
Node set permissionless?
With an undeclared auth layer, this is at the discretion of the application developer. Interestingly, this might make LayerZero a good solution for private companies and regulated institutions who want KYC’ed relayers. However, KYC can easily be added to app itself, rather than at the cross-chain protocol layer.
Conclusion
At the end of the day, discussing cross-chain security, throughput and liveness is just like arguing about types of blockchain consensus. My intuition is that the best auth layer is the same for cross-chain as it is for single-chain: BFT Permissionless Proof of Stake. Other models have different trade-offs, but security and permissionless-ness is the axiom of crypto. IBC should be used wherever possible, and Axelar for any ecosystem which can’t support IBC.
Full disclosure: I’m a community member of Axelar and have received grants from the foundation for contributions there. I am building a cross-chain application and this research was done independently to inform my own project’s choice of cross-chain solution.
