Motivation

Recently, the number of chains and roll-ups has increased due to SDKs that easily build blockchains like Cosmos SDK, Avalaunch Subnet, and Rollup as a Service like Caldera. In such a situation, I feel that the importance of cross-chain communication such as token Bridge, and people's attention to it is increasing.

However, discussions in articles and at conferences frequently involve terms related to cross-chain communication—such as Interoperability, Bridge, and Messaging. These terms, however, tend to be used in an ambiguous manner, leading to potential misunderstandings in discussions among various stakeholders.

Moreover, there appears to be a limited understanding among individuals regarding the intricacies and the existing issues within cross-chain communications. This is evident from the simplistic solutions often proposed, such as "Wouldn't LayerZero be sufficient?" or "Isn't IBC effective?" This suggests that there might be underlying challenges that are not yet fully understood or addressed.

Therefore, in this article, I would like to write about

1. Check terminologies used in the context of cross-chain communication

2. Trilemma in cross-chain communication

3. Complication of cross-chain

4. The future of cross-chain considering the causes of complexity

Check terminologies

I have already used the term Cross-chain, but this time I refer to a different blockchain or roll-up (please ask Jon for the definition of roll-up...). From now on, I will call the chain that sends in cross-chain communication as Src chain and the chain that receives as Destination chain.

First of all, Interoperability refers to the ability to communicate cross-chain, and it can be hierarchized as shown in the figure below, I will explain each hierarchy.

Messaging Layer

The Messaging Layer, also known as Messaging or Arbitrary Messaging Bridges (AMB), refers to the ability to send arbitrary data (often referred to as Message or Packet). Among them, it can be divided into a Transport Layer that establishes a secure connection between chains and a Verification Layer that verifies actual cross-chain communication. In the case of IBC, the Messaging Layer itself seems to be expressed as the Transport Layer, but in this article, Transport Layer and Verification Layer are deliberately defined separately, which will be described in detail later.

Application Layer

The Application Layer is a layer that deals with actions to be performed in actual cross-chain communication, specifically, it can be divided into a Token Bridge that sends FT across chains, a NFT Bridge that sends NFT across chains, and a specific function on the Destination chain. It can be divided into Interchain Account etc. that execute. In IBC, the Token Bridge is standardized as ICS-20, the NFT Bridge is ICS-721, and the Interchain Account is ICS-27. It is standardized as, and LayerZero also standardizes the Token Bridge as Omni-chain FT (OFT).

And especially for Token Bridge, it is necessary to pay attention to the fact that there is another element. That is the Liquidity Network. Token Bridge refers to a method that executes token transmission cross-chain without providing liquidity, often called Liquidity-less. There are two methods, a Lock-mint method that deposits assets in the Src chain's smart contract and mints new ones in the Destination chain, and a Burn-mint method that burns assets in the Src chain and mints new ones in the Destination chain. The former is often used for sending Native Tokens between L1 and L2 like the Token Bridge of $ETH of Arbitrum<>Ethereum. The latter is still small in number, and the representative one is CCTP (Cross-Chain Transfer Protocol) which performs Token Bridge by Burn-mint for USDC provided by Circle.

However, Liquidity Network is a method that sends cross-chain tokens using the same assets (strictly speaking, different assets are not a problem) with liquidity in the Src chain and the Destination chain, and many people will call this Bridge.

For example, when a user sends USDC to the Src chain, the fact that USDC was sent to the Src chain is communicated to the Destination chain through Messaging, and the Destination chain that received it sends USDC to the user based on that information.

This can be said that LayerZero is a Messaging Layer and Stargate is a Liquidity Network of the Application Layer.

Lifecycle of cross-chain communication

Here we will check the basic flow of cross-chain communication. The rough flow is as follows.

1. Send a cross-chain communication request to the Endpoint contract of the Src chain

   1. The user sends the asset to be bridged

   2. Send a message from the contract

2. The Endpoint contract issues an event containing the Message, and an Off-chain actor receives the event and sends the Message to the Destination chain The Off-chain actor here refers to various things such as a Relayer that carries the Message and a unique network that verifies the Message, but the Relayer is almost a necessary actor

