The essence of liquidity is value exchange. In recent years, the market share of ethereum has been gradually declining and more and more alt-blockchains are widely used. When a new public chain/L2 ecology is formed, users create the need to migrate assets from the original ecology to the new one, as well as to transfer information across chains. I refer to these cross-chain behaviors as horizontal liquidity.

The need for horizontal liquidity arises when people want to be able to do things between different blockchains that could otherwise be done in the same blockchain. What prevents people from doing so then is the impediment of horizontal liquidity. The value of blockchains lies in their tamper-proof, trustless nature, and these come from a decentralized consensus that makes every transaction trustworthy, thus eliminating deception. And the core of cross-chain lies in the consensus that can be reached and transmitted (even for atomic exchange, it needs to verify the credentials for single point consensus of both parties), which is the basic value of blockchain embodied.

Consensus building and delivery requires that one blockchain be able to reliably access the state of another blockchain. Since each blockchain has its own rules, governance mechanisms, native assets, and data formats, information transfer and asset migration between blockchains is not naturally accessible. Therefore, we need a system to support the transfer of values between two or more blockchains that include assets, contract calls, proofs, or state information.

This system, which we often call a "bridge", relies on the following components to enable state access between blockchains:

1. State monitoring. There is usually a role, such as "Oracle", "Validator" or "Relayer", which is responsible for monitoring the state on the original chain.

2. Message passing/forwarding. After this role receives an event, it needs to transfer the message from the original chain to the destination chain.

3. Consensus building. In some models, a consensus is needed between the roles monitoring the original chain in order to pass that information to the destination chain.

4. Message signature. The actors need to cryptographically sign the message sent to the destination chain, either individually or as part of a threshold signature scheme.

It can be learned that the reliability of cross-chain migration depends entirely on how the above links work together. They need a verifier to ensure that there are no problems in each link, and the choice of this verifier is the main difference in the way the bridge works: some bridges use trusted systems, others use trustless systems.

Such a bridge requires users to trust a third-party institution and allow the third-party institution to hold their funds. The most common type of bridge is that of a centralized exchange, such as the Binance Bridge.

The advantages of this type of bridge are obvious:

1. Easy to use.

2. Low cost. Most exchanges only charge a gasoline fee for simple conversions, no on-chain calculations.

But they also have more obvious disadvantages:

1. No control. In the process of value transfer, users must give up control of their assets.

2. Limited functionality. Mainly in two aspects, firstly, such bridges are only used to transfer assets and cannot be used for contract calls, proofs or state information transfer, and secondly, they can only be used to transfer CEX listed tokens.

3. Licensing and trust risk. Users need KYC to use such bridges and need to fully trust the bridge developer and risk that the developer may disconnect the asset bridge at any time, such as Binance suspends dogecoin withdrawals.

It's all about trust. De-trusting means that users don't have to worry about their assets being controlled by third parties, and it also means that such bridges can become public goods.

So what is trustless? John Adler and Mikerah Quintyne-Collins explain in their research paper that "a blockchain system is trustless if and only if its state (all its state elements) is both valid and secure."

There are several key words here, state, valid and secure.

1. State. This can be understood as "who" has "what" at "any time", which is recorded by the blockchain.

2. Valid. This means that the user is able to change the status of the funds for a limited period of time.

3. Secure. This means that the user's funds cannot be stolen and frozen forever, and only the owner can change the status of the funds.

It is important to note that trustless does not mean no trust at all, but rather minimizing trust, which is also true for any public chain. A completely message-free cross-chain transaction would be for Alice on blockchain A to send 1000 USDC directly to her wallet address on blockchain B. Alice's wallet address on blockchain B would then receive it directly, just as in the real world I would put money from one wallet into another. This process is completely trustless because there is no third party involved, but this is impossible because different blockchains cannot directly access and modify each other's state directly.

Thus, trust is a spectrum, and the degree of trust is different for different mechanisms. If the trust cost of the above example with no trust at all is 0, then the trust cost of a trusted bridge is 1. The trust cost of a trustless bridge is between 0 and 1, mathematically expressed as (0, 1).

