How does an in-depth interpretation of arbitrary messaging protocols solve the interoperability trust problem?

Question

Original Author: Shi Khai Wei, Raghav Agarwal

Original compilation: Kxp, BlockBeats

Introduction

Multi-chain is the future development trend, and the pursuit of scalability has led Ethereum to the construction of Rollup technology. In the move to modular blockchains, attention has once again been paid to Lisk. And in the not-too-distant future, we hear rumors about application-specific Rollups, L3s, and sovereign chains. But this will all come at the cost of fragmentation, and current cross-chain bridges are often limited in functionality and rely on trusted signers for security.

So, what will the connected Web3 ultimately look like? We believe that cross-chain bridges will eventually evolve into cross-chain messaging or "Arbitrary Messaging" (AMP) protocols to unlock new application scenarios, allowing applications to pass arbitrary messages between the source chain and the target chain. We will also witness the emergence of a "trust mechanism landscape", where builders will make various trade-offs between usability, complexity, and security.

Every AMP solution needs to implement two key functions:

Verification: Ability to verify the validity of messages from the source chain on the target chain
Liveness: the ability to pass information from the source chain to the target chain

Unfortunately, 100% trustless verification is not realistic, 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 paper, we vertically divide the overall interoperability domain into trust-based mechanisms and integration-based architectures.

Trust mechanism:

Trust code and math: For these solutions, there is an on-chain proof that anyone can verify. These solutions usually rely on light clients to verify the consensus of the source chain on the target chain or verify the validity of the state transition of the source chain on the target chain. Verification through light clients can improve efficiency through zero-knowledge proofs, compressing arbitrarily long calculations to be performed offline, while providing simple on-chain verification to prove calculation results.
Trust Game Theory: When a user/application needs to trust a third party or third-party network to guarantee the authenticity of a transaction, additional trust assumptions are involved. The security of these mechanisms can be improved by employing permissionless networks and game theory such as economic incentives and optimistic security.
Trust in humans: These solutions rely on the honesty or independence of a majority of validators, who communicate different information. In addition to trusting the consensus of the two interactive chains, you also need to trust a third party. In this case, the only risk is the reputation of the participating entities. A transaction is considered valid if enough participating entities agree that it is valid.

It’s worth noting that all solutions require trust in code and humans to some degree. Any solution with buggy code can be exploited by hackers, and every solution has some human element in the setup, upgrades, or maintenance of the codebase.

Integrated architecture:

Point-to-point model: A dedicated communication channel needs to be established between each source chain and target chain.
Central hub model: A communication channel with the central hub needs to be established to achieve interconnection with all other blockchains connected to the hub.

The peer-to-peer model is relatively difficult to scale because each connected blockchain requires a paired communication channel. Developing these channels can be challenging for blockchains with different consensus and frameworks. However, paired bridges offer more flexibility to customize the configuration if desired. Hybrid approaches are also possible, such as multi-hop routing through relays using the Inter-Blockchain Communication (IBC) protocol, which removes the need for direct peer-to-peer communication, but introduces more complexities in terms of security, latency, and cost.

Trust 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. Light clients/nodes are software that connect to full nodes to interact with the blockchain. Light clients on the target chain typically store a history (in order) of source chain block headers, which is sufficient to verify transactions. An off-chain proxy (such as a relay) monitors events on the source chain, generates cryptographic proofs of inclusion, and forwards them along with block headers to light clients on the target chain. Since light clients store block headers sequentially, each containing a Merkle root hash that can be used to prove state, they are able to verify transactions. Here is an overview of the main features of this approach:

safety

Trust assumptions are introduced during the initialization of light clients. When creating a new light client, it will be initialized to a block header from a specific height on the other chain. However, there is a possibility that the provided block headers may be incorrect, making it possible to fool light clients with forged block headers. Once a 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, since it can be verified by anyone. In addition, there is a liveness assumption for the relay's continuous transmission of information.

implement