3. Verify the Message or the signature of the unique network on the Destination chain

4. If the verification is successful, pass the Message or Token to the user

The Relayer is an important factor that realizes cross-chain communication and has a role in sending the Message received from the Src chain to the Destination chain.

In this, only 2 is done Off-chain, and there is a design space in 2 and 3. This is because it is necessary to confirm whether the Message sent from the Src chain is correct.

Interoperability Trilemma

The Interoperability Trilemma is an important material to explore the causes of cross-chain complexity and is composed of Generalization, Trustless, and Extensibility.

Generalization

This refers to whether you can handle any data. In the case of protocols that have a Messaging Layer like IBC and LayerZero, this is met, and protocols that only do Token Bridge do not meet this condition. Since I will not describe the Token Bridge in detail in this article, you don't have to worry so much.

Trustless

This refers to whether the additional trust assumption (Additional Trust Assumption) has been minimized (so it is sometimes called Trust-minimized).

A trustworthy third party is required to realize Interoperability, and this is often called an additional trust assumption (Additional Trust Assumption). In the case of a trusted third party (Trusted third-party), it is easy to recall centralized institutions such as CEX, but in this article, I want to trust a unique network like Chainlink rather than trust like CEX, so I use the term Trusted third-party. Instead, I use the term Additional Trust Assumption.

Based on this, the ideal state of Trustless refers to not depending on security other than the chain that is communicating. The Relayer mentioned in the life cycle of cross-chain communication above is just sending a message, so it does not fall under the Additional Trust Assumption. Actors that verify Messages often fall under the Additional Trust Assumption.

In addition, there are important concepts when considering Trustless. That is Cluster and Client diversity.

Cluster

A cluster is a set of domains that share security and can communicate with each other in a trust-minimized manner. It can provide Trustless Interoperability within a specific ecosystem (Intra-cluster) but requires Additional Trust Assumption to realize Interoperability between ecosystems.

For example, IBC uses Tendermint, Polkadot's XCM, Avalanche Warp Messaging (AWM) for communication between Avalanche Subnets, etc.

Client Diversity

This refers to the diversity of chains and roll-ups for each consensus algorithm and state commitment mechanism. To aim for Trustless among them, it is necessary to provide Interoperability according to that diversity. [1]

Extensibility

This refers to whether it can be applied to all chains and roll-ups. In this definition, it is defined as "all", so it is very easy to apply within the Intra-cluster such as IBC and XCM, but it is difficult to cross the ecosystem.

Especially in the Messaging Layer, Trustless and Extensibility are trade-offs, and realizing Extensibility while maintaining Trustless can be said to be one of the goals of Interoperability.

Complication of Interoperability

So far, I have explained the explanation of terms related to cross-chain and the trilemma of Interoperability. Here, I will think about the reason why today's Interoperability has become more complex, touching on the Interoperability of the past.

Previous Interoperability

In this case, I will refer to the pre-2021 period. This is because I felt that there were significant changes around 2022/2023 and because I started studying blockchain in 2022 and may not have a high resolution before 2021.

Previously, Interoperability within the ecosystem was limited to Cosmos, Polkadot, or between Ethereum and L2, etc., and was mostly L1 to L1 Interoperability across ecosystems. Therefore, we feel that in many cases, Interoperability was achieved by intermediate networks that require Additional Trust Assumption. These intermediate chains were monolithic networks with their own Application Layer and Messaging Layer.

In L1 to L1 communication, if the signature on the block header could be verified, Light Client verification like IBC could be performed, but in practice, it was not possible to communicate at high frequency due to the very high cost of on-chain verification (e.g. Near<>Ethereum). Therefore, the image was more focused on Extensibility rather than Trustless.

Interoperability Today

Today, especially from 2022 to 2023, it is estimated that three major factors contributed to the complexity of the Interoperability issue.

1. Development of off-chain computation

2. Modularization of Interoperability

3. Increase and modularization of Rollups and Chains

Development of Off-chain computation

Off-chain computation (Verifiable computation) such as ZKP and TEE are now used in the blockchain domain to reduce verification costs such as block header signatures. This has increased the practicality of Light Client verification and promoted efforts to become trustless while maintaining extensibility. In other words, the Verification Layer has moved away from proprietary networks such as Multisig and PoS in favor of more cryptographic approaches, increasing implementation complexity.