When it comes to trustless bridges, the first question we need to figure out is, "Who is the verifier of the system?", different design mechanisms give different answers.

1. External verification. External validators are not part of any of the related blockchains and are introduced by bridges with their own unique trust assumptions. Dependent on external validators or federations, security depends on the security of the external validator/federations and different collateral mechanisms (described in detail below), such as Thorchain, Anyswap, Biconomy, Celer, Synapse, PolyNetwork, etc.

2. Optimistic verification. Optimistic verification relies on external verifiers, but by using honest observers to monitor operations and report fraud as verification. Its security depends on the optimistic mechanism, and since the attacker does not know at the time of the attack whether the fraud will be detected or not, this makes it impossible for the attacker to ever be sure that he will be able to successfully steal the funds, thus greatly increasing the economic cost of attacking the system, e.g. Nomad.

3. Local verification. The two verifiers underlying the relevant blockchain verify each other. Relying on liquidity networks, the atomic exchange process can effectively make it impossible for the validators on each chain to collude and steal funds, however liquidity networks lack cross-chain messaging capabilities and can rely on optimistic or external validation bridges to enhance the functionality of the bridge, thus reducing security, such as Connext, Hop and other atomic exchange systems.

4. Native verification. All validators at the bottom of the relevant blockchain are responsible for validating the system. Some native validation relies on light clients and relayers, where relayers are handled by oracle or node relayers, where the relayer transmits information from the source chain to the light client of the target chain, and the native validation node will verify the correctness of the information and trigger the corresponding smart contract, so the security depends on the relayer, such as Stargate, Cosmos IBC, Near RainbowBridge, etc.; Some native validation relies on ZKP and security depends on the relevant blockchain, such as Starkgate and other aggregation bridges.

From the above, it is clear that in terms of the degree of trustless, native verification > local verification > optimistic verification > external verification.

Native and local verification are originally trustless to the same extent due to their reliance on the relevant blockchain's own verifier. However, native validation cannot support generic data transfer between chains due to the use of atomic exchanges, so some other trust assumptions are often introduced to support more functionality, e.g. Hop is native validation but introduces a fast arbitrary message bridge (AMB) to enable fast bridging of optimistic aggregated funds. The protocol even relies on an externally validated bridge if no AMB exists for a given target chain. Thus, the degree of trustless: native authentication > local authentication.

Atomic exchange is characterized by implementing exchange operations inside a state update, typically including hash time locks and conditional transfers, etc.

Atomic exchange across layers: The naturally connected nature of the first layer across to the second layer allows them to easily perform conditional transfers since they are bookkeeping under the same set of books. Conditional transfers, where the first segment of an operation is triggered by the second segment, are an atomic exchange that is more straightforward than hash locks (HTLCs). There is also a second interlayer spanning between layers. Some people will look at second layer spanning as distinct from cross-chaining, when in fact they have very few differences. The only difference between Layer 2 cross-layers and cross-chains is that they are previously connected through the Layer 1 network, which allows them to communicate through conditional transfers. However, this approach is simply too expensive, requiring each cross-layer to go through the first layer network, and suffers from slow speeds and congestion. As a result, layer 2 cross-layers are often viewed as different blockchains that are not connected.

Optimistic verification and external verification both essentially have a set of third-party (non-related blockchain) nodes for verification. Beyond the many differences in technical details, the core difference lies in their cryptographic economics.

• External verification (i.e., multi-signature, verifier, PoS, MPC, or threshold signature) cross-chain bridges utilize the honest majority assumption.

• Optimistic verification uses the observer + fraud proof model, i.e. the verifier assumption of an honest person.

Therefore, from a trustless perspective, optimistic verification requires significantly lower trust costs than external verification.

In contrast, among external validation, there are two main economic models.

• Bonded: After malicious activity occurs, node collateral is forfeited, but the system does not guarantee to compensate users for losses, e.g. Polygon PoS Bridge.

• Insured: After malicious activity occurs, the node collateral is reduced, and the reduced collateral is used to compensate for the user's loss, e.g. Axelar.