The implementation of light clients depends on the availability of the cryptographic primitives required for authentication. If the same type of chains are connected, meaning they share the same application framework and consensus algorithm, the light client implementations at both ends will be the same. For example, all Cosmos SDK-based chains use the Inter-Blockchain Communication (IBC) protocol. On the other hand, implementations such as light clients depend on support for the cryptographic primitives required for authentication. If the same type of chains are connected, i.e. they share the same application framework and consensus algorithm, then the light client implementations on both sides 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 two different types of chains are connected, such as different application frameworks or consensus types, the light client implementation will be different. An example is; Composable Finance, who are working on connecting the Cosmos SDK chain to the Polkadot ecosystem's Substrate application framework via IBC. This requires a Tendermint light client on the Substrate chain and a "beefy" light client on the Cosmos SDK chain. Recently, they established the first connection between Polkadot and Kusama via IBC.

challenge

Resource intensity is an important challenge. Running pairs of light clients on all chains can be expensive because writes on the blockchain are expensive. Furthermore, resource intensiveness with dynamic verifiers is an important challenge. It can be expensive to run paired light clients on all chains because writes on the blockchain are expensive. Also, for chains with dynamic validator sets (like Ethereum), it is not feasible to run light clients.

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

Code vulnerabilities are a potential risk because bugs in the code can lead to vulnerabilities. For example, the October 2022 BNB chain breach revealed a critical security flaw affecting all IBC-enabled chains.

To address the cost and practicality of running pairwise light clients on all chains, alternative solutions such as zero-knowledge (ZK) proofs can be employed to remove 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 of 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 allows for faster and more efficient verification than re-running the original computation. Some examples include Polymer Labs'; Polymer ZK-IBC; and Succinct Labs'; Telepathy. Polymer is developing multi-hop IBCs to enhance connectivity and reduce the number of paired 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, including the creation of initial keys used to generate proofs used in verification. The key is to destroy the secret of the setup event to prevent transactions from being authenticated by forgery. Once the trusted setup is complete, no further trust assumptions are introduced. Additionally, newer ZK frameworks (like Halo and Halo;2;) completely remove the need for a trusted setup.

implement

There are a variety of ZK proving schemes, such as SNARK, STARK, VPD and SNARG, and SNARK is currently the most widely used. Different SNARK proving frameworks, such as Groth;16, Plonk, Marlin, Halo, and Halo;2;, offer tradeoffs in terms of proof size, proof time, verification time, memory requirements, and trusted setup requirements. Recursive ZK proofs have also emerged, allowing the proof workload to be distributed across multiple computers rather than a single one. In order to generate proofs of validity, the following core primitives must be implemented: verifying the signature scheme used by a validator, storing proofs of the validator's public key in the validator set commitment stored on-chain, and tracking the validator 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 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 implement circuits directly, both of which can be challenging and can slow adoption. If the time and effort proves to be very high, it may only be handled by dedicated teams and dedicated hardware, potentially leading to centralization. Longer proof generation times also cause delays. Techniques such as Incrementally Verifiable Computation (IVC) can optimize proof times, but many of them are still in the research phase, awaiting implementation. Longer verification times and workloads will increase on-chain costs.

Trust Game Theory

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

The first category is an economic security mechanism in which multiple external actors (such as validators) cooperate to reach a consensus to determine 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 reduced in the event of malicious activity. In a permissionless setup, anyone can accumulate stake and become a validator. In addition, economic incentives such as block rewards are provided to validators who follow the protocol to ensure economic incentives for honest behavior. However, if the potential stolen amount exceeds the staked amount, participants may collude to steal funds. Examples of protocols that use economical security mechanisms include; Axelar and Celer IM.

The second category is optimistic security mechanisms, where the solution relies on the assumption that only a small number of blockchain participants are honest and obey the rules of the protocol. In this approach, an honest participant acts as a guarantee. For example, an optimal solution allows anyone to submit fraud proofs. Although there is a financial incentive, 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 were able to prove fraud, although they are whitelisted at the time of writing. ChainLink CCIP plans to utilize an anti-fraud network consisting of a distributed network of oracles to detect malicious activity, although the implementation of CCIP's anti-fraud network is unknown.