ex. Composable Finance and Electron Lab zkIBC, Datachain’s LCP (using TEE)

Modularization of Interoperability

Especially in 2023, Modular approaches to Interoperability itself are increasingly being referred to, fueled by the Modular Blockchain. As mentioned in the previous section, the terminology is broadly divided into the Application Layer, Transport Layer, and Verification Layer, and the approaches of each layer have become more diverse.

Application Layer.

In particular, Token Bridge has diversified into Burn-mint, Lock-mint, Liquidity Network, etc. In the Liquidity Network, the trilemma [1], further complicates the problem. There are efforts to make xERC20 and OFT use existing tokens in various chains, but each has its standard, and there is competition for standards. [2]

Transport Layer.

IBC, LayerZero, etc. are not unified, as each protocol has its chain connection method and Message format. As a result, the specifications for how to specify the Destination chain, how to send a message, and whether or not acknowledgment is required are different for each, which is a very confusing situation for developers.

Polymer is working on a project to extend IBC (especially Transport Layer) to L2, which may greatly contribute to the unification of Transport Layer.

Verification Layer.

Even though trustless verification methods differ from ecosystem to ecosystem (intra-cluster), the current Modular Blockchain is a complex interplay of clusters, with each chain and roll-up using a different module. The specific complexity is explained in the next section.

As described above, each layer has its own set of problems, and it is very difficult to solve them all together in one network, so each layer must be solved individually. However, this makes the problem more complicated.

Rollups and Chains Increasing and Modularizing

As mentioned briefly above, the trend toward Modular Blockchain and App-specific chains/rollups is currently accelerating. This not only causes the number of Rollups and Chains to increase, but also forms more complex Clusters, especially in Rollups, as each Rollup can freely decide Execution, Settlement, and Data Availability.

This complex Cluster formation makes it difficult to provide a generic trustless communication method such as Tendermint in IBC.

For example, assume the following three Rollups

Rollup A: Settlement and DA are Ethereum

Rollup B: Settlement is Ethereum and DA is Celestia (using blob stream)

Rollup C: Settlement belongs to Rollup and DA is Celestia (Sovereign Rollup)

Since A and B share the same Settlement, trustless communication is possible by utilizing the state root, etc. posted in the Settlement. In addition, since both B and C have Celestia DAs, trustless communication is possible by using Celestia's Light Node. (Strictly speaking, it is more correct to say that the Finality of Rollup can be secured Trustless since only the Finality of Rollup is secured before the Proof is submitted to the Settlement Layer)

However, in the case of A and C, there is no shared part, so it is necessary to use a third party.

Although we do not refer to it deeply here, if A and C share a Sequencing Layer in Shared Sequencer, the network of Shared Sequencer (), they can communicate with each other with a smaller trust, although there is a trust of the network itself.

Thus, today, each Rollup does not exist in the same ecosystem, and each layer may be partially covered or not covered at all, making it very difficult to provide optimal verification methods and increasing complexity.

With the advent of advanced off-chain computation such as ZKP and TEE, the modularization of Interoperability itself, and the increase of Rollups and Chains and their modularization, the optimization of each layer of Interoperability, especially the optimization of each layer of Interoperability, especially the Verification Layer, has become very difficult and complex.

The Future of Interoperability

So far, we've discussed the issues of interoperability such as the interoperability trilemma and the increased complexity of solving it. Here, based on these situations, I'll express my own thoughts on how interoperability will evolve in the future.

Application Layer

For FT, it will likely shift from Liquidity Bridge to Liquidityless. Already in the Cosmos ecosystem, thanks to ICS-20, it has become Liquidity-less, but in the EVM series, Liquidity Bridge is still mainstream, so the momentum of Liquidity-less will likely increase in the future.

There are two reasons for this. One is that with the advent of CCTP, the burn-mint USDC Bridge has gradually become popular. The other is that efforts are being made to use xERC20 or LayerZero's OFT to use existing tokens on various chains, each of which has its standard, and competition for standards is being carried out. [3]

Transport Layer