From this perspective, an insured external verification bridge can relatively minimize the level of trust.

Different authentication mechanisms also bring different security, speed, connectivity, capital efficiency, and statefulness correlations, which are commonly used to evaluate bridge design.

• Security: trust and validity assumptions, tolerance of malicious actors, security and inversity of user funds.

• Speed: delay in completing transactions, and assurance of finality. There is often a trade-off between speed and security.

• Connectivity: The choice of target chains for users and developers, and the different levels of difficulty in integrating additional target chains. Good connectivity means a high degree of compatibility with public chains and not easily limited by differences in consensus algorithms and data structures of different public chains.

• Capital efficiency: The economics around the capital required to secure the system and the transaction costs of transferring assets.

• Statefulness: The ability to transfer specific assets, more complex states, and/or perform cross-chain contract calls.

Different validation approaches have different trade-offs, each with its own advantages and disadvantages. Although there are some drawbacks to simply adding up the dimensions and calculating the total score for comparison, it seems that, as a rough guide, the total score ZKP > Light Clients & Relayers > Liquidity Networks = Optimistic > External Validators & Federations.

External validations excel in terms of statefulness and connectivity because they can trigger transactions, store data and allow interaction with that data on any number of target chains. Usually such third-party nodes require pledge mechanisms for security, so the capital efficiency of such bridges is minimal. In terms of security, since there are many types of externally verified bridges and different externally verified federations have different consensus algorithm security, their security cannot be generalized, but due to trust assumptions and third-party mechanisms, once the bridge is breached, the user may lose all their money and it will ripple through all the applications associated with the bridge, and their security is the lowest overall.

Optimistic verification, which performs well in terms of statefulness and connectivity, is justified in the same way as external verification. However, due to the mechanism of optimistic verification, it is more capital efficient than external verification but less than bridge designs that do not require the guarantee of a cryptographic economic mechanism. Its speed is also the lowest due to the verification window period. In terms of security, the cost of attacking an Optimistic cross-chain bridge with n verifiers is equal to the cost of compromising or hacking n verifiers. And relative to external verification, the cost of an attack with n verifiers for an external verification cross-chain bridge is equal to the cost of compromising or hacking m verifiers, where m < n . In addition, with optimistic verification, even if n verifiers are hacked the attacker is not guaranteed to steal the funds, as long as an honest observer "catches the fraud" and revokes the attacker's access to the funds. Therefore, optimistic verification is generally more secure than external verifiers, but less secure than local verification and native verification mechanisms, where an attacker cannot steal funds at all.

Local validation (liquidity networks) excel in security and speed because the atomic exchange mechanism using hash time locks makes it impossible for funds to be stolen, and local validation without the need for universal consensus greatly increases speed. They are also more capital efficient than bonded/insured external verifiers, as capital efficiency is related to transaction flow/volume rather than security. However, because locally validated systems cannot support common data transfer between chains, their statefulness is poor, which leads to the fact that they often need to introduce other technical support to achieve more functionality, such as Hop's introduction of the Arbitrary Message Bridge (AMB) and Connext's cooperation with Nomad.

Native authentication performs very well in terms of security, capital efficiency and statefulness because it relies on the underlying trust and/or consensus mechanism of the domain to operate, and the blockhead relay system can pass any type of data without any pledge. Likewise, it must be customized for each type of domain. The Ethereum ecosystem is highly heterogeneous: ZK/optimistic aggregation, sidechains, and base chains running a large number of consensus algorithms such as ETH-PoW, Nakamoto-PoW, Tendermint-PoS, Snowball-PoS, PoA, and many others. Each of these areas requires a unique strategy to implement a natively verified interoperability system. In terms of connectivity, a native verification system using ZKP is a bit worse, since not every consensus model can be proven with zero knowledge. In terms of speed, ZKP cross-chain bridges have good low-latency properties and are also likely to be much cheaper than conventional blockhead relay systems because proving consensus does not need to happen on the chain.

