Is ZKP the only way to secure cross-chain?
From 2022, with the launch of the ZKP cross-chain testnet by many cross-chain projects such as Multichain, Succinct, and Celer, ZKP-based light client cross-chain has become a hot spot in the industry. The essence of ZKP cross-chain belongs to the category of native verification, which can realize trustless source chain consensus verification and help DAPP build the most secure multi-chain (or full-chain) ecosystem. The reason why it is said to be the safest is that compared with the current cross-chain solution that achieves cross-chain communication by trusting a third party, ZKP cross-chain does not introduce any trust assumptions, and users only need to trust the consensus of the source chain and the consensus of the target chain. From this dimension, ZKP cross-chain is the safest cross-chain method. However, the ZKP cross-chain solution technology is extremely complex, and the threshold is relatively high.
1. Using ZKP to build native verification of light clients is the best way to achieve trustless cross-chain
Cross-chain operable protocols can usually be divided into three types in terms of verification methods, external verification, native verification and local verification. These three types of interoperability protocols have their own limitations, and it is difficult to balance trustlessness, scalability, and versatility.
1. External Validation
External verification refers to the introduction of a group of trusted external nodes to be responsible for the verification of cross-chain messages. The premise is that users must trust the relay network formed by this group of external nodes. Cross-chain solutions based on MPC, Oracle systems, PoS/PoA, multi-signature, and TEE all fall into this category. The external verification cross-chain interoperability protocol is based on the trust of third-party relay nodes or oracles, and it is impossible to achieve trustless message relay cross-chain, but relayers and oracles are also difficult to be verified in some cases. complete trust. This type of cross-chain implementation is the mainstream in the current market, including well-known projects such as Multichain, Wormhole, Axelar, and LayerZero.
2. Local authentication
Local verification is also called P2P verification, which refers to the direct verification of the counterparty, and its core is the atomic exchange based on the hash time lock. During the transaction, both parties to the transaction verify the behavior of the other party separately. As long as one party does evil, both parties will face losses, so their interests are consistent. In practice, in order to match transactions, there will be a liquidity provider acting as a counterparty. Both Connext and Hop can be regarded as typical in this category. However, this type of solution is only suitable for asset cross-chain, not for general message cross-chain, and its versatility is weak.
3. Native authentication
Native verification refers to the deployment of source chain light nodes on the target chain, and the source chain messages are verified by the light nodes of the target chain. There is no trust assumption in native verification. In theory, users only need to trust the source chain consensus and target chain consensus, and ensure that the source chain There is no rollback with the target chain (the light nodes on the chain generally set a certain amount of block redundancy to prevent the rollback of the source chain and the target chain). Typical projects for native verification include Rainbow Bridge, and ZK-based cross-chain solutions in the past two years also fall into this category. Typical ZKP cross-chain projects include zkRouter, Succinct Labs, Nil;Foundation, etc.
A comprehensive comparison of the verification methods of the three types of cross-chain interoperability protocols is shown in Table 1.
Table 1 Comprehensive comparison of three types of verification methods for cross-chain interoperability protocols
The prosperity of multi-chain ecology has given birth to the demand for cross-chain. Many excellent cross-chain projects such as Multichain (anyCall), Layerzero, and Wormhole have been born one after another. These cross-chain projects pay more attention to versatility and scalability, and also require a trusted relay network.
However, from 2021 to 2022, cross-chain projects such as Ronin Network, Horizon, BNB Chain, Wormhole, and Nomad have all been attacked by hackers, and huge amounts of assets have been stolen. Multi-chain ecological users and cross-chain track participants found that although trustless cross-chain is weak in scalability, its trustless feature is a safer choice for users. Therefore, native verification becomes the best way to realize trustless cross-chain.
However, in the usual sense, native cross-chain interoperability protocols need to consume a lot of Gas to verify the consensus of the source chain on the target chain. The reason is that the light client of the target chain needs to obtain a large amount of source chain data to generate information about the consensus. Using ZKP for native verification, by generating concise ZKP proofs, the light client of the target chain only needs to obtain ZKP to verify the transaction of the target chain. Therefore, using ZKP to build a native verification method for light clients becomes a better solution.
2. Realize trustless cross-chain through consensus transmission
The ecological consensus of public chains such as Polkadot and Cosmos naturally supports cross-chains within the ecology, but for public chains that are not in the same ecology, such as Ethereum, Solana and other heterogeneous chains, they cannot take advantage of their cross-chain advantages. Mainstream third-party cross-chain bridges including Multichain, Layerzero, Wormhole, etc. all need to trust the relay network. The cross-chain solution constructed using ZKP does not need to trust a third party. It directly transmits the ZKP consensus proof of the source chain to the target chain. The light client of the target chain only needs to verify the consensus proof of the source chain to achieve consensus cross-chain.
However, the consensus generation principles and methods of different chains are very different, and the data required to verify the consensus are also different. The difficulty of ZKP cross-chain is how to generate the source chain consensus ZKP, and the source chain consensus ZKP is generated based on the source chain consensus data, so the generation of the source chain ZKP also needs to be based on the source chain consensus. The ZKP circuits generated by different source chain consensus also need to be customized.
The consensus generation process of different public chains is very different, and the process of generating ZKP is also different. The following takes Ethereum POS as an example to illustrate this process.
Ethereum has designed a complex validator selection mechanism to generate consensus. Ethereum has added a key feature in the Altair upgrade, which is a sync committee specially designed to support light clients to synchronize block states. Ethereum uses the RANDAO algorithm to randomly select 512 verifiers to form a synchronization committee. The information of the synchronization committee is stored in the Beacon Chain and updated every 256 Epochs (one Epoch is about 6.4 minutes). The role of the synchronization committee is to continuously sign block headers. After 2/3 of the synchronization committee members sign, the Ethereum state transition will be confirmed.
The Beacon Chain uses the BLS 12-381 algorithm as a way for validators to participate in the POS consensus. The BLS signatures of multiple verifiers in the beacon chain block can be further aggregated into a single signature, thus effectively reducing the data communication and on-chain storage pressure of the original several signatures. At the same time, validators only need to verify a single signature to perform block verification more efficiently.
Because the sync committee is an integral part of the consensus mechanism, light clients can obtain the verified consensus state without access to the entire validator set. In order to verify the consensus status of the source chain, the light client of the target chain will download some data and perform verification and calculation, including:
(1) Merkle path proof. The committee that verifies the signature of the current block (sync_cmts) is the next committee specified in the header of the verified block.
(2) Aggregation committee public key. According to the actual signature of the current block synchronization committee, the aggregation committee public key can be calculated.
(3) Synchronize the signature of the committee. Using the aggregated committee public key, verify the committee signature in the new block.
image description
image description
Source: zkPoS: End-to-End Trustless
From the above ZKP light client synchronization consensus process, it can be found that the off-chain proof generation process is closely related to the source chain consensus mechanism and light client support. This is why it is difficult to implement a light client on the chain, and the light client needs to check whether the synchronization code needs to be updated every time Ethereum is upgraded.
3. Comparison of ZKP cross-chain projects
The process of ZKP cross-chain is similar. When analyzing individual cases, the author pays more attention to the uniqueness of each cross-chain project. The basic principle of ZKP cross-chain can be seen in the previous blog (https://www.theblockbeats.info/news/35560).
1. zkRouter（Multichain）
zkRouter is a ZKP cross-chain project developed by Multichain. According to its white paper, its vision is to develop zkRouter into a part of its MBI (Multi-chain Interoperability Protocol) and serve its multi-chain interoperability protocol as an underlying trust mechanism. This part of the content has been explained a lot in the previous article, and here are a few key points.
image description
image description
Source: zkRouter: Trustless, General Cross-Chain Infrastructure
( 1) Initial setting (Setup)
In order for the target chain light client to complete the verification of the source chain ZKP proof, it must have the consensus state of the previous source chain block. The consensus state of the blockchain is continuous, that is, the current block consensus result is updated based on the consensus result of the previous block, so the light client of the target chain must first obtain the current consensus state of the source chain before verifying subsequent blocks The correctness of the consensus.
The light client of the target chain needs initial initial_data at the beginning, which includes the initial block height, block header hash, etc. The initial setting only needs to be set once, and the data will be automatically updated as the cross-chain behavior occurs later.
( 2) Consensus proof generation (Proof Gen)
This step occurs in the specific cross-chain process. When the source chain generates a new block, the target chain needs to synchronize new information, which includes the status of the previous block, the selection of block producing nodes, and the legitimacy of signing nodes. For non-immediate finality consensus mechanisms, it is also necessary to set a certain number of redundant blocks to avoid losses caused by forks. Then the relayer calculates and generates off-chain ZKP through off-chain ZKP technology, and synchronizes to the target chain.
(3) Verify consensus proof (ProofVerify)
After the simple ZKP is submitted to the target chain by the relayer, the ZKP needs to be verified, and this part of the work is done by the light client on the chain. After the verification is passed, the verification result is returned, and the consensus status information of the source chain is updated on the target chain.
( 4) Interoperable contract call (InterOperCall)
After the target chain light client passes the verification of the source chain consensus (including source chain transactions), participants can initiate cross-chain contract interoperability calls to complete cross-chain interactions. For details, please refer to its white paper.
The core advantage of zkRouter is the realization of high TPS cross-chain. According to the description, the TPS upper limit of zkRouter is the TPS of the public chain, and the test network shows that its data can reach 100 TXS.
Goerli test network source chain address: https://goerli.etherscan.io/txs?a=0x91d1d54572ef662419d9e552a013321b5713e3ad
Fantom test network target chain address: https://testnet.ftmscan.com/address/0x91d1D54572Ef662419d9E552A013321b5713E3AD#tokentxns
For the specific solution of zkRouter, you can further refer to its white paper for specific descriptions.
2. Hyper Oracle（Hyper Oracle）
Hyper Oracle defines itself as a trustless oracle network. The difference from other ZKP cross-chain projects is that Hyper Oracle emphasizes the transfer of the entire consensus. The vision of Hyper Oracle is to achieve end-to-end trustless, which requires light clients to verify the entire consensus of Ethereum PoS.
In the implementation of Ethereum POS, the consensus of the synchronization committee is already a part of the entire consensus, why should we emphasize the transmission of the entire consensus?
3. Brevis（Celer）
Brevis defines itself as a full-chain computing and verification platform, which is essentially a cross-chain communication solution, and realizes trustless cross-chain communication by generating ZKP consensus proofs. Brevis includes three components, namely zkFabric, zkQueryNet and zkAggregatorRollup. Judging from the current situation, its coverage includes EVM and NON-EVM chains,
The main function of zkFabric is to collect block headers and generate a consensus proof after proving its validity through the ZKP light client circuit, which is equivalent to the relayer and certifier in the ZK cross-chain role. Of course in this system, the destination of the relay is zkAggregatorRollup.
zkAggregator Rollup is a ZK rollup blockchain powered by a lightweight ZKP virtual machine, which aggregates different proofs and input information from zkQueryNet and zkFabric. According to Celer's description, the zkAggregatorRollup VM runtime has the following functions:
(1) Recursively verify the proofs generated by zkQueryNet and zkFabric;
(2) Store block headers from zkFabric and verified by ZKP;
(3) Store query requests and ZKP verification results.
zkQueryNet is an open market that provides a ZKP query engine, which can directly accept data queries from smart contracts on the chain, and generate query results and corresponding ZKP query proofs through the ZKP query engine circuit. This result will also be saved in Query Result (Query Result belongs to zkAggregatorRollup module).
image description
image description
Source: Brevis: A ZK Omnichain Data Attestation Platform
Compared with other zk cross-chain projects, the biggest feature of Brevis is modularization. This structured design enhances the scalability of Brevis. By encapsulating different functions, Brevis can achieve a unified interface. While facilitating DAPP calls, It is also conducive to the subsequent expansion of more public chains.
4. Telepathy（Succinct）
Telepathy is a protocol developed by the Succinct team with the goal of enabling users to achieve interoperability without permission and trust. Through Telepathy, DAPPs can securely send messages from source chains to arbitrary target chains. This definition conforms to the traditional cross-chain message definition model.
The Telepathy cross-chain communication model mainly has five steps, as shown in Figure 4.
(1) The multi-chain DAPP contract initiates a multi-chain interoperability command.
(2) After the Telepathy Broadcaster receives this instruction, about 12 minutes later, the Ethereum main chain forms a final consensus.
(3) Telepathy Operator uses Ethereum consensus to generate ZKP consensus proof.
(4) Telepathy Relayer passes the consensus proof to the target chain contract.
(5) The light client contract of the target chain verifies the ZKP consensus proof.
image description
image description
Source: Telepathy official profile
5. Nil.foundation
The positioning of Nil is similar to that of Brevis. The goal is to become a multi-chain proof market. DAPPs can request Nil to generate proof data according to their own needs. I won't go into too much detail here.
In addition, the zkLLVM mentioned in the previous article is also one of Nil's core products. This product is positioned to help developers compile ZKP using high-level languages, which greatly reduces the barriers to entry for developers. Through this tool, developers can use the language they are familiar with to focus on circuit design, instead of getting stuck in learning a specific domain language DSL.
4. Summary and Outlook
At present, many teams are working on the development of ZK cross-chain bridge. Since the generation of ZKP is closely related to the source chain consensus, and different chains have different ways of reaching consensus and the signature algorithms used, in practice, the efficiency and characteristics of various schemes are also different, as shown in Table 2.
Table 2 Comparison of main cross-chain protocols based on ZKP
Although these projects are zero-knowledge proof systems based on SNARK technology, it is difficult to unify the implementation algorithm, algorithm optimization degree, and hardware used. Therefore, the above-mentioned ZKP generation speed is only for reference, and more detailed data needs to be more rigorous. Benchmarks.
At present, most ZK cross-chain bridges support NON-EVM, and there is little difference between projects on this point. In the future, the main competition points of the ZK cross-chain interoperability protocol will lie in algorithm optimization, multi-chain deployment and contract security.
Generating ZKP off-chain requires a large-memory high-performance server, which means high equipment costs, and an optimized algorithm can save computing power.
In the past two months, many cross-chain protocols have taken action, basically centering on ZKP cross-chain development. Generally, cross-chain testnets are launched, and not many mainnets are launched. In addition, many cross-chain protocols generally link one or two chains, and do not realize multi-chain interoperability. Therefore, the more chains supported by the cross-chain bridge in the future, the more competitive it will be.
ZK cross-chain projects generally have not undergone large-scale market tests, and the security of contracts will determine whether these projects can survive in this market. At present, this issue is ignored by most people, and future security will become the biggest risk item of the ZKP project.
Cross-chain protocols are the hardest-hit area for blockchain security incidents, which has caused almost all practitioners to worry about cross-chain protocols. What is more serious is that almost all mainstream cross-chain protocols currently belong to the category of external verification. There are serious security risks in realizing trustlessness. Once the relayers join forces to do evil, the multi-chain ecological participants will face immeasurable losses. As a type of native verification, ZKP cross-chain not only has the unique advantages of trustless, universal and other native verification cross-chains, but also has lower gas consumption than the method of directly verifying the original source chain data on the target chain. Recently, cross-chain projects Fang frequently launched the ZKP cross-chain test network, which shows that they have also been keenly aware of this. However, the development of the ZKP cross-chain protocol is still in its early stages. Whether the ZKP cross-chain protocol can bring users a more secure cross-chain experience remains to be tracked and observed further.
Original link
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/
