Author: STANFORD BLOCKCHAIN ​​CLUB. Translated by: Cointime: QDD.

introduction

The future is multi-chain. The quest for scalability led Ethereum to rolling solutions. The move to modular blockchains has reignited interest in application chains. On the horizon, we hear rumors of application-specific rolling solutions, third-layer solutions, and sovereign chains. But this all comes at the cost of fragmentation, and current bridges are often limited in functionality and rely on trusted signing parties for security.

What will the final form of interconnection in Internet 3.0 look like? We believe that bridges will eventually evolve into cross-chain messaging or "Arbitrary Message Passing" (AMP) protocols to unlock new use cases, allowing applications to pass arbitrary messages between source and target chains. We will also see the rise of a "trust mechanism landscape" where builders make various trade-offs in ease of use, complexity, and security.

Every AMP solution requires two key capabilities:

1. Verification: Verify the validity of the source chain message on the target chain.

2. Survivability: the ability to transfer information from the source chain to the target chain.

Unfortunately, 100% trustless verification is unrealistic and users need to trust code, game theory, humans (or entities), or a combination of these, depending on whether verification is done on-chain or off-chain.

In this article, we will divide the overall interoperability landscape vertically and horizontally based on the trust mechanisms and integration architectures used.

Trust Mechanism:

1. Trust in code and math: For these solutions, there are on-chain proofs that can be verified by anyone. These solutions often rely on light clients to verify the consensus of the source chain on the target chain or to verify the validity of the state transition of the source chain on the target chain. Zero-knowledge proofs can make light client verification more efficient to compress arbitrarily long computations offline and provide simple verification on the chain to prove the computation.

2. Trust Game Theory: When users/applications must trust a third party or a group of third parties to guarantee the authenticity of a transaction, there are additional trust assumptions. These mechanisms can be made more secure by combining game theory such as economic incentives and optimistic security through permissionless networks.

3. Trust in humans: These solutions rely on the honesty of the majority of validators or the independence of the entities that pass different information. In addition to trusting the consensus of the two interacting chains, trust in third parties is also required. Only the reputation of the participating entities is involved here. If enough participating entities consider the transaction to be valid, then it is considered valid.

It is important to note that all solutions require trust in both the code and humans to some degree. Any flawed code solution can be exploited by hackers, and every solution has a certain human element in setting up, upgrading, or maintaining the code base.

Integrated architecture:

1. Peer-to-peer model: A dedicated communication channel needs to be established between each source chain and each target chain.

2. Central Hub Model: A communication channel needs to be established with a central hub that connects all other blockchains connected to the hub.

The peer-to-peer model is relatively difficult to scale because each connected blockchain requires a pair of communication channels. Developing these channels can be challenging for blockchains with different consensus and frameworks. However, if necessary, a hybrid approach can be adopted, such as using the Inter-Chain Communication Protocol (IBC) for multi-hop routing through a central hub, which eliminates the need for direct peer-to-peer communication but introduces more complexity in terms of security, latency, and cost.

Trust in code and math

In order to rely only on code/math for trust assumptions, light clients can be used to verify the consensus of the source chain on the target chain. A light client/node is a piece of software that connects to a full node to interact with the blockchain. A light client on the target chain typically stores the source chain block headers (in order), which is sufficient to verify transactions. Similarly, off-chain agents (such as relayers) on the source chain monitor events, generate cryptographic inclusion proofs, and forward them along with the block headers to light clients on the target chain. Since light clients store block headers in order, they are able to verify transactions because each block header contains a Merkle root hash that proves the state. Here is an overview of the key features of this approach:

safety

Trust assumptions are introduced during the light client initialization process. When a new light client is created, it is initialized with a block header at a specific height. However, the provided block header may be wrong, and it is possible to deceive the light client by forging a block header. Once the light client is initialized, no further trust assumptions are introduced. However, it is worth noting that this initialization process relies on a weak trust assumption because anyone can verify it. In addition, the continuity of the relayer is also a trust assumption because it is responsible for transmitting information.

