Cracking the interoperability trust problem: how will Web3 and cross-chain bridges ultimately evolve?

Solving the interop trust issue: the future of Web3 and cross-chain bridges.

We will witness the emergence of a “trust mechanism pattern”, where builders will make various trade-offs between usability, complexity, and security.

Original title: “Deciphering the Trust Puzzle of Interoperability”

Written by: Shi Khai Wei, Raghav Agarwal, LongHash Ventures

Compiled by: Kxp

• Analyze the three main characteristics of the Cosmos LSM module: what are the positive implications?
• Blockchain detective ZachXBT sued by “Big Brother Ma Ji”: Received donations of over one million US dollars, supported by CZ and Justin Sun
• Sei Network: The fastest Layer1 public chain on Cosmos designed for trading?

Introduction

Multi-chain is the future trend, and the pursuit of scalability has led Ethereum to the construction of Rollup technology. In the process of turning to modular blockchains, people have once again paid attention to application chains. In the not-too-distant future, we have heard rumors about specific application Rollups, L3 and sovereign chains. However, all of this will come at the cost of fragmentation, and current cross-chain bridges typically have functional limitations and rely on trusted signers to ensure security.

So, what will the interconnected Web3 ultimately look like? We believe that cross-chain bridges will eventually evolve into cross-chain messaging or “Arbitrary Messaging Protocol” (AMP) protocols, unlocking new use cases and allowing applications to pass arbitrary messages between source and target chains. We will also witness the emergence of a “trust mechanism pattern”, where builders will make various trade-offs between usability, complexity, and security.

Each AMP solution must implement two key functions:

• Verification: able to verify the validity of messages from the source chain on the target chain

• Liveliness: able to pass information from the source chain to the target chain

Unfortunately, 100% trustless verification is not realistic, and users must choose to trust code, game theory, humans (or entities), or a combination of these, depending on whether the verification is on-chain or off-chain.

In this article, we will vertically divide the overall interoperability field into two aspects: trust mechanism-based and integration architecture-based.

Trust Mechanism:

1. Trust in code and math: For these solutions, there is on-chain proof that anyone can verify. These solutions typically rely on light clients to verify the consensus of the source chain on the target chain or the validity of state transitions of the source chain on the target chain. Verification via light clients can be made more efficient with zero-knowledge proofs, compressing arbitrarily long computations to be done offline, while providing simple on-chain verification to prove computation results.

2. Trust game theory: When users/applications need to trust third parties or third-party networks to ensure the authenticity of transactions, additional trust assumptions are involved. By adopting permissionless networks and game theory such as economic incentives and optimistic security, the security of these mechanisms can be improved.

3. Trust humans: These solutions rely on the honesty or independence of the majority of validators who pass on different information. In addition to trusting the consensus of the two interacting chains, trust in third parties is also required. The only risk in this case is the reputation of the participating entities. If enough participating entities agree that a transaction is valid, it is considered valid.

It is worth noting that all solutions require some degree of trust in both code and human beings. Any solution with faulty code can be exploited by hackers, and each solution has some human factor in setting up, upgrading, or maintaining the codebase.

Integration Architecture:

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

2. Centralized hub model: A communication channel needs to be established with a central hub to achieve interoperability with all other blockchains connected to that hub.

The peer-to-peer model is relatively difficult to scale because each connected blockchain requires a paired communication channel. Developing these channels may be challenging for blockchains with different consensus and frameworks. However, paired bridges provide more flexibility for custom configurations if needed. Hybrid approaches can also be used, such as using the Inter-Blockchain Communication (IBC) protocol for multi-hop routing through relays, eliminating the need for direct peer-to-peer communication but introducing more complexity in security, latency, and cost.

Trust Code and Mathematics

To rely only on code/mathematics for trust assumptions, a light client can be used to verify the consensus of the source chain on the target chain. A light client/node is software that connects to full nodes to interact with the blockchain. The light client on the target chain typically stores the history (in order) of the source chain block headers, which is enough to verify transactions. Offline proxies (such as relays) monitor events on the source chain, generate cryptographic proof containing the proof, and forward them to the light client on the target chain along with the block header. Since light clients store block headers in order and each block header contains a Merkle root hash that can be used to prove the state, they are able to verify transactions. The following is an overview of the main features of this approach:

Safety

A trust assumption is introduced in the initialization process of a light client. When creating a new light client, it is initialized to a block header from a specific height on the other chain. However, there is a possibility that the provided block header might be incorrect, which could deceive the light client with a forged block header. Once the light client is initialized, no further trust assumptions are introduced. However, it is worth noting that the initialization process relies on a weaker trust assumption, as anyone can verify it. Additionally, there is an liveness assumption for the continuous transmission of information from relayers.