In addition, LayerZero belongs to native authentication, and its innovation, even if small, is very important, introducing a prophecy machine to enable on-demand streaming of blockheads (instead of keeping all blockheads and reducing costs) and guaranteeing security due to the addition of an independent relay system on top of the prophecy machine.

Universal messaging is the ability to call any contract on different blockchains. So why does the cross-chain approach of locally validated networks not support generic messaging?

It is actually possible for a locally validated system to implement cross-domain contract calls, but only if the function being called has some form of logical owner. For example, it is possible to trustlessly call Uniswap's swap function across chains, since anyone with an exchangeable token can call the swap function. However, it is not possible to trustlessly lock and mint NFTs across chains in local validation - this is because the logical owner of the mint function on the destination chain should be the lock contract on the source chain.

Intuitively, locally validated messages are sent from one contract on the chain to the same contract on another chain for function invocation through a single point of mutual validation, completing the transaction and state change within an atomic exchange process, and thus there is a logical problem of invocation; while messages of other validation methods pass the changed (fast) state through multiple points of validation, and there is no logical problem of invocation.

As already talked about, it is due to the different consensus algorithms of the different chains that break connectivity. How is this understood?

Take the example of a transfer. Briefly, when a transfer occurs, a credential is generated at this point, and another chain learns that this is true than the transfer by verifying the change of credentials before it can initiate the next action. The process of generating this credential is the process of consensus algorithm, and the other chain needs to understand the credential (e.g., verify the hash) to simulate the way the credential is generated, and this is where different consensus algorithms can get in the way. At this point, the logic of ZKP is slightly different again, although the same generation algorithm can be used for ZKP, some of the consensus models are difficult to prove by zero knowledge.

Horizontal liquidity refers to interoperability across chains to support messaging and asset transfer. Currently, there is no solution to the trilemma of horizontal liquidity: trustless, scalability and generalizable. The NXTP proposed by Connext tries to build an interoperable network "layer 2" to solve this problem, based on the idea of the second layer of Ethereum, but I think the effectiveness of this solution remains to be examined.

In the scalability trilemma of Ethereum, it is verification that plays the role of a mortise and tenon structural connector, so it can be developed as a modular blockchain by breaking it down with verification as the mortise and tenon into executing (computation to verify), (verification result to build) consensus and data availability (to verify).

Recently there have been voices talking about modular cross-chain bridges, which try to combine different cross-chain solutions and encapsulate them with the same interface, but this does not change the nature of the logic running under the package, and the problems that should exist remain. We need to find the mortise and tenon structure in the cross-chain problem to be able to disassemble a complex problem cleanly without breaking the original parts. Verification as a cross-chain mortise and tenon structure works because cross-chain is essentially cross-ledger bookkeeping, and the very core point is verification, but due to the differences in consensus mechanisms and data structures of different blockchains, another more core point is cross-chain message identification, because the prerequisite for verification is to identify these data messages (there is no identification problem in L2).

So how does one go about thinking about cross-chain message recognition as a cross-chain mortise and tenon structure? As mentioned above,

• External verification, digesting cross-chain messages in an external validation federation by deploying our own smart contracts on different chains, so we have to trust this external validation federation and cannot reach trustless.

• Local verification, where messaging is written in the contract as a form of logical structure (atomic exchange), which directly leads to its lower connectivity and very low statefulness, it can only deliver an exchange logic and not a generic ledger change type of message and cannot reach generalizability.

• Native verification, messages are delivered directly in the original data structure, reach the target blockchain, and then the data stored in the original blockchain data structure is deconstructed, computed, and validated. This requires a codified medium in between to be able to understand and translate the data structure of the two blockchains. Different consensus algorithms pose a number of challenges, and even ZKP, which is the "silver bullet" for verification, encounters translation problems here. Therefore, it is difficult to make native verification scalable.

There are about two paths I can think of to solve this problem: one is the emergence of ZKP algorithms that support common consensus algorithms; the other is to build a message recognition middleware by non-intermediate consensus.

Some immature thoughts. Feel free to discuss.

Many thanks to Yang Peng and Xiang Wang for proofreading this paper.