accomplish

The implementation of a light client depends on the availability of the cryptographic primitives required for verification. If the chains being connected are of the same type, i.e. they share the same application framework and consensus algorithm, then the light client implementation will be the same on both sides. For example, all Cosmos SDK-based chains use the Inter-Blockchain Communication (IBC) protocol. On the other hand, if two different types of chains are being connected, such as different application frameworks or consensus types, the light client implementation will be different. An example is Composable Finance, which is working on connecting the Cosmos SDK chain to the Substrate of the Polkadot ecosystem via IBC. This requires adding a Tendermint light client on the Substrate chain and a "strong" light client on the Cosmos SDK chain. Recently, they established the first connection between Polkadot and Kusama via IBC.

challenge

Resource intensity is a significant challenge. Running pairs of light clients on all chains can be expensive because writes on the blockchain are expensive. Additionally, it is not possible to run light clients on chains with dynamic validator sets, such as Ethereum.

Scalability is another challenge. Light client implementations vary based on the chain’s architecture, which makes it difficult to scale and connect different ecosystems.

Code exploits are a potential risk because errors in the code can lead to vulnerabilities. An example is the BNB chain vulnerability in October 2022, which revealed a critical security vulnerability affecting all IBC-enabled chains [1].

To address the cost and practicality of running pairs of light clients on all chains, alternatives such as zero-knowledge (ZK) proofs offer a way to eliminate the need for trust in a third party.

Zero-knowledge proof as a solution to third-party trust

ZK proofs can be leveraged to verify the validity of state transitions on the source chain on the target chain. Rather than performing the entire computation on-chain, only the verification of the computation is performed on-chain, while the actual computation process is performed off-chain. This approach can be faster and more gas-efficient than re-running the original computation. Some examples include Polymer ZK-IBC from Polymer Labs and Telepathy from Succinct Labs. Polymer is developing IBC that supports multi-hops to enhance connectivity and reduce the number of pairwise connections required.

Key aspects of the mechanism include:

safety

The security of zk-SNARKs relies on elliptic curves, while zk-STARKs rely on hash functions. zk-SNARKs may require a trusted setup process where the initial keys for the proofs used in the verification are created. It is critical to keep the keys that destroy the setup event confidential to prevent transactions from being made through forged verifications. Once the trusted setup is complete, no further trust assumptions are introduced. In addition, new ZK frameworks such as Halo and Halo2 completely eliminate the need for a trusted setup.

accomplish

There are various ZK proof schemes such as SNARK, STARK, VPD, and SNARG, with SNARK being the most widely adopted currently. Different SNARK proof frameworks such as Groth16, Plonk, Marlin, Halo, and Halo2 have trade-offs in proof size, proof time, verification time, memory requirements, and the need for a trusted setup. Recursive ZK proofs have also emerged, allowing the proof workload to be distributed across multiple computers instead of just one. In order to generate a validity proof, the following core primitives must be implemented: verifying the signature scheme used by the verifier, including the proof of the verifier's public key in the verifier set commitment stored on-chain, and keeping track of the verifier set, which may change frequently.

challenge

Implementing various signature schemes in zkSNARKs requires implementing out-of-domain arithmetic and complex elliptic curve operations, which is not trivial and may require different implementations for each chain depending on the chain's framework and consensus. Auditing ZK circuits is a challenging and error-prone task. Developers need to be familiar with domain-specific languages ​​like Circom, Cairo, and Noir, or directly implement the circuits themselves, both of which can be challenging and may slow down adoption. If the proof time and effort are very high, only dedicated teams with specialized hardware may be able to handle it, which may lead to centralization. Longer proof generation times can also cause delays. Techniques like incremental verifiable computation (IVC) can optimize proof times, but many of them are still in the research stage and awaiting implementation. Longer verification times and efforts will increase costs on the chain.

Trust Game Theory

Game-theoretic interoperability protocols can be broadly divided into two categories based on how they incentivize honest behavior among participating entities:

The first category is economic security, where multiple external actors (such as validators) collaborate to reach a consensus on the updated state of the source chain. In order to become a validator, participants need to stake a certain amount of tokens, which may be slashed in the event of malicious activity. In a permissionless setting, anyone can accumulate a stake and become a validator. In addition, the economic incentive for validators to follow the protocol is provided in the form of block rewards, ensuring an economic incentive for honest behavior. However, if the potential amount that can be stolen exceeds the staked amount, participants may collude to steal funds. Examples of protocols that use economic security mechanisms are Axelar and Celer IM.

The second category is optimistic security, where the solution is based on the assumption that only a minority of blockchain participants are honest and follow the rules of the protocol. In this approach, a single honest participant can serve as collateral. For example, the optimal solution allows anyone to submit evidence of fraud. Although there is a financial incentive, honest observers may miss fraudulent transactions. Optimistic Roll-ups also adopt this mechanism. Nomad and ChainLink CCIP are examples of protocols that use optimistic security. In the case of Nomad, observers are able to prove fraud, although they are whitelisted at the time of writing. ChainLink CCIP plans to utilize an anti-fraud network composed of a decentralized oracle network to monitor malicious activity, although the implementation of CCIP's anti-fraud network is not yet known.

safety

In terms of security, both mechanisms rely on permissionless participation of validators and observers to ensure game theory validity. In the economic security mechanism, funds are more vulnerable to attack if the staked amount is lower than the potential stealable amount. On the other hand, in the optimistic security mechanism, the assumption of minority trust may be exploited if no one submits fraud proofs or the permissioned observers are compromised or removed. In contrast, the economic security mechanism is less dependent on liveness in maintaining security.

Implementation

In terms of implementation, one approach involves an intermediate chain with its own validators. In this setup, a group of external validators monitor the source chain and reach a consensus on the validity of a transaction when a call is detected. Once consensus is reached, they provide proof on the target chain. Validators are usually required to stake a certain amount of tokens and can be slashed if malicious activity is detected. Examples of protocols using this implementation method include Axelar Network and Celer IM.

Another implementation method involves the use of off-chain proxies. Off-chain proxies are used to implement solutions similar to optimistic roll-ups. Within a predefined time window, these off-chain proxies are allowed to submit fraud proofs and reverse transactions if necessary. For example, Nomad relies on independent off-chain proxies to relay headers and cryptographic proofs. On the other hand, ChainLink CCIP plans to leverage its existing oracle network to monitor and prove cross-chain transactions.

Advantages and Challenges

A key advantage of game-theoretic AMPs is resource optimization, as the validation process typically does not occur on-chain, reducing resource requirements. Additionally, these mechanisms are scalable, as the consensus mechanism remains the same for various types of chains and can be easily extended to heterogeneous blockchains.

These mechanisms also face some challenges. If a majority of validators collude, the trust assumption can be exploited to steal funds, which requires the use of countermeasures such as quadratic voting and fraud proofs. In addition, solutions based on optimistic security introduce complexities in terms of finality and liveness, as users and applications need to wait for the fraud window to ensure the validity of transactions.

Trust in humans

Solutions that require trust in a human entity can also be broadly divided into two categories:

1. Reputation Security: These solutions rely on multi-signature implementations where multiple entities verify and sign a transaction. Once a minimum threshold is reached, the transaction is considered valid. The assumption here is that the majority of entities are honest, and if the majority of these entities sign on a particular transaction, then it is valid. Some examples of this include Multichain (Anycall V6) and Wormhole. Smart contract vulnerabilities can still be exploited, as demonstrated by the Wormhole hack in early 2022.

2. Independence: These solutions split the entire messaging process into two parts and rely on different independent entities to manage the two processes. The assumption here is that the two entities are independent of each other and will not collude. LayerZero is an example. Block headers can be transmitted on demand by a decentralized oracle and transaction proofs are sent through relayers. If the proof matches the block header, the transaction is considered valid. While the proof matching relies on code/math, participants need to trust that these entities can remain independent. Applications built on LayerZero can choose their oracles and relayers (or host their own oracles/relays), which limits the risk of individual oracles/relays colluding. End users need to trust that LayerZero, third parties, or the application itself is running oracles and relays independently and without malicious intent.