Implementation

The implementation of a light client depends on the availability of the cryptographic primitives required for validation. If connected to the same type of chain, meaning they share the same application framework and consensus algorithm, the light client implementation on both ends will be the same. For example, all Cosmos SDK-based chains use the Inter-Blockchain Communication (IBC) protocol. On the other hand, if connected to different types of chains, 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 Cosmos SDK chains to the Substrate application framework in the Polkadot ecosystem via IBC. This requires using a Tendermint light client on the Substrate chain and adding a “beefy” light client on the Cosmos SDK chain. Recently, they established the first connection between Polkadot and Kusama via IBC.

Challenges

Resource intensiveness is an important challenge. Running pairs of light clients on all chains may be expensive as writes on blockchains are expensive. Additionally, for chains with dynamic validators, running light clients is not feasible.

Scalability is another challenge. The implementation of light clients varies depending on the architecture of the chain, which makes scaling and connecting different ecosystems difficult.

Code vulnerabilities are a potential risk as errors in code can lead to vulnerabilities. For example, the October 2022 BNB chain vulnerability revealed a critical security vulnerability affecting all chains that support IBC.

To address the cost and practicality issues of running paired light clients on all chains, alternative solutions such as zero-knowledge (ZK) proofs can be used to eliminate the need for third-party trust.

Zero-knowledge proofs as a solution for third-party trust

Zero-knowledge proofs can be used to verify the validity of state transitions from the source chain on the target chain. Compared to performing the entire computation on-chain, ZK proofs only perform the verification part of the computation on-chain, while the actual computation happens off-chain. This approach can verify faster and more efficiently than re-running the original computation. Some examples include Polymer Labs’ Polymer ZK-IBC and Succinct Labs’ TeleBlockingthy. Polymer is developing multi-hop IBC to enhance connectivity and reduce the number of required paired connections.

The key aspects of this mechanism include:

Security

Security of zk-SNARKs depends on elliptic curves, while zk-STARKs depends on hash functions. zk-SNARKs may require a trusted setup, including creating initial keys for generating proofs used in verification. The key is to keep the secret of the setup event to prevent transactions from being verified by forging. Once the trusted setup is completed, no further trust assumptions are introduced. Additionally, new ZK frameworks such as Halo and Halo2 completely eliminate the need for trusted setup.

Implementation

There are multiple ZK proving schemes, such as SNARK, STARK, VPD, and SNARG, with SNARK being the most widely adopted currently. Different SNARK proving frameworks, such as Groth16, Plonk, Marlin, Halo, and Halo2, offer trade-offs in proof size, proof time, verification time, memory requirements, and trusted setup requirements. Recursive ZK proofs have also emerged, allowing proof workload to be distributed across multiple computers rather than a single one. To generate validity proofs, the following core primitives must be implemented: the signature scheme used by the verifying verifier, proof that the verifier’s public key is included in the verifying verifier set commitment stored on-chain, and tracking of the verifier set, which may change frequently.

Challenge

Implementing various signature schemes in zkSNARKs requires out-of-domain arithmetic and complex elliptic curve operations, which is not trivial and may require different implementations depending on different chain frameworks and consensus. Auditing ZK circuits is a challenging and error-prone task. Developers need to be familiar with domain-specific languages such as Circom, Cairo, and Noir, or directly implement circuits, both of which may be challenging and may slow down adoption. If proof time and workload are very high, only dedicated teams and dedicated hardware may be able to handle it, which may lead to centralization. Longer proof generation times also lead to delays. Technologies such as Incrementally Verifiable Computation (IVC) can optimize proof time, but many of them are still in the research stage, waiting to be implemented. Longer verification time and workload will increase on-chain costs.

Game Theory of Trust

Interoperability protocols based on game theory can be broadly divided into two categories, depending on how they incentivize honest behavior from participating entities:

The first category is economic security mechanisms, where multiple external participants (such as validators) collaborate to reach consensus and determine the updated state of the source chain. To become a validator, participants need to stake a certain amount of tokens, which may be reduced if malicious activity occurs. In permissionless setups, anyone can accumulate stakes and become a validator. Additionally, economic incentives such as block rewards are provided to validators who follow the protocol, ensuring an economic motivation for honest behavior. However, if the potential stolen amount exceeds the staked amount, participants may collude to steal the funds. Protocol examples that use economic security mechanisms include Axelar and Celer IM.