The Transport Layer will diversify as long as other Messaging protocols come out, so I don't think it will be unified for a while. I think the IBC's Transport Layer is sophisticated, but the reason why it has not been adopted in the same way in EVM chains or rollups is probably due to two reasons.

One is that IBC has hardly been applied to EVM chains or rollups and it is not clear whether it will work in the same way as in the case of the Cosmos ecosystem. The other is that the current Cross-chain is mostly Token Bridge, so the strengths of Transport are not fully utilized.

As for the former, LCP and Polymer are supposed to realize it, so I look forward to the future. Regarding the latter, I think that the strengths of the Transport Layer, such as Packet forward middleware, will not be demonstrated until the acceleration of app-specific chains/rollups and their interaction level progresses.

Verification Layer

In the Verification Layer, modular interoperability that provides appropriate verification methods for each ecosystem will likely become more popular. Already, Hyperlane, LayerZero, and Axelar VM have this concept, but this year I expect this trend to accelerate even more. As a result, endpoints sending messages can freely choose the verification method, which allows for optimal communication between rollups.

And in terms of verification methods, ZK Coprocessors such as Axiom, Lagrange, and Herodotus will likely attract more attention. These are protocols that offload expensive computations, and by using them for verification in modular interoperability (actually, there are various things such as consensus verification and STF verification), more secure communication can be realized.

On the other hand, considering that the proof generation time is long and the verification cost is still a bit high, there are more cases where ZK Coprocessor is adopted as a sub-method rather than the main method. For example, Brevis's coChain returns a calculation result once with PoS, then sets a certain period of Challenge window, and during that period, a Fraud Proof against PoS can be submitted as a ZKP. This method is also used in Layer N and others, and I predict that many projects will adopt this method for a while.

Although we haven't touched on it much here, in rollups, actors such as Shared Sequencer and Shared Prover are also involved in Cross-chain, and there are many Cross-chain solutions. It is necessary to realize Trustless communication while taking into account these methods.

Other

Intent Layer

An Intent Layer will appear above the Application Layer, making it possible for users to execute Token Bridges without executing transactions. This reduces the burden of gas charges for users and allows Token Bridge to be implemented by signing, so users don't have to be aware of the chain (Chain Abstraction [4]).

This layer includes Anoma and SUAVE, which will function as a shared mempool that is not tied to one chain.

Permissionless deployment

Hyperlane implements a feature called Permissionless deployment, which allows applications and chains to implement Messaging and Token Bridge on top of it, in addition to being deployed by the Hyperlane team. This was not in the EVM series and should be very useful for new rollups, etc.

However, in the case of Hyperlane, the default security is isolated PoS for each network, so the Additional Trust Assumption is a problem.

Conclusion

In this article, I explored the terminology related to Cross-chain, such as Interoperability, Bridge, and Messaging, the interoperability trilemma, and the reasons for the increased complexity of solving it, and expressed my thoughts on what kind of future will come based on that.

Especially due to the impact of Modular Blockchain and App-specific chain/rollup, the increase in Chain and Rollup and the complex intertwining of the ecosystem resulted in the diversification of Trustless verification methods, which is considered to be a major factor in complexity. Therefore, it is difficult to solve it comprehensively with one protocol.

Among them, what I think is most important is not the communication within the ecosystem of Polygon CDK or OP Stack, but the communication between the Rollup of Polygon CDK and OP Stack. I feel there is plenty of room for design in these communications, and I think it would be great if I could propose.

Lastly, I am currently developing Futaba, an infrastructure for obtaining Cross-chain data. I posted the document and contact information here, so if you are interested, please contact me.

Also, I am currently thinking of a Token Bridge using Futaba, so I would be happy if anyone interested in it could contact me.

References

[1] https://www.youtube.com/watch?v=o3BYfEMbUzM

[2] https://www.dropbox.com/s/gf3606jedromp61/Delta-Solving.The.Bridging-Trilemma.pdf?dl=0

[3] There was a dispute over each Messaging protocol for deploying wstETH to other chains.https://research.lido.fi/t/wormhole-x-axelar

[4] https://medium.com/connext/introducing-chain-abstraction-9b8f6e4dc31a