safety

In terms of security, both mechanisms rely on permissionless participation of verifiers and observers to ensure game-theoretic validity. In an economic security mechanism, funds are more vulnerable if the staked amount is lower than the amount that could be stolen. On the other hand, in optimistic security mechanisms, the assumption of minority trust can be exploited if no one submits a fraud proof, or if permission observers are compromised or removed. In contrast, economic security mechanisms are less dependent on liveness for maintaining security.

implement

In terms of implementation, one approach involves an intermediate chain with its own validators. In this setup, a group of external validators monitors the source chain and reaches consensus on the validity of a transaction when an invocation is detected. Once consensus is reached, they provide proofs on the target chain. Validators are usually required to stake a certain amount of tokens, which may be reduced if malicious activity is detected. Examples of protocols that use this method of implementation include Axelar Network and Celer IM.

Another method of implementation involves the use of off-chain proxies. Off-chain proxies are used to implement optimistic Rollups-like solutions. Within a predefined time window, these off-chain proxies can 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 network of oracles to monitor and attest to cross-chain transactions.

Strengths and Challenges

A key advantage of game-theoretic AMP solutions is resource optimization, as the verification process is typically off-chain, reducing resource requirements. Furthermore, these mechanisms are scalable as the consensus mechanism remains the same for various types of chains and can be easily extended to heterogeneous blockchains.

There are also several challenges associated with these mechanisms. If a majority of validators collude, trust assumptions can be exploited to steal funds, requiring countermeasures such as quadratic voting and fraud proofs. Furthermore, solutions based on optimistic security introduce complexities in terms of finality and liveness, as users and applications need to wait for fraudulent windows to ensure the validity of transactions.

Trust Humans

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

Reputational Security: These solutions rely on multi-signature implementations, where multiple entities verify 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 thing at risk here is the reputation of the entities involved. Some examples include; Multichain (Anycall V;6;) and Wormhole. Vulnerabilities can still exist due to smart contract vulnerabilities, as demonstrated by the Wormhole hack in early 2022.
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 these two entities are independent of each other and cannot collude. LayerZero is an example. Block headers are transmitted on-demand through distributed oracles, and transaction proofs are sent through relayers. If the proof matches the header, the transaction is considered valid. While proving a match 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 oracles and relays (or host their own oracles/relays), thereby limiting risk to individual oracles/relays. End users need to trust that LayerZero, third parties, or the application itself are running oracles and relays independently, with no malicious intent.

In both approaches, the reputation of the participating third-party entities deters malicious behavior. These are usually well-respected entities in the validator and oracle community, and if they behave maliciously, they risk reputational damage and negative impact on other business activities.

Additional Considerations for AMP Solutions

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

code integrity