In both approaches, the reputation of the participating third-party entities reduces the incentive to act maliciously. They are typically well-respected entities within the validator and oracle communities, and if they behave maliciously, they face reputational consequences and negative impacts on their other business activities.

Beyond the Assumption of Trust: Additional Considerations for AMP Solutions

When considering the security and usability of AMP solutions, we also need to consider details beyond the basic mechanisms. Since these are moving parts that can change over time, we did not include them in the overall comparison.

Code Integrity

Recent hacks that exploited code bugs have highlighted the need for reliable auditing, bug bounties, and diverse client implementations. If all validators (in economic/optimistic/reputational security) run the same client (software used for validation), this will increase dependency on a single codebase and reduce client diversity. For example, Ethereum relies on multiple execution clients such as geth, nethermind, erigon, besu, akula. Multiple implementations in multiple languages ​​could increase diversity without any client dominating the network, eliminating potential single points of failure. Having multiple clients can also help improve liveness, if a few validators/signers/light clients are shut down due to a bug/attack in a specific implementation, other clients are still available.

Setup and Upgradability

Users and developers need to understand whether validators/observers can join the network in a permissionless manner, otherwise trust will be hidden by the permissioned entity chosen. Upgrades to smart contracts may also introduce bugs that lead to attacks or may even change trust assumptions. Different solutions can be implemented to mitigate these risks. For example, in the current instantiation, the Axelar gateway can be upgraded based on offline committee approval (4/8 threshold), however, in the near future, Axelar plans to require all validators to collectively approve any upgrades to the gateway. Wormhole’s core contracts are upgradeable and managed through Wormhole’s on-chain governance system. LayerZero relies on immutable smart contracts and immutable libraries to avoid any upgrades, but new libraries can be rolled out, dApps using the default settings will get updated versions, dApps with manually set versions will need to be set to the new version.

Maximum Extractable Value (MEV)

Different blockchains are synchronized by a common clock and have different finality times. Therefore, the execution order and time on the target chain may vary from chain to chain. In a cross-chain world, a clear definition of MEV is challenging. It introduces a trade-off between liveness and execution order. An ordered channel will ensure the ordered delivery of messages, but if a message times out, the channel will be closed. Another application may prefer no ordering, but it will not affect the delivery of other messages.

Source chain finality

Ideally, an AMP solution should wait for the source chain to reach finality before transmitting state information from the source chain to one or more target chains. This will ensure that blocks on the source chain are almost impossible to reverse or change. However, in order to provide the best user experience, many solutions provide instant messaging and make trust assumptions about finality. In this case, if the source chain rolls back after the message is delivered and the funds are bridged, there may be situations such as double spending of funds. AMP solutions can manage this risk in a variety of ways, such as using different finality assumptions for different chains, weighing speed and security based on the degree of decentralization of the chain. Bridges that utilize AMP solutions can set limits on the number of assets that can be bridged before the source chain reaches finality.

Trends and future prospects

Customizable and increased security

To better cater to different use cases, AMP solutions are incentivized to provide more developer flexibility. Axelar introduced a method for upgradability of messaging and verification without changing the application layer logic. HyperLane V2 introduced modules, allowing developers to choose from multiple options such as economic security, optimistic security, dynamic security, and hybrid security. CelerIM provides additional optimistic security in addition to economic security. Many solutions wait for a predefined minimum number of block confirmations on the source chain before transmitting a message. LayerZero allows developers to update these parameters. We expect that some AMP solutions will continue to provide more flexibility, but these design choices require some discussion. Should applications be able to configure their security, to what extent, and what happens if an application adopts a suboptimal design architecture? User awareness of the basic concepts behind security may become increasingly important. Ultimately, we foresee aggregation and abstraction of AMP solutions, perhaps in the form of some combination or "added" security.

