Starting from 2022, many cross-chain projects, including Multichain, Succinct, and Celer, have launched their ZKP cross-chain testnets, thus putting a spotlight on ZKP-based cross-chain communication through light clients. ZKP-based cross-chain communication, in essence, falls into the category of native verification, which enables trustless verification of consensus on the source chain and helps DAPPs build the most secure multichain (or full-chain) ecosystem. It is said to be the safest because compared with the existing cross-chain solutions that requires to trust a third party, ZKP-based cross-chain communication does not introduce any trust assumptions, while users only need to trust the consensuses of the source chain and the destination chain. It is from this perspective that ZKP-based cross-chain communication can be said the safest cross-chain method. The complexity of ZKP cross-chain technology, however, means a relatively high threshold.

In terms of verification methods, cross-chain interoperability protocols (CCIP) can be divided into three types, i.e. external verification, native verification, and local verification. Each type of CCIP has its limitations: it is difficult to juggle trustlessness, scalability, and universality.

External verification refers to the practice of introducing a group of trusted external nodes for the verification of cross-chain messages, provided that users must trust the relay network consisting of the external nodes. Cross-chain solutions based on MPC, Oracle systems, PoS/PoA, multi-signature, and TEE fall into this category. External verification is based on the trust of third-party relay nodes or oracle machines, and therefore, trustless cross-chain messaging through relay is impossible, not to mention that relayers and oracle machines are not worthy of complete trust in certain cases. Nevertheless, it is the mainstream way of implementing cross-chain communication on the market, which has been adopted by well-known projects such as Multichain, Wormhole, Axelar, and LayerZero.

Local verification, also known as P2P verification, refers to direct verification by the counterparties in a cross-chain interaction. It is essentially about the atomic exchange based on the hash timelock. The parties of a transaction verify the behavior of each other. In case one party does evil, both will face losses because they have shared interests. In practice, there will be a liquidity provider acting as a counterparty just for matchmaking. Connext and Hop are typical in this category. Nevertheless, such solutions are only suitable for cross-chain transfer of assets, not for generic cross-chain messaging; hence not universally applicable.

Native verification refers to the practice in which the light node deployed on the destination chain verifies the messages sent from the source chain, without trust assumptions. In theory, users only need to trust the consensuses on the source chain and the destination chain and ensure there is no rollback on the two chains. Generally, block redundancy will be set by the light node to prevent possible rollbacks. Typical native verification projects include Rainbow Bridge, as well as ZK-based cross-chain solutions emerging lately, e.g. zkRouter, Succinct Labs, =nil; Foundation, etc.

A comprehensive comparison of the three types of CCIP is shown in Table 1.

The prosperity of multichain ecosystems has spawned the need for cross-chain interactions. As a result, many cross-chain projects such as Multichain (anyCall), Layerzero, and Wormhole have come into being. These projects value universality and scalability as they require a trusted relay network.

Nevertheless, from 2021 to 2022, cross-chain projects such as Ronin Network, Horizon, BNB Chain, Wormhole, and Nomad suffered hacker attacks, which resulted in tremendous asset losses. Users of multichain ecosystems and cross-chain solution providers have found that trustless cross-chain solutions provide a safer choice for users, despite their weak scalability. As such, native verification becomes the best way to realize trustless cross-chain interactions.

Native CCIPs generally need to consume a lot of Gas to verify the consensus of the source chain on the destination chain, because the light client on the destination chain needs to obtain a large amount of source chain data to generate information about the consensus. When ZKP is used for native verification, the light client on the destination chain only needs to obtain the concise ZKP to verify the transaction on the source chain. This is why it is considered a better solution.

Consensuses of public-chain ecosystems such as Polkadot and Cosmos naturally allow for cross-chain communication within the ecosystem. However, public chains that are not in the same ecosystem, such as Ethereum and Solana, cannot enjoy the advantage. While mainstream third-party cross-chain bridges, including Multichain, Layerzero, and Wormhole, require the trust of a relay network, cross-chain solutions based on ZKP do not require the trust of a third party. They directly transmit the consensus proof of the source chain to the destination chain for verification by the light client on the latter. This is essentially how consensus cross-chain works.

