NewsFlash Articles Data Fundraising BlockBeats Pro

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

Read this article in 34 Minutes

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

Original Title: "Smart Contract Authority Conflicts"

Source: Stanford Blockchain Review

Authors: Shi Khai Wei, Raghav Agarwal

Translation: Kxp, BlockBeats

Introduction

Multi-chain is the future development trend. The pursuit of scalability has led Ethereum to the construction of Rollup technology. In the process of turning to modular blockchains, people are once again paying 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 usually have limitations in functionality and rely on trusted signers to ensure security.

So, what will the interlinked Web3 ultimately look like? We believe that cross-chain bridges will eventually evolve into cross-chain message passing or "Arbitrary Message Passing" (AMP) protocols, unlocking new use cases and allowing applications to pass any message 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 needs to implement two key functions:

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

• Activity: Able to transfer information from the source chain to the target chain.

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

In this article, we will divide the overall interoperability field vertically into two aspects: trust-based mechanisms and integrated architectures.

Trust Mechanism:

1. Trust Code and Mathematics: For these solutions, there are on-chain proofs that anyone can verify. These solutions typically rely on light clients to verify the validity of consensus or state transitions from the source chain to the target chain. Verification through light clients can be made more efficient through zero-knowledge proofs, compressing any length of computation for offline processing, while providing simple on-chain verification to prove the computation result.

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 mechanisms such as economic incentives and optimistic security, the security of these mechanisms can be improved.

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

It is worth noting that all solutions to some extent require trust in both the code and humans. Any solution with faulty code can be exploited by hackers, and each solution has some human factors involved in its setup, upgrade, or maintenance of the code repository.

Integrated Architecture:

1. Point-to-Point Model: It requires the establishment of dedicated communication channels between each source chain and target chain.

2. Centralized Hub Model: It requires the establishment of a communication channel with the central hub to achieve interconnection with all other blockchains connected to the hub.

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

Trust Code and Mathematics

In order 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 a full node to interact with the blockchain. The light client on the target chain typically stores the historical record (in order) of the source chain block headers, which is sufficient to verify transactions. Offline agents (such as relays) monitor events on the source chain, generate cryptographic proofs, and forward them along with the block headers to the light client on the target chain. Since the light client stores block headers in order, each block header contains a Merkle root hash that can be used to prove the state, so they are able to verify transactions. The following is an overview of the main features of this approach:

Security

During the initialization process of the light client, a trust assumption is introduced. 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 may be incorrect, which could deceive the light client through a forged 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 weaker trust assumption, as anyone can verify it. Additionally, there is an liveness assumption for the continuous transmission of information by the relayer.

Implementation

The implementation of a light client depends on the availability of the password primitives required for verification. If the connected chains are of the same type, meaning they share the same application framework and consensus algorithm, then the implementation of light clients 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, the implementation of light clients depends on the support for the cryptographic primitives required for verification. If the connected chains are of the same type, meaning they share the same application framework and consensus algorithm, then the implementation of light clients on both ends will be the same. For example, the Inter-Blockchain Communication (IBC) protocol is used for all Cosmos SDK-based chains. On the other hand, if the connected chains are of different types, such as different application frameworks or consensus types, then the implementation of light clients will be different. An example is Composable Finance, who is working to connect Cosmos SDK chains to the Substrate application framework in the Polkadot ecosystem through 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 through IBC.

Challenge

Resource intensiveness is an important challenge. Running paired light clients on all chains may be expensive, as writes on the blockchain are costly. Additionally, resource intensiveness is an important challenge for chains with dynamic validators. Running paired light clients on all chains may be expensive, as writes on the blockchain are costly. Furthermore, for chains with dynamic validator sets (such as Ethereum), running light clients is not feasible.

Scalability is another challenge. The implementation of lightweight clients varies depending on the architecture of the chain, which makes it difficult to scale and connect different ecosystems.

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

In order to solve 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 proof as a solution for third-party trust

The key aspects of this mechanism include:

Implementation

There are multiple ZK proving schemes, such as SNARK, STARK, VPD, and SNARG. Currently, the most widely used one is SNARK. Different SNARK proving frameworks, such as Groth16, Plonk, Marlin, Halo, and Halo2, provide 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 instead of a single one. To generate a validity proof, the following core primitives must be implemented: the signature scheme used by the verifier, a proof that includes the verifier's public key in the commitment of the verifier set stored on the chain, and tracking the verifier set, which may change frequently.

Challenge

Implementing various signature schemes in zkSNARKs requires implementing out-of-field arithmetic and complex elliptic curve operations, which is not easy and may require different implementations depending on the framework and consensus of different chains. 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 can be challenging and may slow down adoption. If the proof time and workload are very high, only specialized teams and dedicated hardware may be able to handle it, which may lead to centralization. Longer proof generation times can also cause delays. Incrementally Verifiable Computation (IVC) and other technologies can optimize proof time, but many of them are still in the research stage and waiting to be implemented. Longer verification time and workload will increase on-chain costs.

Trust Game Theory

Based on game theory, interoperability protocols can be broadly divided into two categories according to how they incentivize honest behavior from participating entities:

The first type is economic security mechanism, in which 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, and if malicious activity occurs, these tokens may be reduced. In a permissionless setting, anyone can accumulate stakes and become a validator. In addition, economic incentives such as block rewards are provided to validators who follow the protocol, ensuring economic motivation for honest behavior. However, if the potential stolen amount exceeds the staked amount, participants may collude to steal funds. Examples of protocols using economic security mechanisms include Axelar and Celer IM.

The second type is optimistic security mechanism, 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 proof of fraud. Although there are economic incentives, an honest observer may miss a fraudulent transaction. Optimistic Rollups also adopt 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. The CCIP plan to use a fraud detection network composed of distributed oracle networks to monitor malicious activity, although the implementation of the CCIP fraud detection network is not yet known.

Security

In terms of security, both mechanisms rely on the unlicensed participation of validators and observers to ensure the effectiveness of game theory. In economic security mechanisms, if the pledged amount is lower than the amount that could be stolen, funds are more vulnerable to attack. On the other hand, in optimistic security mechanisms, if no one submits proof of fraud or licensed observers are compromised or removed, a few trusted assumptions may be exploited. In contrast, economic security mechanisms are less dependent on activity for maintaining security.

Implementation

In terms of implementation, one 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 when called upon. Once consensus is reached, they provide proof on the target chain. Validators typically need to stake a certain amount of tokens, which may be reduced if malicious activity is detected. Examples of protocols using this implementation method include Axelar Network and Celer IM.

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

Advantages and Challenges

One key advantage of the AMP solution for game theory is resource optimization, as the verification process typically does not occur on-chain, thereby reducing resource requirements. In addition, these mechanisms are scalable, as the consensus mechanism remains unchanged for various types of chains and can be easily extended to heterogeneous blockchains.

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

Trust Humans

The solutions that require trust in human entities can be broadly divided into two categories:

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

2. Independence: These solutions divide the entire message delivery 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, while transaction proofs are sent through a relay. If the proof matches the header, the transaction is considered valid. Although proof matching relies on code/mathematics, 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/relays, thus limiting the risk to individual oracles/relays. End users need to trust that LayerZero, third parties, or the application itself are running oracles and relays independently and without malicious intent.

In these two methods, the reputation of the third-party entities involved will prevent malicious behavior. These are usually respected entities in the validator and oracle communities, and if they behave maliciously, they run the risk of reputation damage and negative impact on other business activities.

Trends and Future Outlook

可定制并可附加的安全性

translates to

Customizable and attachable security

In order to better serve diverse use cases, the AMP solution is motivated to provide more flexibility to developers. Axelar has introduced a method for achieving scalability in message passing 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 provides additional optimistic security in addition to economic security. Many solutions wait for a pre-defined 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 offer more flexibility, but these design choices require some discussion. Should applications be able to configure their security, to what extent, and what happens if the application adopts suboptimal design architecture? Awareness of the basic concepts behind security may become increasingly important for users. Ultimately, we anticipate the aggregation and abstraction of AMP solutions, possibly in the form of a combination or "add-on" security.

"Trust Code and Mathematics" Mechanism Maturity

At the ideal final stage, all cross-chain messages will be achieved with minimal trust by using zero-knowledge (ZK) proofs. We have seen similar projects such as Polymer Labs and Succinct Labs emerge. Multichain has also released a whitepaper on zkRouter, which achieves interoperability through ZK proofs. With the recently announced Axelar virtual machine, developers can establish new connections to the Axelar network without permission using the Interchain Amplifier. For example, once a strong light client and ZK proof are developed for Ethereum's state, developers can easily integrate them into the Axelar network to replace or enhance existing connections. Celer Network has announced Brevis, a ZK cross-chain data proof platform that allows dApps and smart contracts to access, compute, and utilize arbitrary data on multiple blockchains. Celer uses 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 for the future. New projects like Lagrange are exploring the aggregation of 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. The current cost of verification and proof generation is not optimized. We believe that in the long run, to support highly scalable cross-chain applications on the blockchain, many AMP solutions are likely to combine verifiable software with trusted humans and entities, because:

1. Through auditing and bug bounties, the possibility of code exploitation can be minimized. As time goes on and the history of these systems becomes a testament to their security, trusting these systems will become easier.

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

3. Blockchain will become more supportive of ZK. In the future, zkEVM will be able to provide concise proofs of the validity of execution, and solutions based on light clients will be able to easily verify the execution and consensus of the source chain. In the final stage of Ethereum, there are also plans to "zk-SNARK everything", including the consensus mechanism.

Proof, Reputation, and Identity of Humans

The security of 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 subsets of nodes and promote decentralization. Other forms of human proof, reputation, and identity verification can also serve as supplements to the setup and permission mechanisms.

Conclusion

In the spirit of openness in Web3, we may see a diverse future with multiple methods coexisting. In fact, applications can choose to use multiple interoperability solutions, either redundantly or by allowing users to combine them based on trade-offs. Between the "high traffic" routes, peer-to-peer solutions may be prioritized, while the center and radiation model may dominate the long tail of the chain. Ultimately, as a community of users, builders, and contributors, we will shape the fundamental appearance of the Web3 internet.