The essence of liquidity is value exchange. In recent years, the market share of ethereum has been gradually declining and more and more alt-blockchains are widely used. When a new public chain/L2 ecology is formed, users create the need to migrate assets from the original ecology to the new one, as well as to transfer information across chains. I refer to these cross-chain behaviors as horizontal liquidity.

The need for horizontal liquidity arises when people want to be able to do things between different blockchains that could otherwise be done in the same blockchain. What prevents people from doing so then is the impediment of horizontal liquidity. The value of blockchains lies in their tamper-proof, trustless nature, and these come from a decentralized consensus that makes every transaction trustworthy, thus eliminating deception. And the core of cross-chain lies in the consensus that can be reached and transmitted (even for atomic exchange, it needs to verify the credentials for single point consensus of both parties), which is the basic value of blockchain embodied.

Consensus building and delivery requires that one blockchain be able to reliably access the state of another blockchain. Since each blockchain has its own rules, governance mechanisms, native assets, and data formats, information transfer and asset migration between blockchains is not naturally accessible. Therefore, we need a system to support the transfer of values between two or more blockchains that include assets, contract calls, proofs, or state information.

This system, which we often call a "bridge", relies on the following components to enable state access between blockchains:

1. State monitoring. There is usually a role, such as "Oracle", "Validator" or "Relayer", which is responsible for monitoring the state on the original chain.

2. Message passing/forwarding. After this role receives an event, it needs to transfer the message from the original chain to the destination chain.

3. Consensus building. In some models, a consensus is needed between the roles monitoring the original chain in order to pass that information to the destination chain.

4. Message signature. The actors need to cryptographically sign the message sent to the destination chain, either individually or as part of a threshold signature scheme.

It can be learned that the reliability of cross-chain migration depends entirely on how the above links work together. They need a verifier to ensure that there are no problems in each link, and the choice of this verifier is the main difference in the way the bridge works: some bridges use trusted systems, others use trustless systems.

Such a bridge requires users to trust a third-party institution and allow the third-party institution to hold their funds. The most common type of bridge is that of a centralized exchange, such as the Binance Bridge.

The advantages of this type of bridge are obvious:

1. Easy to use.

2. Low cost. Most exchanges only charge a gasoline fee for simple conversions, no on-chain calculations.

But they also have more obvious disadvantages:

1. No control. In the process of value transfer, users must give up control of their assets.

2. Limited functionality. Mainly in two aspects, firstly, such bridges are only used to transfer assets and cannot be used for contract calls, proofs or state information transfer, and secondly, they can only be used to transfer CEX listed tokens.

3. Licensing and trust risk. Users need KYC to use such bridges and need to fully trust the bridge developer and risk that the developer may disconnect the asset bridge at any time, such as Binance suspends dogecoin withdrawals.

It's all about trust. De-trusting means that users don't have to worry about their assets being controlled by third parties, and it also means that such bridges can become public goods.

So what is trustless? John Adler and Mikerah Quintyne-Collins explain in their research paper that "a blockchain system is trustless if and only if its state (all its state elements) is both valid and secure."

There are several key words here, state, valid and secure.

1. State. This can be understood as "who" has "what" at "any time", which is recorded by the blockchain.

2. Valid. This means that the user is able to change the status of the funds for a limited period of time.

3. Secure. This means that the user's funds cannot be stolen and frozen forever, and only the owner can change the status of the funds.

It is important to note that trustless does not mean no trust at all, but rather minimizing trust, which is also true for any public chain. A completely message-free cross-chain transaction would be for Alice on blockchain A to send 1000 USDC directly to her wallet address on blockchain B. Alice's wallet address on blockchain B would then receive it directly, just as in the real world I would put money from one wallet into another. This process is completely trustless because there is no third party involved, but this is impossible because different blockchains cannot directly access and modify each other's state directly.

Thus, trust is a spectrum, and the degree of trust is different for different mechanisms. If the trust cost of the above example with no trust at all is 0, then the trust cost of a trusted bridge is 1. The trust cost of a trustless bridge is between 0 and 1, mathematically expressed as (0, 1).