The second category is optimistic security mechanisms, where the solution relies on the assumption that only a few blockchain participants are honest and follow the protocol rules. In this approach, an honest participant can act as a guarantor. For example, one optimal solution allows anyone to submit fraud proofs. While there are economic incentives, an honest observer may miss a fraudulent transaction. Optimistic rollups also use this mechanism. Nomad and ChainLink CCIP are examples of protocols that use optimistic security mechanisms. In the case of Nomad, observers are able to prove fraud, although they have been whitelisted at the time of writing this article. ChainLink CCIP plans to leverage a fraud-detection network composed of distributed oracle networks, although the implementation of the CCIP fraud-detection network is not yet known.

Security

In terms of security, both mechanisms rely on permissionless participation of validators and observers to ensure the effectiveness of game theory. In economic security mechanisms, funds are more vulnerable to attacks if the staked amount is lower than the potential stolen amount. On the other hand, in optimistic security mechanisms, the assumption of few trusted participants may be exploited if no one submits a fraud proof, or if permissioned observers are compromised or removed. Economic security mechanisms, in contrast, are less dependent on liveness for maintaining security.

Implementation

One implementation method involves an intermediate chain with its own validators. In this setup, a group of external validators monitor the source chain and reach consensus on the validity of transactions upon detection of a call. Once consensus is reached, they provide proof on the target chain. Validators typically need to stake a certain number of tokens, which may be reduced if malicious activity is detected. Protocol examples 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 rollups. These off-chain proxies can submit fraud proofs within a predefined time window and revoke transactions when necessary. For example, Nomad relies on independent off-chain proxies to relay headers and cryptographic proofs. On the other hand, the ChainLink CCIP plan to leverage its existing oracle network to monitor and prove cross-chain transactions.

Advantages and Challenges

A key advantage of AMP solutions based on game theory is resource optimization, as the validation process typically does not occur on-chain, reducing resource requirements. Additionally, these mechanisms are scalable as consensus mechanisms remain the same across various types of chains and can be easily extended to heterogeneous blockchains.

There are also several challenges associated with these mechanisms. If the majority of validators collude, the trust assumption may be exploited to steal funds, necessitating countermeasures such as secondary voting and fraud proofs. Furthermore, optimistic security-based solutions introduce complexity in terms of finality and liveness as users and applications must wait for the fraud window to ensure the validity of transactions.

Trusting Humans

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

1. Reputation-based security: These solutions rely on multisignature implementations where multiple entities validate and sign transactions. Once the minimum threshold is reached, transactions are considered valid. The assumption here is that most entities are honest and if the majority of these entities sign a particular transaction, the transaction is valid. The only risk involved here is the reputation of the participating entities. Some examples include Multichain (Anycall V6) and Wormhole. Vulnerabilities may still exist due to smart contract loopholes, as demonstrated by the Wormhole hack in early 2022.

2. Independence: These solutions divide the entire message-passing process into two parts and rely on different independent entities to manage these two processes. The assumption here is that these two entities are independent of each other and will not collude. LayerZero is an example of this. Block headers are transmitted on demand through a distributed oracle, and transaction proofs are sent through relayers. If the proof matches the header, the transaction is considered valid. While proof matching depends on code/math, participants need to trust that these entities remain independent and have no malicious intent. Applications built on LayerZero can choose their own or hosted oracles and relayers, thus limiting risk to individual oracles/relayers. End users need to trust that LayerZero, third parties, or the application itself are running oracles and relayers independently and without malicious intent.

In both of these approaches, the reputation of the participating third-party entities prevents malicious behavior. These are typically respected entities in the validator and oracle communities who risk reputational damage and negative impacts on other business activities if they behave maliciously.

Other considerations for the AMP solution

When considering the security and availability of the AMP solution, we also need to consider details beyond the basic mechanisms. Since these are components that can change over time, we have not included them in the overall comparison.

Code integrity

Recent hacks have exploited code errors, highlighting the need for reliable audits, bug bounties, and diverse client implementations. If all validators (in the economic/optimistic/reputational security) run the same client (software used for validation), it increases reliance on a single codebase and reduces client diversity. For example, Ethereum relies on multiple executing clients such as geth, nethermind, erigon, besu, akula. Multiple implementations in various languages could increase diversity, with no one client dominating the network and eliminating potential single points of failure. Having multiple clients can also help maintain liveness if a small number of validators/signers/light clients fail due to a bug/attack in a particular implementation.

Setup and upgradability

Users and developers need to know whether validators/observers can join the network in a permissionless way, otherwise trust will be hidden in chosen permissioned entities. Upgrades to smart contracts may also introduce bugs that lead to attacks and potentially change trust assumptions. Different solutions can be implemented to mitigate these risks. For example, in the current instantiation, Axelar gateways can be upgraded but require offline committee approval (4/8 threshold), however, Axelar plans to require collective validator approval for any gateway upgrade in the near future. The core contract of Wormhole is upgradable 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 pushed and dapps with default settings will get updated versions, while dapps with manual settings will need to set them to the new version.