However, the way in which consensuses are generated varies with the chain, and as a result, the data required to verify them are different. The difficult part about ZKP-based cross-chain interactions is how to generate the ZKP for the consensus on the source chain because it is supposed to be generated on the basis of the data of source chain consensus. The ZKP circuits generated by different source chain consensuses also need to be customized.

The process in which different public chains generate consensuses varies greatly. Similarly, the process of generating ZKP also varies. Take Ethereum POS as an example.

Ethereum has designed a complex verifier selection mechanism to generate consensus. Ethereum has added a key feature in the Altair upgrade, that is, a sync committee specifically designed to enable light clients to sync block states. Ethereum uses the RANDAO algorithm to randomly select 512 verifiers to form a sync committee, the information of which is stored on the Beacon Chain and updated every 256 Epochs (about 6.4 minutes each). The role of the sync committee is to continuously sign block headers. The transition of Ethereum state will be confirmed when two thirds of the sync committee members have signed.

The Beacon Chain uses the BLS12-381 algorithm as a way for verifiers to participate in the POS consensus. The BLS signatures of multiple verifiers in the blocks of the Beacon Chain can be further aggregated into one single signature, thus effectively reducing the data communication and on-chain storage pressures brought about by the multiple signatures. Meanwhile, the verifiers only need to verify a single signature to make block verification more efficient.

As the sync committee is an integral part of the consensus mechanism, light clients can obtain the verified consensus state without accessing the entire verifier set. In order to verify the consensus state of the source chain, the light client on the destination chain will download part of the data for verification and calculation, including:

(1) Merkle path proof. This is to verify that the current committee (sync_cmts) verifying the signature of the current block is the next committee designated in the verified block header.

(2) Aggregation Committee Public Key. According to the actual signature of the current block's sync committee, the aggregation committee public key can be calculated.

(3) Signature of the sync committee. The aggregation committee public key can be used to verify the signature of the sync committee in the new block.

The above method is a common solution for native verification. However, direct verification of a source chain consensus on the destination chain involves a huge amount of data verification and calculation on the destination chain; hence high gas consumption. The use of the ZKP technology to complete the calculation and verification of the source-chain data off-chain, generate a concise source-chain consensus, and then pass it to the destination chain, serves to greatly reduce the Gas consumption on the destination chain, which is why a ZKP-based on-chain light client can verify the source chain consensus at a low cost. ZKP-based cross-chain protocols conduct aggregated public key verification of BLS signature off chain and generate a ZKP. Simply by verifying the ZKP, the client on the destination chain will have the source chain consensus verified. The specific code is shown in Fig. 1.

The above ZKP-based process of syncing consensus through the light client shows that the generation of off-chain proof is closely related to the consensus mechanism on the source chain and the supportiveness of the light client. It also explains why implementing an on-chain light client is so difficult, and why the light client needs to check if the code should be synced whenever Ethereum is upgraded.