When it comes to trustless bridges, the first question we need to figure out is, "Who is the verifier of the system?", different design mechanisms give different answers.

1. External verification. External validators are not part of any of the related blockchains and are introduced by bridges with their own unique trust assumptions. Dependent on external validators or federations, security depends on the security of the external validator/federations and different collateral mechanisms (described in detail below), such as Thorchain, Anyswap, Biconomy, Celer, Synapse, PolyNetwork, etc.

2. Optimistic verification. Optimistic verification relies on external verifiers, but by using honest observers to monitor operations and report fraud as verification. Its security depends on the optimistic mechanism, and since the attacker does not know at the time of the attack whether the fraud will be detected or not, this makes it impossible for the attacker to ever be sure that he will be able to successfully steal the funds, thus greatly increasing the economic cost of attacking the system, e.g. Nomad.

3. Local verification. The two verifiers underlying the relevant blockchain verify each other. Relying on liquidity networks, the atomic exchange process can effectively make it impossible for the validators on each chain to collude and steal funds, however liquidity networks lack cross-chain messaging capabilities and can rely on optimistic or external validation bridges to enhance the functionality of the bridge, thus reducing security, such as Connext, Hop and other atomic exchange systems.

4. Native verification. All validators at the bottom of the relevant blockchain are responsible for validating the system. Some native validation relies on light clients and relayers, where relayers are handled by oracle or node relayers, where the relayer transmits information from the source chain to the light client of the target chain, and the native validation node will verify the correctness of the information and trigger the corresponding smart contract, so the security depends on the relayer, such as Stargate, Cosmos IBC, Near RainbowBridge, etc.; Some native validation relies on ZKP and security depends on the relevant blockchain, such as Starkgate and other aggregation bridges.

From the above, it is clear that in terms of the degree of trustless, native verification > local verification > optimistic verification > external verification.

Native and local verification are originally trustless to the same extent due to their reliance on the relevant blockchain's own verifier. However, native validation cannot support generic data transfer between chains due to the use of atomic exchanges, so some other trust assumptions are often introduced to support more functionality, e.g. Hop is native validation but introduces a fast arbitrary message bridge (AMB) to enable fast bridging of optimistic aggregated funds. The protocol even relies on an externally validated bridge if no AMB exists for a given target chain. Thus, the degree of trustless: native authentication > local authentication.

Atomic exchange is characterized by implementing exchange operations inside a state update, typically including hash time locks and conditional transfers, etc.

Atomic exchange across layers: The naturally connected nature of the first layer across to the second layer allows them to easily perform conditional transfers since they are bookkeeping under the same set of books. Conditional transfers, where the first segment of an operation is triggered by the second segment, are an atomic exchange that is more straightforward than hash locks (HTLCs). There is also a second interlayer spanning between layers. Some people will look at second layer spanning as distinct from cross-chaining, when in fact they have very few differences. The only difference between Layer 2 cross-layers and cross-chains is that they are previously connected through the Layer 1 network, which allows them to communicate through conditional transfers. However, this approach is simply too expensive, requiring each cross-layer to go through the first layer network, and suffers from slow speeds and congestion. As a result, layer 2 cross-layers are often viewed as different blockchains that are not connected.

Optimistic verification and external verification both essentially have a set of third-party (non-related blockchain) nodes for verification. Beyond the many differences in technical details, the core difference lies in their cryptographic economics.

• External verification (i.e., multi-signature, verifier, PoS, MPC, or threshold signature) cross-chain bridges utilize the honest majority assumption.

• Optimistic verification uses the observer + fraud proof model, i.e. the verifier assumption of an honest person.

Therefore, from a trustless perspective, optimistic verification requires significantly lower trust costs than external verification.

In contrast, among external validation, there are two main economic models.

• Bonded: After malicious activity occurs, node collateral is forfeited, but the system does not guarantee to compensate users for losses, e.g. Polygon PoS Bridge.

• Insured: After malicious activity occurs, the node collateral is reduced, and the reduced collateral is used to compensate for the user's loss, e.g. Axelar.