Maximum Extractable Value (MEV)

Different blockchains are unsynchronized with 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 the cross-chain world, MEV is difficult to define precisely. It introduces a trade-off between liveness and execution order. Ordered channels will ensure the ordered delivery of messages, but if a message times out, the channel will be closed. Another application may prefer unordered delivery without affecting the delivery of other messages.

Source Chain Determinism

Ideally, an AMP solution should wait for the source chain to achieve finality before transmitting state information from the source chain to one or more target chains. This would ensure that blocks on the source chain are almost never reverted or changed. However, to provide the best user experience, many solutions offer instant message delivery and make trust assumptions about finality. In this case, if the source chain experiences a state rollback after message delivery and bridging assets, it may lead to double-spending of bridged funds and other situations. AMP solutions can manage this risk in various ways, such as setting different finality assumptions for different chains based on their degree of decentralization or trading off speed and security. Bridges that use the AMP solution can set asset amount limits before the source chain achieves finality.

Trends and Future Outlook Customizable and Attachable Security

AMP solutions are incentivized to offer more flexibility to developers in order to better serve diverse use cases. Axelar has introduced a method for scalable message delivery and verification without changing the application layer logic. HyperLane V2 introduces modules that allow developers to choose from multiple options such as economic security, optimistic security, dynamic security, and hybrid security. CelerIM offers additional optimistic security in addition to economic security. Many solutions wait for a predefined minimum block confirmation on the source chain before delivering messages. LayerZero allows developers to update these parameters. We expect some AMP solutions to 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 suboptimal design architecture? Awareness of the fundamental concepts behind security may become increasingly important for users. Ultimately, we anticipate the aggregation and abstraction of AMP solutions, possibly in the form of combinations or “attachable” security.

Maturity of Trust and Mathematics Mechanisms

In the ideal final stage, all cross-chain messages will be minimized by using zero-knowledge (ZK) proofs. We have seen similar projects such as Polymer Labs and Succinct Labs emerge. Multichain also published a zkRouter white paper on achieving interoperability through ZK proofs. With the recently announced Axelar virtual machine, developers can use the Interchain Amplifier to establish new connections to the Axelar network without permission. For example, once a strong light client and ZK proof for Ethereum’s state are developed, developers can easily integrate them into the Axelar network to replace or enhance existing connections. Celer Network announced Brevis, a ZK cross-chain data proof platform that enables dApps and smart contracts to access, compute, and leverage arbitrary data on multiple blockchains. Celer utilizes ZK light client circuits to implement a user-oriented asset zkBridge for cross-chain between Ethereum Goerli testnet and BNB Chain testnet. LayerZero discusses the possibility of adding new optimized proof message libraries in its documentation. New projects like Lagrange are exploring aggregating multiple proofs from multiple source chains, while Herodotus makes storage proofs possible through ZK proofs. However, this transition takes 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 not optimized. We believe that in the long run, many AMP solutions are likely to combine verifiable software with trusted humans and entities to support highly scalable cross-chain applications on blockchains because:

1. By auditing and offering bug bounties, the possibility of code exploitation can be minimized. Over time, as the history of these systems becomes a proof of their security, trusting these systems will become easier.

2. The cost of generating ZK proofs will be reduced. With more research and development on ZKP, recursive ZKP, proof aggregation, folding schemes, and specialized hardware, we expect that the time and cost of generating and verifying proofs will be significantly reduced, making it a more cost-effective method.

3. Blockchains will become more supportive of ZK. In the future, zkEVM will be able to provide succinct proofs of validity for executions, and light client-based solutions will be able to easily verify the execution and consensus of source chains. In the final stage of Ethereum, there are also plans to “zk-SNARK everything,” including consensus mechanisms.

Proof of Humanity, Reputation, and Identity

Security for complex systems like the AMP solution cannot be encapsulated by a single framework and requires multi-layered solutions. For example, in addition to economic incentives, Axelar also implements a secondary voting mechanism to prevent voting power from being concentrated among a subset of nodes and to promote decentralization. Other proofs of humanity, reputation, and identity can also be used as supplements to setup and permission mechanisms.

Conclusion

In the spirit of Web3 openness, we may see a diverse future with multiple methods coexisting. In fact, applications may choose to use multiple interoperability solutions, either redundantly or allowing users to choose combinations based on trade-offs. Peer-to-peer solutions may be prioritized for “high-traffic” routes, while hub-and-spoke models may dominate the long tail of chains. Ultimately, we as a community of users, builders, and contributors will shape the fundamental contours of the Web3 internet.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!