The maturity of the "trust in code and math" mechanism

In the ideal end goal, all cross-chain messaging will minimize trust by using zero-knowledge proofs. We are already seeing this shift emerging with projects like Polymer Labs and Succinct Labs. Multichain has also published a whitepaper called zkRouter for interoperability via ZK proofs. With the recently announced Axelar Virtual Machine, developers can leverage Interchain Amplifier to permissionlessly establish new connections to the Axelar network. For example, once robust light clients and ZK proofs of Ethereum state are developed, developers can easily integrate them into the Axelar network to replace or enhance existing connections. Celer Network announced a ZK cross-chain data proof platform called Brevis, enabling dApps and smart contracts to access, compute, and utilize arbitrary data on multiple blockchains. Celer implemented a user-visible asset zkBridge using ZK light client circuits to bridge between Ethereum Goerli and BNB Chain testnets. LayerZero talks about the possibility of adding new optimized proof message libraries in the future in its documentation. New projects like Lagrange are exploring the possibility of aggregating multiple proofs from multiple source chains, while Herodotus makes storage proofs possible through ZK proofs. However, this transition will take time as this approach is difficult to scale between blockchains that rely on different consensus mechanisms and frameworks.

ZK is a relatively new and complex technology that is difficult to audit, and the current verification and proof generation costs are suboptimal. We believe that in the long run, in order to support highly scalable cross-chain applications on blockchains, many AMP solutions will likely combine trusted human entities with verifiable software for the following reasons:

1. Through audits and bug bounties, the potential for code exploitation can be minimized. Over time, it will become easier to trust these systems as their history serves as proof of security.

2. The cost of generating ZK proofs will decrease. With more R&D on ZKPs, recursive ZK, proof aggregation, folding schemes, and specialized hardware, we expect the time and cost of proof generation and verification to decrease significantly, making it a more cost-effective approach.

3. Blockchains will be more ZK-friendly. In the future, zkEVM will be able to provide concise proofs of the validity of execution, and light client-based solutions will be able to easily verify the execution and consensus of the source chain. In the final stage of Ethereum, it is also planned to "convert everything to zk-SNARK", including consensus.

Humans, Reputation, and Identity

The security of a complex system like the AMP solution cannot be encapsulated by a single framework alone and requires a multi-layered solution. For example, in addition to economic incentives, Axelar has implemented a quadratic voting mechanism to prevent the concentration of voting power in a subset of nodes and promote decentralization. Other human, reputation, and identity proofs can also complement the mechanisms of settings and permissions.

in conclusion

Building on the open ethos of Web3, we may see a future where multiple approaches coexist. In practice, applications may choose to use multiple interoperability solutions, either in a redundant fashion or by allowing users to mix and match with tradeoffs. Peer-to-peer solutions may be prioritized between “high traffic” routes, while hub and spoke models may dominate in the long tail of chains. Ultimately, it is up to us as a community of users, builders, and contributors to shape the landscape of an interconnected Web3.

references

https://forum.cosmos.network/t/ibc-security-advisory-dragonberry/7702 

https://polymerlabs.medium.com/the-multi-hop-ibc-upgrade-will-take-ibc-to-ethereum-and-beyond-b4bee43523e 

https://cointelegraph.com/news/wormhole-hack-illustrates-danger-of-defi-cross-chain-bridges 

https://axelar.network/blog/future-proof-interop-path-adaptability-for-cross-chain-dapps 

https://ethresear.ch/t/hashi-a-principled-approach-to-bridges/14725 

https://twitter.com/MultichainOrg/status/1613830754458533888?s=20&t=MoDGESqOdcjMQDMFQqzTyQ

https://axelar.network/blog/axelar-virtual-machine-future-of-interoperability 

https://twitter.com/CelerNetwork/status/1638330932603109379?s=20

https://axelar.network/blog/axelar-implements-quadratic-voting-with-maeve-upgrade