From this perspective, an insured external verification bridge can relatively minimize the level of trust.

Different authentication mechanisms also bring different security, speed, connectivity, capital efficiency, and statefulness correlations, which are commonly used to evaluate bridge design.

• Security: trust and validity assumptions, tolerance of malicious actors, security and inversity of user funds.

• Speed: delay in completing transactions, and assurance of finality. There is often a trade-off between speed and security.

• Connectivity: The choice of target chains for users and developers, and the different levels of difficulty in integrating additional target chains. Good connectivity means a high degree of compatibility with public chains and not easily limited by differences in consensus algorithms and data structures of different public chains.

• Capital efficiency: The economics around the capital required to secure the system and the transaction costs of transferring assets.

• Statefulness: The ability to transfer specific assets, more complex states, and/or perform cross-chain contract calls.

Different validation approaches have different trade-offs, each with its own advantages and disadvantages. Although there are some drawbacks to simply adding up the dimensions and calculating the total score for comparison, it seems that, as a rough guide, the total score ZKP > Light Clients & Relayers > Liquidity Networks = Optimistic > External Validators & Federations.

External validations excel in terms of statefulness and connectivity because they can trigger transactions, store data and allow interaction with that data on any number of target chains. Usually such third-party nodes require pledge mechanisms for security, so the capital efficiency of such bridges is minimal. In terms of security, since there are many types of externally verified bridges and different externally verified federations have different consensus algorithm security, their security cannot be generalized, but due to trust assumptions and third-party mechanisms, once the bridge is breached, the user may lose all their money and it will ripple through all the applications associated with the bridge, and their security is the lowest overall.

Optimistic verification, which performs well in terms of statefulness and connectivity, is justified in the same way as external verification. However, due to the mechanism of optimistic verification, it is more capital efficient than external verification but less than bridge designs that do not require the guarantee of a cryptographic economic mechanism. Its speed is also the lowest due to the verification window period. In terms of security, the cost of attacking an Optimistic cross-chain bridge with n verifiers is equal to the cost of compromising or hacking n verifiers. And relative to external verification, the cost of an attack with n verifiers for an external verification cross-chain bridge is equal to the cost of compromising or hacking m verifiers, where m < n . In addition, with optimistic verification, even if n verifiers are hacked the attacker is not guaranteed to steal the funds, as long as an honest observer "catches the fraud" and revokes the attacker's access to the funds. Therefore, optimistic verification is generally more secure than external verifiers, but less secure than local verification and native verification mechanisms, where an attacker cannot steal funds at all.

Local validation (liquidity networks) excel in security and speed because the atomic exchange mechanism using hash time locks makes it impossible for funds to be stolen, and local validation without the need for universal consensus greatly increases speed. They are also more capital efficient than bonded/insured external verifiers, as capital efficiency is related to transaction flow/volume rather than security. However, because locally validated systems cannot support common data transfer between chains, their statefulness is poor, which leads to the fact that they often need to introduce other technical support to achieve more functionality, such as Hop's introduction of the Arbitrary Message Bridge (AMB) and Connext's cooperation with Nomad.

Native authentication performs very well in terms of security, capital efficiency and statefulness because it relies on the underlying trust and/or consensus mechanism of the domain to operate, and the blockhead relay system can pass any type of data without any pledge. Likewise, it must be customized for each type of domain. The Ethereum ecosystem is highly heterogeneous: ZK/optimistic aggregation, sidechains, and base chains running a large number of consensus algorithms such as ETH-PoW, Nakamoto-PoW, Tendermint-PoS, Snowball-PoS, PoA, and many others. Each of these areas requires a unique strategy to implement a natively verified interoperability system. In terms of connectivity, a native verification system using ZKP is a bit worse, since not every consensus model can be proven with zero knowledge. In terms of speed, ZKP cross-chain bridges have good low-latency properties and are also likely to be much cheaper than conventional blockhead relay systems because proving consensus does not need to happen on the chain.