Recent hacks have exploited code errors, highlighting the need for robust auditing, bug bounties, and diverse client implementations. If all verifiers (in economic/optimistic/reputational security) run the same client (software for verification), it increases dependency on a single codebase and reduces client diversity. For example, Ethereum relies on several execution clients such as geth, netermind, erigon, besu, akula. Multiple implementations in various languages may increase diversity, with no single client dominating the network, eliminating a potential single point of failure. Having multiple clients can also help keep liveness in case 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 if validators/observers can join the network in a permissionless manner, otherwise trust will be hidden by entities who choose permission. Upgrades to smart contracts can also introduce vulnerabilities that can lead to attacks and possibly 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 but requires approval from the offline committee (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 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, dapps that set default settings will get newer versions, dapps that manually set the version need to set it to the new version.

Maximum Extractable Value (MEV)

Different blockchains are not synchronized by a common clock and have different finality times. Therefore, the execution order and timing on the target chain may vary from chain to chain. In a cross-chain world, MEV is difficult to define clearly. It introduces a tradeoff between liveness and order of execution. An ordered channel will ensure in-order delivery of messages, but if a message times out, the channel will be closed. Another application might prefer no ordering, but delivery of other messages is unaffected.

source chain certainty

Ideally, AMP solutions should wait for the source chain to reach finality before transmitting the state information of the source chain to one or more target chains. This will ensure that blocks on the source chain can hardly be reversed or changed. However, many solutions provide instant messaging and make trust assumptions about finality in order to provide the best user experience. In this case, if the source chain undergoes a state rollback after the message is delivered and the bridge asset is passed, it may lead to situations such as double spending of the bridge funds. AMP solutions can manage this risk in a number of ways, such as by setting different finality assumptions for different chains depending on how decentralized the chain is, or by making tradeoffs between speed and security. Bridges utilizing AMP solutions can set limits on the amount of assets bridged before the source chain reaches finality.

Trends and future outlook Customizable and attachable security

To better serve diverse use cases, AMP solutions are incentivized to provide more flexibility to developers. Axelar introduces a method for enabling scalability of messaging and validation without changing application layer logic. HyperLane V2 introduces modules that allow developers to choose from multiple options such as economical 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 delivering a message. 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 applications are architected with a suboptimal design? User awareness of the fundamental concepts behind security is likely to become increasingly important. Ultimately, we foresee aggregation and abstraction of AMP solutions, possibly in the form of some form of composition or "add-on" security.

The Maturity of the “Trust Code and Math” Mechanism

In an ideal end-stage, all cross-chain messages will be trust-minimized through the use of zero-knowledge (ZK) proofs. We've seen similar projects like Polymer Labs and Succinct Labs emerge. Multichain also published a zkRouter white paper on interoperability via ZK proofs. With the recently announced Axelar Virtual Machine, developers can leverage the Interchain Amplifier to establish new connections to the Axelar network permissionlessly. For example, once strong light clients and ZK proofs are developed for Ethereum's state, 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 utilize arbitrary data on multiple blockchains. Celer implemented a user-oriented asset zkBridge using the ZK light client circuit for cross-chain between Ethereum Goerli testnet and BNB Chain testnet. LayerZero discusses in its documentation the possibility of adding new optimized proof message libraries in the future. Newer projects like Lagrange are exploring aggregating multiple proofs from multiple source chains, while Herodotus makes storing proofs possible with ZK proofs. However, this transition will take time, as this approach is difficult to scale across blockchains that rely on different consensus mechanisms and frameworks.

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

Through auditing and bug bounties, the possibility of code exploitation can be minimized. Over time, it will become easier to trust these systems as their history becomes proof of their security.
The cost of generating ZK proofs will be reduced. With more research and development on ZKPs, recursive ZKPs, proof aggregation, folding schemes, and specialized hardware, we expect the time cost of proof generation and verification to decrease substantially, making it a more cost-effective approach.
The blockchain will become more supportive of ZK. In the future, zkEVM will be able to provide concise proofs of execution validity, and light client-based solutions will be able to easily verify source chain execution and consensus. In the final stage of Ethereum, it is also planned to "zk-SNARK everything", including the consensus mechanism.

Human Credentials, Reputation and Identity

The security of a complex system like an AMP solution cannot be encapsulated by a single framework alone and requires a multi-layered solution. For example, in addition to economic incentives, Axelar implements a quadratic voting mechanism to prevent the concentration of voting power among a subset of nodes and promote decentralization. Other human proofs, reputations, and identities can also complement setup and permission mechanisms.

in conclusion

In the open spirit of Web3, we may see a pluralistic future where multiple approaches coexist. In fact, an application can choose to use multiple interoperability solutions, either in a redundant fashion or for the user to choose a combination based on trade-offs. Between "high traffic" routes, point-to-point solutions may be prioritized, while hub-and-spoke models may dominate the long tail of the chain. Ultimately, we, as a community of users, builders, and contributors, will shape the basic shape of the Web3 Internet.

Original link