ZKP-based cross-chain processes are roughly the same. So when analyzing individual cases, we placed more emphasis on the uniqueness of each cross-chain project. As to how ZKP-based cross-chain communication works, please refer to the previous blog post (https://www.theblockbeats.info/news/35560).

zkRouter is a ZKP cross-chain project developed by Multichain. According to its white paper, Multichain's vision is to develop zkRouter into a part of its MBI (Multiple Blockchain Interaction) as an underlying trust mechanism. This has been elaborated in the previous article. But a few key points are worth mentioning here.

The information now available shows that the zkRouter cross-chain bridge between the Goerli testnet and the Fantom testnet will be launched soon. The zkRouter protocol mainly includes four steps: initial setup (Setup), consensus proof generation (Proof Gen), consensus proof verification (ProofVerify), and interoperability contract call (InterOperCall), as shown in Fig. 2.

(1) Setup

To complete the verification of the source chain ZKP, the light client on the destination chain must have access to the consensus state of the previous source chain block. The continuity of consensus state means that the consensus result of the current block is based on the updated consensus result of the preceding block. Therefore, the light client on the destination chain must first obtain the current consensus state of the source chain before verifying the correctness of subsequent block consensus.

The light client on the destination chain needs to access the initial data (initial_data), which includes the initial block height, block header hash, and so on. This initial setting needs to be done once only, and will be automatically updated as cross-chain interaction occurs.

(2) Proof Gen

This step occurs during specific cross-chain processes. When a new block is generated by the source chain, the destination chain needs to sync the updated information, including the state of the previous block, the selection of block-generating nodes, and the legality of signature nodes. For non-immediate consensus mechanisms, there is a need to set a certain number of redundant blocks to avoid losses incurred by forking. Then, the relayer uses the off-chain ZKP technology to calculate and generate a ZKP, which is then synced to the destination chain.

(3) ProofVerify

After the concise ZKP is submitted to the destination chain by the relayer, it is necessary to verify the ZKP, a task fulfilled by the light client on the destination chain. When the verification is passed, the result is returned and the consensus state of the source chain is updated on the destination chain.

(4) InterOperCall

When the light client on the destination chain has verified the consensus on the source chain (including transactions on the source chain), the participants can initiate cross-chain contract interoperability calls to complete cross-chain interactions. For details, please refer to Multichain's white paper.

The core advantage of zkRouter is that it enables high TPS cross-chain interaction. According to the description, zkRouter's TPS, at its best, can reach the TPS of a public chain, that is, 100 transactions per the testnet data.

The source chain address of Goerli testnet: https://goerli.etherscan.io/txs?a=0x91d1d54572ef662419d9e552a013321b5713e3ad

The destination chain address of Fantom testnet: https://testnet.ftmscan.com/address/0x91d1D54572Ef662419d9E552A013321b5713E3AD#tokentxns

For the specifics of zkRouter, please refer to its white paper.

Hyper Oracle defines itself as a trusted oracle machine network. Unlike other ZKP-based cross chain projects, Hyper Oracle stresses the transmission of the entire consensus. It's Hyper Oracle's vision to develop an end-to-end trustless solution, which requires the light client to verify the entire consensus of Ethereum PoS.

When implementing Ethereum POS, the consensus of the sync committee is already a part of the entire consensus, so why stress the transmission of the entire consensus?

Brevis defines itself as a full-chain computing and verification platform, which is essentially a cross-chain communication solution that achieves trustless cross-chain communication by generating ZKP-based consensus proofs. Brevis consists of three components, namely zkFabric, zkQueryNet, and zkAggregatorRollup. For now, it covers EVM and NON-EVM chains.

zkFabric is mainly used to collect block headers and generate consensus proofs after their validity is verified through the ZKP light client circuit. It plays a similar role to the relayer or verifier in the ZK cross-chain process. In this particular system, however, the destination of the relay is zkAggregatorRollup.

ZkAggregator Rollup is a ZK rollup blockchain supported by light ZKP virtual machines, which aggregates different proofs and input information from zkQueryNet and zkFabric. According to Celer's description, zkAggregatorRollup VM runtime has the following features:

(1) Recursive verification of proofs generated by zkQueryNet and zkFabric;

(2) Store block headers from zkFabric that have been verified by ZKP;

(3) Store query requests and ZKP validation results.

ZkQueryNet is an open market that provides a ZKP query engine, which can directly take in data queries from on-chain smart contracts, and generate query results and corresponding ZKP query proofs through the ZKP query engine circuit. The result will also be saved in the Query Result, which belongs to the zkAggregatorRollup module, as shown in Fig. 3.

Compared with other cross-chain projects, Brevis is most distinctively featured by its modularity. Such structured design enhances Brevis' scalability. By encapsulating different functions, Brevis can achieve a unified interface, which is convenient for DAPP calls and also conducive to expansion to cover more public chains in the future

Telepathy is a protocol developed by the Succinct team, with the aim to provide users with permissionless and trustless interoperability. Through Telepath, DAPP can securely send messages from the source chain to any destination chain. This is in line with the traditional model for defining cross-chain messaging.

The Telepathy cross-chain communication model mainly consists of five steps, as shown in Fig. 4.

(1) The multichain DAPP contract issues a multichain interoperability order.

(2) When Telepath Broadcaster receives such order, the Ethereum mainchain will strike a final consensus in about 12 minutes.

(3) The Telepathy Operator uses the consensus to generate a ZKP consensus proof.

(4) The Telepathy Relayer passes the consensus proof to the contract on the destination chain.

(5) The light client contract on the destination chain verifies the consensus proof.

This generic model is suitable for the cross-chain messaging among multiple chains. Across, a well-known cross-chain project, has announced the use of Telepathy to build a cross-chain bridge between Avalanche and BNB Chain.

=nil; Foundation has a similar positioning as Brevis, with the goal of becoming a multichain proof market where DAPPs can request =nil; Foundation to generate proofs as needed. A detailed description is beyond the scope of this text.

But remember that the zkLLVM mentioned in the previous article is also one of its core products. The product is aimed to help developers compile ZKP in a high-level programming language, which greatly lowers the entry threshold for developers. It allows developers to focus on circuit design using a language they are familiar with, rather than struggling to learn a domain-specific language.

So far, many teams have committed themselves to the development of ZK cross-chain bridges. As the generation of ZKP is closely related to the consensus on the source chain, and as the way in which consensus is reached and the signature algorithm used by different chains vary, different solutions used in practice vary in terms of efficiency and characteristics, as shown in Table 2.

Although these projects build their ZKP systems on the basis of the SNARK technology, it is difficult to ensure the consistency of algorithms, the degree to which algorithms are optimized, and the hardware used. The above ZKP generation speed is for reference only. More detailed data require more rigorous benchmark testing.

At present, most ZK cross-chain bridges are supportive of cross-chain communication among non-EVM chains, and in this regard, there is little difference between different projects. Going forward, the main competitive advantages of ZK CCIPs will lie in algorithm optimization, multichain deployment, and contract security.

The off-chain generation of ZKP requires high-performance servers with larger memory, which means high device costs. Optimized algorithms, in a degree, can save computational power.

In the past two months, many cross-chain protocols have made their moves revolving around ZKP cross-chain development, but primarily through the launch of testnet, rather than mainnet. Moreover, many cross-chain protocols generally link one or two chains without achieving multichain interoperability. Therefore, the more chains a cross-chain bridge can support in the future, the more competitive it will become.

As ZK cross-chain projects have not been put to large-scale market test, whether they can survive in the market largely depends on the security of contracts. This issue, though ignored by most people nowadays, is likely to become the biggest concern when it comes to ZKP projects.

We have seen a number of blockchain security accidents related to cross-chain protocols, which have raised concerns among almost all practitioners. More importantly, most mainstream cross-chain protocols fall into the external verification category, which does not allow for trustless verification. Therefore, serious security risks remain. If the relayers collide to do evil, the participants in the multichain ecosystem are likely to face immeasurable losses. As a type of native verification, ZKP-based cross-chain solutions have their unique advantages, i.e. they are trustless and universally available. They consume much less gas compared to direct verification of the original source chain data on the destination chain. The frequent launch of ZKP-based cross-chain testnets indicates that many cross-chain projects have been keenly aware of this. However, ZKP-based cross-chain protocols are still in their early stages of development. Whether they can provide users with a more secure cross-chain experience remains an issue that needs to be further tracked and observed.

Reference:

https://hyperoracle.medium.com/zkpos-end-to-end-trustless-65edccd87c5a

https://blog-cn.celer.network/2023/03/22/brevis-a-zk-omnichain-data-attestation-platform/

https://drive.google.com/file/d/1ibuHChcYcYCN6JelRAQPnM4rkaB9EgAM/view

https://blog.succinct.xyz/blog/telepathy

https://docs.telepathy.xyz/protocol/overview

https://blog.celer.network/2023/03/21/brevis-a-zk-omnichain-data-attestation-platform/

Starting from 2022, many cross-chain projects, including Multichain, Succinct, and Celer, have launched their ZKP cross-chain testnets, thus putting a spotlight on ZKP-based cross-chain communication through light clients. ZKP-based cross-chain communication, in essence, falls into the category of native verification, which enables trustless verification of consensus on the source chain and helps DAPPs build the most secure multichain (or full-chain) ecosystem. It is said to be the safest because compared with the existing cross-chain solutions that requires to trust a third party, ZKP-based cross-chain communication does not introduce any trust assumptions, while users only need to trust the consensuses of the source chain and the destination chain. It is from this perspective that ZKP-based cross-chain communication can be said the safest cross-chain method. The complexity of ZKP cross-chain technology, however, means a relatively high threshold.

In terms of verification methods, cross-chain interoperability protocols (CCIP) can be divided into three types, i.e. external verification, native verification, and local verification. Each type of CCIP has its limitations: it is difficult to juggle trustlessness, scalability, and universality.

External verification refers to the practice of introducing a group of trusted external nodes for the verification of cross-chain messages, provided that users must trust the relay network consisting of the external nodes. Cross-chain solutions based on MPC, Oracle systems, PoS/PoA, multi-signature, and TEE fall into this category. External verification is based on the trust of third-party relay nodes or oracle machines, and therefore, trustless cross-chain messaging through relay is impossible, not to mention that relayers and oracle machines are not worthy of complete trust in certain cases. Nevertheless, it is the mainstream way of implementing cross-chain communication on the market, which has been adopted by well-known projects such as Multichain, Wormhole, Axelar, and LayerZero.

Local verification, also known as P2P verification, refers to direct verification by the counterparties in a cross-chain interaction. It is essentially about the atomic exchange based on the hash timelock. The parties of a transaction verify the behavior of each other. In case one party does evil, both will face losses because they have shared interests. In practice, there will be a liquidity provider acting as a counterparty just for matchmaking. Connext and Hop are typical in this category. Nevertheless, such solutions are only suitable for cross-chain transfer of assets, not for generic cross-chain messaging; hence not universally applicable.

Native verification refers to the practice in which the light node deployed on the destination chain verifies the messages sent from the source chain, without trust assumptions. In theory, users only need to trust the consensuses on the source chain and the destination chain and ensure there is no rollback on the two chains. Generally, block redundancy will be set by the light node to prevent possible rollbacks. Typical native verification projects include Rainbow Bridge, as well as ZK-based cross-chain solutions emerging lately, e.g. zkRouter, Succinct Labs, =nil; Foundation, etc.

A comprehensive comparison of the three types of CCIP is shown in Table 1.

The prosperity of multichain ecosystems has spawned the need for cross-chain interactions. As a result, many cross-chain projects such as Multichain (anyCall), Layerzero, and Wormhole have come into being. These projects value universality and scalability as they require a trusted relay network.

Nevertheless, from 2021 to 2022, cross-chain projects such as Ronin Network, Horizon, BNB Chain, Wormhole, and Nomad suffered hacker attacks, which resulted in tremendous asset losses. Users of multichain ecosystems and cross-chain solution providers have found that trustless cross-chain solutions provide a safer choice for users, despite their weak scalability. As such, native verification becomes the best way to realize trustless cross-chain interactions.

Native CCIPs generally need to consume a lot of Gas to verify the consensus of the source chain on the destination chain, because the light client on the destination chain needs to obtain a large amount of source chain data to generate information about the consensus. When ZKP is used for native verification, the light client on the destination chain only needs to obtain the concise ZKP to verify the transaction on the source chain. This is why it is considered a better solution.

Consensuses of public-chain ecosystems such as Polkadot and Cosmos naturally allow for cross-chain communication within the ecosystem. However, public chains that are not in the same ecosystem, such as Ethereum and Solana, cannot enjoy the advantage. While mainstream third-party cross-chain bridges, including Multichain, Layerzero, and Wormhole, require the trust of a relay network, cross-chain solutions based on ZKP do not require the trust of a third party. They directly transmit the consensus proof of the source chain to the destination chain for verification by the light client on the latter. This is essentially how consensus cross-chain works.

However, the way in which consensuses are generated varies with the chain, and as a result, the data required to verify them are different. The difficult part about ZKP-based cross-chain interactions is how to generate the ZKP for the consensus on the source chain because it is supposed to be generated on the basis of the data of source chain consensus. The ZKP circuits generated by different source chain consensuses also need to be customized.

The process in which different public chains generate consensuses varies greatly. Similarly, the process of generating ZKP also varies. Take Ethereum POS as an example.

Ethereum has designed a complex verifier selection mechanism to generate consensus. Ethereum has added a key feature in the Altair upgrade, that is, a sync committee specifically designed to enable light clients to sync block states. Ethereum uses the RANDAO algorithm to randomly select 512 verifiers to form a sync committee, the information of which is stored on the Beacon Chain and updated every 256 Epochs (about 6.4 minutes each). The role of the sync committee is to continuously sign block headers. The transition of Ethereum state will be confirmed when two thirds of the sync committee members have signed.

The Beacon Chain uses the BLS12-381 algorithm as a way for verifiers to participate in the POS consensus. The BLS signatures of multiple verifiers in the blocks of the Beacon Chain can be further aggregated into one single signature, thus effectively reducing the data communication and on-chain storage pressures brought about by the multiple signatures. Meanwhile, the verifiers only need to verify a single signature to make block verification more efficient.

As the sync committee is an integral part of the consensus mechanism, light clients can obtain the verified consensus state without accessing the entire verifier set. In order to verify the consensus state of the source chain, the light client on the destination chain will download part of the data for verification and calculation, including:

(1) Merkle path proof. This is to verify that the current committee (sync_cmts) verifying the signature of the current block is the next committee designated in the verified block header.

(2) Aggregation Committee Public Key. According to the actual signature of the current block's sync committee, the aggregation committee public key can be calculated.

(3) Signature of the sync committee. The aggregation committee public key can be used to verify the signature of the sync committee in the new block.

The above method is a common solution for native verification. However, direct verification of a source chain consensus on the destination chain involves a huge amount of data verification and calculation on the destination chain; hence high gas consumption. The use of the ZKP technology to complete the calculation and verification of the source-chain data off-chain, generate a concise source-chain consensus, and then pass it to the destination chain, serves to greatly reduce the Gas consumption on the destination chain, which is why a ZKP-based on-chain light client can verify the source chain consensus at a low cost. ZKP-based cross-chain protocols conduct aggregated public key verification of BLS signature off chain and generate a ZKP. Simply by verifying the ZKP, the client on the destination chain will have the source chain consensus verified. The specific code is shown in Fig. 1.

The above ZKP-based process of syncing consensus through the light client shows that the generation of off-chain proof is closely related to the consensus mechanism on the source chain and the supportiveness of the light client. It also explains why implementing an on-chain light client is so difficult, and why the light client needs to check if the code should be synced whenever Ethereum is upgraded.

ZKP-based cross-chain processes are roughly the same. So when analyzing individual cases, we placed more emphasis on the uniqueness of each cross-chain project. As to how ZKP-based cross-chain communication works, please refer to the previous blog post (https://www.theblockbeats.info/news/35560).

zkRouter is a ZKP cross-chain project developed by Multichain. According to its white paper, Multichain's vision is to develop zkRouter into a part of its MBI (Multiple Blockchain Interaction) as an underlying trust mechanism. This has been elaborated in the previous article. But a few key points are worth mentioning here.

The information now available shows that the zkRouter cross-chain bridge between the Goerli testnet and the Fantom testnet will be launched soon. The zkRouter protocol mainly includes four steps: initial setup (Setup), consensus proof generation (Proof Gen), consensus proof verification (ProofVerify), and interoperability contract call (InterOperCall), as shown in Fig. 2.

(1) Setup

To complete the verification of the source chain ZKP, the light client on the destination chain must have access to the consensus state of the previous source chain block. The continuity of consensus state means that the consensus result of the current block is based on the updated consensus result of the preceding block. Therefore, the light client on the destination chain must first obtain the current consensus state of the source chain before verifying the correctness of subsequent block consensus.

The light client on the destination chain needs to access the initial data (initial_data), which includes the initial block height, block header hash, and so on. This initial setting needs to be done once only, and will be automatically updated as cross-chain interaction occurs.

(2) Proof Gen

This step occurs during specific cross-chain processes. When a new block is generated by the source chain, the destination chain needs to sync the updated information, including the state of the previous block, the selection of block-generating nodes, and the legality of signature nodes. For non-immediate consensus mechanisms, there is a need to set a certain number of redundant blocks to avoid losses incurred by forking. Then, the relayer uses the off-chain ZKP technology to calculate and generate a ZKP, which is then synced to the destination chain.

(3) ProofVerify

After the concise ZKP is submitted to the destination chain by the relayer, it is necessary to verify the ZKP, a task fulfilled by the light client on the destination chain. When the verification is passed, the result is returned and the consensus state of the source chain is updated on the destination chain.

(4) InterOperCall

When the light client on the destination chain has verified the consensus on the source chain (including transactions on the source chain), the participants can initiate cross-chain contract interoperability calls to complete cross-chain interactions. For details, please refer to Multichain's white paper.

The core advantage of zkRouter is that it enables high TPS cross-chain interaction. According to the description, zkRouter's TPS, at its best, can reach the TPS of a public chain, that is, 100 transactions per the testnet data.

The source chain address of Goerli testnet: https://goerli.etherscan.io/txs?a=0x91d1d54572ef662419d9e552a013321b5713e3ad

The destination chain address of Fantom testnet: https://testnet.ftmscan.com/address/0x91d1D54572Ef662419d9E552A013321b5713E3AD#tokentxns

For the specifics of zkRouter, please refer to its white paper.

Hyper Oracle defines itself as a trusted oracle machine network. Unlike other ZKP-based cross chain projects, Hyper Oracle stresses the transmission of the entire consensus. It's Hyper Oracle's vision to develop an end-to-end trustless solution, which requires the light client to verify the entire consensus of Ethereum PoS.

When implementing Ethereum POS, the consensus of the sync committee is already a part of the entire consensus, so why stress the transmission of the entire consensus?

Brevis defines itself as a full-chain computing and verification platform, which is essentially a cross-chain communication solution that achieves trustless cross-chain communication by generating ZKP-based consensus proofs. Brevis consists of three components, namely zkFabric, zkQueryNet, and zkAggregatorRollup. For now, it covers EVM and NON-EVM chains.

zkFabric is mainly used to collect block headers and generate consensus proofs after their validity is verified through the ZKP light client circuit. It plays a similar role to the relayer or verifier in the ZK cross-chain process. In this particular system, however, the destination of the relay is zkAggregatorRollup.

ZkAggregator Rollup is a ZK rollup blockchain supported by light ZKP virtual machines, which aggregates different proofs and input information from zkQueryNet and zkFabric. According to Celer's description, zkAggregatorRollup VM runtime has the following features:

(1) Recursive verification of proofs generated by zkQueryNet and zkFabric;

(2) Store block headers from zkFabric that have been verified by ZKP;

(3) Store query requests and ZKP validation results.

ZkQueryNet is an open market that provides a ZKP query engine, which can directly take in data queries from on-chain smart contracts, and generate query results and corresponding ZKP query proofs through the ZKP query engine circuit. The result will also be saved in the Query Result, which belongs to the zkAggregatorRollup module, as shown in Fig. 3.

Compared with other cross-chain projects, Brevis is most distinctively featured by its modularity. Such structured design enhances Brevis' scalability. By encapsulating different functions, Brevis can achieve a unified interface, which is convenient for DAPP calls and also conducive to expansion to cover more public chains in the future

Telepathy is a protocol developed by the Succinct team, with the aim to provide users with permissionless and trustless interoperability. Through Telepath, DAPP can securely send messages from the source chain to any destination chain. This is in line with the traditional model for defining cross-chain messaging.

The Telepathy cross-chain communication model mainly consists of five steps, as shown in Fig. 4.

(1) The multichain DAPP contract issues a multichain interoperability order.

(2) When Telepath Broadcaster receives such order, the Ethereum mainchain will strike a final consensus in about 12 minutes.

(3) The Telepathy Operator uses the consensus to generate a ZKP consensus proof.

(4) The Telepathy Relayer passes the consensus proof to the contract on the destination chain.

(5) The light client contract on the destination chain verifies the consensus proof.

This generic model is suitable for the cross-chain messaging among multiple chains. Across, a well-known cross-chain project, has announced the use of Telepathy to build a cross-chain bridge between Avalanche and BNB Chain.

=nil; Foundation has a similar positioning as Brevis, with the goal of becoming a multichain proof market where DAPPs can request =nil; Foundation to generate proofs as needed. A detailed description is beyond the scope of this text.

But remember that the zkLLVM mentioned in the previous article is also one of its core products. The product is aimed to help developers compile ZKP in a high-level programming language, which greatly lowers the entry threshold for developers. It allows developers to focus on circuit design using a language they are familiar with, rather than struggling to learn a domain-specific language.

So far, many teams have committed themselves to the development of ZK cross-chain bridges. As the generation of ZKP is closely related to the consensus on the source chain, and as the way in which consensus is reached and the signature algorithm used by different chains vary, different solutions used in practice vary in terms of efficiency and characteristics, as shown in Table 2.

Although these projects build their ZKP systems on the basis of the SNARK technology, it is difficult to ensure the consistency of algorithms, the degree to which algorithms are optimized, and the hardware used. The above ZKP generation speed is for reference only. More detailed data require more rigorous benchmark testing.

At present, most ZK cross-chain bridges are supportive of cross-chain communication among non-EVM chains, and in this regard, there is little difference between different projects. Going forward, the main competitive advantages of ZK CCIPs will lie in algorithm optimization, multichain deployment, and contract security.

The off-chain generation of ZKP requires high-performance servers with larger memory, which means high device costs. Optimized algorithms, in a degree, can save computational power.

In the past two months, many cross-chain protocols have made their moves revolving around ZKP cross-chain development, but primarily through the launch of testnet, rather than mainnet. Moreover, many cross-chain protocols generally link one or two chains without achieving multichain interoperability. Therefore, the more chains a cross-chain bridge can support in the future, the more competitive it will become.

As ZK cross-chain projects have not been put to large-scale market test, whether they can survive in the market largely depends on the security of contracts. This issue, though ignored by most people nowadays, is likely to become the biggest concern when it comes to ZKP projects.

We have seen a number of blockchain security accidents related to cross-chain protocols, which have raised concerns among almost all practitioners. More importantly, most mainstream cross-chain protocols fall into the external verification category, which does not allow for trustless verification. Therefore, serious security risks remain. If the relayers collide to do evil, the participants in the multichain ecosystem are likely to face immeasurable losses. As a type of native verification, ZKP-based cross-chain solutions have their unique advantages, i.e. they are trustless and universally available. They consume much less gas compared to direct verification of the original source chain data on the destination chain. The frequent launch of ZKP-based cross-chain testnets indicates that many cross-chain projects have been keenly aware of this. However, ZKP-based cross-chain protocols are still in their early stages of development. Whether they can provide users with a more secure cross-chain experience remains an issue that needs to be further tracked and observed.

Reference:

https://hyperoracle.medium.com/zkpos-end-to-end-trustless-65edccd87c5a

https://blog-cn.celer.network/2023/03/22/brevis-a-zk-omnichain-data-attestation-platform/

https://drive.google.com/file/d/1ibuHChcYcYCN6JelRAQPnM4rkaB9EgAM/view

https://blog.succinct.xyz/blog/telepathy

https://docs.telepathy.xyz/protocol/overview

https://blog.celer.network/2023/03/21/brevis-a-zk-omnichain-data-attestation-platform/