In addition, LayerZero belongs to native authentication, and its innovation, even if small, is very important, introducing a prophecy machine to enable on-demand streaming of blockheads (instead of keeping all blockheads and reducing costs) and guaranteeing security due to the addition of an independent relay system on top of the prophecy machine.

Universal messaging is the ability to call any contract on different blockchains. So why does the cross-chain approach of locally validated networks not support generic messaging?

It is actually possible for a locally validated system to implement cross-domain contract calls, but only if the function being called has some form of logical owner. For example, it is possible to trustlessly call Uniswap's swap function across chains, since anyone with an exchangeable token can call the swap function. However, it is not possible to trustlessly lock and mint NFTs across chains in local validation - this is because the logical owner of the mint function on the destination chain should be the lock contract on the source chain.

Intuitively, locally validated messages are sent from one contract on the chain to the same contract on another chain for function invocation through a single point of mutual validation, completing the transaction and state change within an atomic exchange process, and thus there is a logical problem of invocation; while messages of other validation methods pass the changed (fast) state through multiple points of validation, and there is no logical problem of invocation.

As already talked about, it is due to the different consensus algorithms of the different chains that break connectivity. How is this understood?

Take the example of a transfer. Briefly, when a transfer occurs, a credential is generated at this point, and another chain learns that this is true than the transfer by verifying the change of credentials before it can initiate the next action. The process of generating this credential is the process of consensus algorithm, and the other chain needs to understand the credential (e.g., verify the hash) to simulate the way the credential is generated, and this is where different consensus algorithms can get in the way. At this point, the logic of ZKP is slightly different again, although the same generation algorithm can be used for ZKP, some of the consensus models are difficult to prove by zero knowledge.

Horizontal liquidity refers to interoperability across chains to support messaging and asset transfer. Currently, there is no solution to the trilemma of horizontal liquidity: trustless, scalability and generalizable. The NXTP proposed by Connext tries to build an interoperable network "layer 2" to solve this problem, based on the idea of the second layer of Ethereum, but I think the effectiveness of this solution remains to be examined.

In the scalability trilemma of Ethereum, it is verification that plays the role of a mortise and tenon structural connector, so it can be developed as a modular blockchain by breaking it down with verification as the mortise and tenon into executing (computation to verify), (verification result to build) consensus and data availability (to verify).

Recently there have been voices talking about modular cross-chain bridges, which try to combine different cross-chain solutions and encapsulate them with the same interface, but this does not change the nature of the logic running under the package, and the problems that should exist remain. We need to find the mortise and tenon structure in the cross-chain problem to be able to disassemble a complex problem cleanly without breaking the original parts. Verification as a cross-chain mortise and tenon structure works because cross-chain is essentially cross-ledger bookkeeping, and the very core point is verification, but due to the differences in consensus mechanisms and data structures of different blockchains, another more core point is cross-chain message identification, because the prerequisite for verification is to identify these data messages (there is no identification problem in L2).

So how does one go about thinking about cross-chain message recognition as a cross-chain mortise and tenon structure? As mentioned above,

• External verification, digesting cross-chain messages in an external validation federation by deploying our own smart contracts on different chains, so we have to trust this external validation federation and cannot reach trustless.

• Local verification, where messaging is written in the contract as a form of logical structure (atomic exchange), which directly leads to its lower connectivity and very low statefulness, it can only deliver an exchange logic and not a generic ledger change type of message and cannot reach generalizability.

• Native verification, messages are delivered directly in the original data structure, reach the target blockchain, and then the data stored in the original blockchain data structure is deconstructed, computed, and validated. This requires a codified medium in between to be able to understand and translate the data structure of the two blockchains. Different consensus algorithms pose a number of challenges, and even ZKP, which is the "silver bullet" for verification, encounters translation problems here. Therefore, it is difficult to make native verification scalable.

There are about two paths I can think of to solve this problem: one is the emergence of ZKP algorithms that support common consensus algorithms; the other is to build a message recognition middleware by non-intermediate consensus.

Some immature thoughts. Feel free to discuss.

Many thanks to Yang Peng and Xiang Wang for proofreading this paper.