A brief analysis of different cross-chain projects and their use cases

I thought it would be useful to give a broad overview of the architectural landscape of various types of cross-chain projects before I delve into the designs of individual cross-chain projects.

Everybody loves Synapse/IBC, and everyone has heard of Multichain/Hop, but how are they different and why is it important to understand them?

Blockchains face an interoperability trilemma between universality, trustlessness, and scalability. It is often said that decentralization is not important to users, and there is nothing wrong with that, but when it comes to communication between different blockchains, it is crucial to ensure that malicious parties cannot easily steal users' funds, especially with the development of cryptocurrencies, avoiding similar things has long become a focus of developers.

I've heard a good point before that in a new space like cryptocurrency, protocols and validators naturally have a good relationship because the space is still small, but over time, as the space continues to grow, the opportunities for malicious parties to do evil will also increase accordingly.

As I mentioned before, communication between blockchains and even rollups is easy to achieve because it is all guaranteed by the underlying blockchain.

A previous article mentioned that there are three main types of cross-chain projects, and I agree with his point of view.

The first type of cross-chain projects, such as Synapse, Multichain, Thorchain, etc., all rely on MPC (Multi-party secure computation), which means that Synapse has their own validators for verifying transactions between blockchains. Of course, there are subtle differences between all of these cross-chain projects, such as Thorchain using native assets, but their architecture is roughly the same. This model makes it easy for users to quickly build bridges between chains. However, it comes with a big trust assumption. Traditional blockchains are trustless because they have the same security model, and for these cross-chain projects, in addition to the two blockchains passing transactions between each other, you also have to trust the MPC validator group, which is Thorchain/Synapse. Of course, there are ways to improve their security, such as Thorchain requiring validators to bond twice the amount of Rune they verify, but it still has certain risks. This involves the risk of smart contracts, as we have recently seen with the security risks of protocols such as Multichain/Wormhole.

Equivalent to the first type of cross-chain projects, Cosmos and IBC have a different model in terms of architecture. Rather than saying that there is an intermediary between different blockchains, it is better to say that the blockchain itself verifies the transaction from another blockchain. Rather than trusting the security model of external validators, it is better to trust it because the chain itself is the validator.

The downside to this type of cross-chain project is that it does require custom configuration. Like IBC, it only works with chains that reach final consensus quickly and custom light clients set up to achieve this goal. Considering the many different consensus models such as Tendermint, Snowball, PoW, Nightshade, etc., you can imagine that using this type of cross-chain project requires a lot of extra work.

There is a third category, which I haven't really thought about well, but essentially you can have a system where transactions on the chain are verified by the counterparty. So the main assumption is that as long as the validators on two independent chains don't collude, then the system is trustless, such as Hop/Connext between L2 (second layer network). The disadvantage of this is that it is difficult to call cross-chain smart contracts on this basis.

Outside of these three categories, there are other categories of cross-chain projects that are trying different models.

For example, L0 (Layer Zero) tries to be a bridge rather than a chain infrastructure, so it is more plug-and-play, so everyone doesn't have to do their own custom architecture. The premise of L0 is that you choose your security properties, so you can choose the oracle/relayer you want to use, so that you can choose the security trade-offs you want to create as an application.

You can imagine how much this helps a project like IBC, because despite the trustless nature of its design, it seems that its biggest hurdle is creating custom light clients based on the consensus model on various chains.

Nomad is trying to enable cross-chain communication by emulating an optimized design that has low gas fees, uses cryptography with fraud proofs, but also takes into account the tradeoff of several hours of latency for the model. So instead of relying on external validators, you have an off-chain observer that flags fraudulent transactions when necessary, while allowing communication to go through.

There is an interesting debate going on right now about these projects as to how much or if they care about modular security features. However, you can imagine that in a modular architecture like L0, similar to volition/validium with ZKR, different applications might choose to make different security tradeoffs for different applications. For example, if you developed an application that wanted to use a simple bridge that didn’t need to transfer a lot of value and just called contracts on other chains, then an MPC like Synapse would work well. Whereas if you were a large enterprise and you wanted to invest resources because you were moving a lot of value between chains, then an architecture like IBC would appeal to you. Like I mentioned before, I want to dive deeper into specific architectures like IBC/Nomad and others in more depth, but I thought this post would help outline my understanding of them.