The vigorous development of multi-chain ecology makes cross-chain protocols indispensable. However, due to the large amount of assets mortgaged by the cross-chain bridge, and the fact that the logic of the cross-chain protocol is more complex than that of a general Swap, the possibility of the cross-chain protocol being attacked by hackers is getting higher and higher. By the end of 2022, the losses caused by cross-chain bridge security issues have reached more than 2 billion US dollars. Among them, cross-chain bridges that have lost hundreds of millions of dollars include Ronin Network, Horizon, BNB Chain, Wormhole, Nomad, etc.
Cross-chain bridge mainly solves the problem of cross-chain interoperability. A large number of cross-chain bridge security incidents in the past have shown that the current cross-chain interoperability solution still has huge room for optimization. Recently, Multichain launched zkRouter, a trustless cross-chain solution based on zero-knowledge proof.
Multichain is a leading project in the cross-chain field. It received a US$60 million investment led by Binance at the end of 2021, and currently ranks first in the cross-chain market share. Uniswap's cross-chain governance vote was aroused before, but Curve, the stablecoin DEX king, has long used Multichain's anyCall to complete multi-chain LP incentive distribution. Table 1 gives a comparison of relevant data of current major cross-chain projects.
Table 1 Comparison of relevant data of current major cross-chain projects
(Data source: https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148)
This article will focus on analyzing the latest trustless product zkRouter launched by Multichain based on ZKP, and also make a comparison with other excellent ZK cross-chain projects on the market.
1. ZKP has become the best solution to solve the problem of trustless cross-chain
The sovereign zone characteristics of the blockchain make it difficult for on-chain contracts to obtain accurate off-chain information, and they have to rely on third parties to relay assets and messages across chains to maintain the security of assets and the credibility of information transfer between contracts on different chains. reliable. This is similar to the role of an oracle. This means that transactions between cross-chains need to be based on trust in third-party relay cross-chains or oracles, and relay cross-chains and oracles are sometimes difficult to fully trust. Therefore, how to obtain off-chain information through trustless means has become an important research topic.
Whether cross-chain relay is achieved through relay networks, oracles or chains, partial or even complete decentralization can be achieved, but trustlessness cannot be achieved. Currently, the security of applications built through mainstream cross-chain bridges on the market is entrusted to third parties. Users need to trust the cross-chain relay network to accept the source chain status it delivers, but cannot verify their security, which hinders The emergence of a true cross-chain ecosystem. In a sense, the most important feature of a cross-chain bridge should be to achieve complete trustlessness. If cross-chain services can be built in a trustless manner, and the light client on the chain can independently verify and directly adopt the source chain information, this will greatly promote the further development of the multi-chain ecology and the large-scale use of native multi-chain applications. emerge.
The emergence of ZKP technology and the cross-chain bridge constructed by ZKP technology will become the best solution to achieve trustless cross-chain.
2. Cross-chain trustlessness based on ZKP
An excellent cross-chain protocol must first be safe, secondly have a rich ecosystem, and finally have low cross-chain costs and fast speed. Therefore, an excellent cross-chain protocol should have the characteristics of high degree of trustlessness, high degree of decentralization, good scalability, fast cross-chain speed and low cost. Most people agree with this view, but I think there may be some problems with this view. If a cross-chain protocol achieves complete trustlessness, do we still need to consider whether it is decentralized?
Many cross-chain projects now use a dedicated chain to implement cross-chain operations. This approach makes the cross-chain agreement more decentralized, but does not achieve trustlessness. Decentralization still means that cross-chain initiators place their cross-chain security on a decentralized network. But what cross-chain protocols should achieve is trustlessness, not decentralization, because once trustlessness in cross-chain operations is achieved, the problem of decentralization will no longer exist. Just imagine, when the ZKP generated by the relay can be easily verified by the users themselves, do we still need to discuss the necessity of decentralization?
In the process of cross-chain operations, trusting the source chain consensus and target chain consensus is the prerequisite for the existence of cross-chain operations. Additionally, trusting any organization reduces the security of your assets. It is best to achieve trustlessness in cross-chain operations, and trustlessness is ultimately a trustless assumption. To achieve trustless cross-chain, the best way is to use ZKP to build the underlying trust mechanism of the cross-chain interoperability protocol and achieve trustless cross-chain.
Cross-chain bridges built based on ZKP generally involve three logical roles:
1. The generator of Proof, its function is to observe the status of the original chain and use the original chain data to generate ZKP.
2. Relayer, delivers ZKP to the target chain.
3. On-chain light client. The on-chain light client is also a verifier and can independently complete the verification of ZKP.
The prover and relay can be the same person or different people, because it is the on-chain light client that decides whether to adopt ZKP. Therefore, this setup does not pose any security issues. In addition, in ZKP, as long as there is an honest relay node, the normal operation of the protocol can be guaranteed.
All current ZK interoperability protocols basically revolve around Ethereum. Some implement the interoperability between Ethereum and other heterogeneous chains, and some want to complete the interoperability between Ethereum and its isomorphic chains. However, no matter which chain the interoperability between Ethereum and Ethereum is implemented, it is necessary to generate Ethereum's consensus certificate and implement the Ethereum light client's verification of the consensus certificate on other chains.
3. zkRouter and other ZK interoperability protocols
The cross-chain protocol built on ZKP can perfectly achieve trustlessness. The most typical protocol currently is probably zkRouter launched by Multichain.
1. How zkRouter implements cross-chain based on ZKP
Whether it is cross-chain assets, cross-chain messages, or cross-chain interoperability, they essentially do the same thing, that is, the user initiates an action on the source chain through a smart contract and verifies the action on the target chain. As long as this action can be verified trustlessly, it can support a true native multi-chain and achieve true multi-chain interoperability.
The zkRouter white paper describes delivering Ethereum messages to Fantom, which involves the following steps:
First, a transaction occurs in the source chain (the transaction can be verified through the block header hash and Merkel tree path);
The relayer submits the transaction to the light client on the target chain;
The on-chain light client verifies the transaction.
Readers will have two questions when seeing this:
What are light clients and on-chain light clients?
Where is ZKP reflected in the above steps, and what is the role of ZKP?
(1) Light client and on-chain light client
Since the launch of the LayerZero protocol, the concept of light clients seems to have been abused. There is a difference between ultra-light nodes in the LayerZero protocol and light clients in the usual sense. LayerZero ultra-light nodes only verify whether the data passed by the relay matches the data passed by the oracle, and do not directly verify the transactions on the chain. In the usual sense, light clients directly verify transactions on the chain. In essence, LayerZero still needs to trust that relayers and oracles will not work together to cause evil, and has not achieved trustlessness.
Let’s start with how to verify an on-chain transaction and explore what a real light client and an on-chain light client are.
What is a light client? Many transactions will occur in Ethereum at the same time, and many transactions have occurred in history. Without a light client, users must synchronize all transaction data of all blocks in order to verify the transaction, which is obviously impossible.
In the Bitcoin network, each block has a block header, which contains a pointer to the previous block and the Merkle root of the hash of all transactions in the current blockchain. The pointer to the previous block can ensure that the transaction data in the previous block has not been tampered with, and the Merkle tree in each block contains all transactions in the current block, and the root hash value can verify all current transactions. trade. As shown in Figure 1. This ensures that all transaction information contained in current and historical blocks will not be tampered with. Ethereum inherits this verification method. The Ethereum network's block header also contains the Merkle root and a pointer to the previous block, which can be used to verify any type of data stored.
Figure 1 Schematic diagram of the Merkle tree structure of the Bitcoin network
As shown in Figure 1, perform hash operations on transactions L1, L2, L3, and L4 respectively, and obtain Hsh0-0=hash(L1), Hash0-1=hash(L2), Hash1-0=hash(L3), Hash1 -1=hash(L4).
To obtain the root hash (Top Hash), the light client only needs to calculate:
Hash0=hash（Hsh0-0,Hash0-1）
Hash1=hash（Hash1-0,Hash1-1）
Top Hash=hash(Hash0,hash1)
The hash operation can only be one-way, that is, Y=Hash(X) can only be calculated through X, but X cannot be calculated through Y. Therefore, the light client only needs to synchronize the root hash value in the block and ask the full node path hash data to verify the authenticity of the transaction.
If the light client wants to verify L1 transactions. If the light client has the root hash value, it can verify the L1 transaction by applying for the values of Hash1 and Hash0-1 from the full node. The specific method is:
1. Calculate Hash0-0;
2. Based on the Hash0-1 synchronized by the whole node and the Hash0-0 calculated in the previous step, Hash0=hash(Hash0-0, Hash0-1) can be calculated.
3. Based on Hash1 synchronized by the whole node and Hash0 calculated in the previous step, calculate the root hash RootH = hash (Hash0, Hash1), and compare whether the calculated root hash RootH is equal to the Top Hash synchronized by the light client. If the two are the same, it proves that the L1 transaction is indeed on the chain and has not been changed. This is how the entire blockchain implements trusted light clients.
The above process demonstrates how the light client verifies on-chain transactions. So if the light client of the source chain can be implemented on the target chain, that is, the light client on the chain, can it be possible to verify the source chain transactions on the target chain?
Just imagine, in the specific application of cross-chain, the key difficulty is that the transactions that occur in the source chain cannot be verified trustlessly on the target chain, but need to be relayed through a third party, which invisibly reduces the security of cross-chains. . If you use a smart contract to implement a light client on another chain, you can verify the transactions that occurred on the source chain on the target chain, achieving trustless cross-chain.
(2) Why do on-chain light clients need to use ZKP technology?
The previous section explained how to verify source chain transactions through the light client on the chain, which can completely achieve cross-chain. So why use ZKP technology?
Light client verification involves a large number of calculations in the consensus generation process. If these calculations are completed on the chain, it will consume extremely high gas fees and is not feasible for generalization. Zero-knowledge proof technology can transfer a large number of calculations in the consensus generation process to be performed reliably off-chain, thereby generating concise proof results that can be verified on the chain with less gas.
Whenever relays are involved, users will feel that they are suspected of being centralized and not trustworthy enough. However, the relayer in the cross-chain bridge implemented based on ZKP is only responsible for relaying messages and is not responsible for verifying messages. The verification work is completed by the light client of the target chain. The rigorous mathematical and cryptographic proofs can ensure that the light client of the target chain can complete the verification and achieve trustlessness.
(3) How zkRouter uses ZKP technology to achieve cross-chain
The cross-chain solution implemented by zkRouter is described in detail in its white paper, but there is currently no document explaining it on the market. To understand zkRouter, some background knowledge is needed.
At present, there are several typical Turing-complete proof algorithms in the application field of zero-knowledge proof. The most popular ones are zkSnark (zero-knowledge succinct non-interactive arguments of knowledge, zero-knowledge succinct non-interactive arguments of knowledge) and zk-Stark (zero-knowledge succinct non-interactive arguments of knowledge). Zero-Knowledge Scalable Transparent Argument of Knowledge, zero-knowledge scalable transparent knowledge argument). The size of the ZKP file generated by zk-Stark is about 200KB, and the size of the ZKP file generated by zk-Snark is about 192B. The ZKP file generated by zk-Stark is too large. If zk-Stark is used to achieve cross-chain, the gas consumed by the target chain will be very large, so it does not have economic advantages in specific applications. The ZKP generated by zk-snark is widely used in the blockchain due to its advantages of non-interaction, fast proof generation, and short proof results. Currently, most ZK cross-chain bridges on the market use zk-Snark. , or a variant of zk-Snark technology, which zkRouter also uses zk-Snark.
The zkRouter protocol mainly consists of four steps.
1. Initial setup (Setup)
In order for the target chain light client to complete the verification of the source chain ZKP certificate, it must have the consensus state of the previous source chain block. The consensus state of the blockchain has continuity, that is, the current block consensus result is based on the previous block. Updates to the consensus result of the block. Therefore, the target chain light client must first obtain the current consensus status of the source chain before it can verify the correctness of subsequent block consensus.
The light client of the target chain needs initial initial_data at the beginning. This data includes the initial block height, block header hash, etc. This initial setting only needs to be set once, and the data will be automatically updated as cross-chain behavior occurs.
2. Consensus Proof Generation (Proof Gen)
This step occurs in specific cross-chain behaviors. When the source chain generates a new block, the target chain needs to synchronize new information. This new information includes the status of the previous block, the selection of the block producing node, the legality of the signature node, etc. For non-instant 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 it to the target chain.
3. Verify consensus proof (ProofVerify)
After the concise ZKP is submitted to the target chain by the relayer, the ZKP needs to be verified. This part of the work is completed 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 in the target chain.
4. Interoperation contract call (InterOperCall)
When the target chain light client passes the verification of the source chain consensus (including source chain transactions), participants can initiate cross-chain contract interoperation calls to complete cross-chain interaction.
For example, for cross-chain Swap, any participant submits the TXS corresponding to the source chain transaction and the corresponding Merkel tree certification path. Based on the existing source chain consensus information of the light client, the contract can easily verify the authenticity of the transaction.
There are quite a few instructions for the Ethereum->Fantom ZK cross-chain implementation in the Multichain white paper. The steps are similar to the above process and will not be repeated here.
2. Other major ZK cross-chain solutions
Currently, many teams are working on the development of ZK cross-chain bridge. Since the generation of ZKP is closely related to the consensus of the source chain, and different chains reach consensus in different ways and use different signature algorithms, in practice, the methods used by light clients on different chains to be implemented by the project team will also be different. Different, but the core algorithm is basically similar to that of zkRouter.
（1）Electronlabs
Electronlabs has implemented a two-way cross-chain bridge from the Ethereum test network to the Near test network, which shows that Electronlabs has not only implemented Ethereum's light client on Near, but also implemented Near's light client on the Ethereum network. Cosmos supports Ed25519 [Ed25519 has become the preferred signature scheme for blockchain ecosystems such as Cosmos, NEAR, Solana, etc. Verifying blockchain consensus requires verifying a large number of Ed25519 signatures (validator signatures). Therefore, a concise verification of a batch of Ed25519 signatures is required. ] signature algorithm, but Ethereum does not support this algorithm. Therefore, on-chain verification of Ed25519 signatures on Ethereum requires some additional work.
In addition, the Ed25519 algorithm does not support aggregate signatures, so Eletronlabs uses a recursive method to implement verification of a large number of Ed25519 algorithms. Verifying signatures generates large circuits, so the key question is how to efficiently and cost-effectively verify Ed25519 signatures from any blockchain in the Cosmos SDK on the Ethereum chain. Electronlabs’ solution is to build a zk-Snark that generates a proof of signature validity off-chain, and only verifies that proof on the Ethereum chain.
Judging from the current results of Electronlabs, it has made some progress in the deployment of heterogeneous chains, including the public chain signature algorithm of the Cosmos series, which is Ed25519. In the future, its public chain ability to expand the Ed25519 signature algorithm should be strong.
（2）Succinct
Succinct also only launched the one-way ZK cross-chain bridge. The difference is that it launched the ZK cross-chain bridge of Goerli->Gnosis, Optimism, Polygon, Avalanch and other test networks. The only source chain is Goerli.
The most complicated part of ZK cross-chain is to set up the circuit according to the source chain consensus. There will not be too much development work on the target chain client. Therefore, Succinct's launch of ZK cross-chain bridges on Goerli->Gnosis, Optimism, Polygon, Avalanch and other test networks is actually at the same progress as launching only a one-way cross-chain bridge. Succinct also uses the zk-Snark scheme. Its basic scheme is not very different from the general scheme, so I will not go into details here.
Succinct's main goal is to expand the second-layer network around Ethereum. Judging from the current progress, if it can complete the cross-chain of Gnosis, Optimism, Polygon, Avalanch->Goerli in the future, there will be a lot of room for imagination. However, given that the generation of source chain ZKP requires a large amount of circuit settings and the consensus varies greatly, this part of the work is the most time-consuming part of ZK cross-chain implementation, and Succinct has not yet completed it.
（3）nil.foundation
Nil has implemented the verification of the status of the Mina test network on the Ethereum test network and the Polygon test network, but has not implemented the verification of the status of the Ethereum test network and the Polygon test network on the Mina test network. Therefore, in terms of progress, Nil and other ZK cross-chain projects In the same echelon.
However, the nil.foundation project has received investment from Starkware and Mina, the leading organizations on the ZK track, and its technical strength is evident. In addition, Nil has open sourced the zkLLVM product, which is positioned to help developers compile ZKP using high-level languages, greatly lowering the entry barrier for developers. Through this tool, developers can focus on circuit design using a language they are familiar with, rather than falling into the trap of learning a domain-specific language-DSL. Compiling zero-knowledge circuits often requires domain-specific languages and toolkits and takes a lot of time.
（4）Herodotus
Herodotus official description uses a cross-chain bridge implemented by "MPC+light client+ZKP", using the optimistic MPC method to challenge messages relayed by relayers. But since any relayer can relay the generated ZKP to the target chain, verification is done by the light client on the target chain. If you still need a trustworthy MPC network, adding ZKP will not make much sense. Of course, its test network has not yet been launched, and the specific plan has yet to be announced by the project party.
（5）Polyhedra
Polyhedra is currently the cross-chain bridge with the most online testnets. The online testnets include Goerli, BNB Chain Testnet, Polygon Testnet, Fantom Testnet, and Avalanche Testnet. Polyhedra is currently launching NFT cross-chain. Users can generate cross-chain NFT through Polyhedra, and then use its NFT cross-chain bridge to cross-chain. Polyhedra has received $10 million in support from institutions including Binance Labs, Polychain Capital, and others.
However, after analysis and testing, we found that the test network of this project did not use ZKP, and the light client did not verify the Merkle tree. The details are as follows.
Test transaction source chain address:
https://mumbai.polygonscan.com/tx/0xc89904563b9f26a2eaeae5da91e87f6c86a8a2ebc33ca9d23a02b9ffb0e58aca
Test target chain address:
https://testnet.bscscan.com/tx/0xbcbe3f47ae9b2d17c38d0ee4271669690e5c5049b2dd150c90ad50efbaa9848b
Intermediate nested contract address:
https://testnet.bscscan.com/address/0x7b95cf4cefdd218017e0e0e4da99f3b2c6f9e2a5
The final call verifies the Merkle tree contract address:
https://testnet.bscscan.com/address/0x3BBd3ECa3C1bA24603f8C8EC247f225fb629a40B
Figure 2 polyhedra related contract code
The contract code is shown in Figure 2. Hash header verification directly returns true. There is no ZK technology that is not used, and the hash header is not verified, so the correctness of cross-chain messages is assumed. Judging from the test network contract, we cannot see its progress. Of course, we will continue to pay attention to its test network dynamics.
4. Development prospects of cross-chain projects based on ZKP
Currently, ZK cross-chain has become a hot spot in the industry, and there are many related solutions. Future competition is likely to revolve around the following aspects.
1. Contract security. Although many ZK cross-chain solutions are working hard to achieve trustlessness, ZKP only provides the underlying technical architecture. The underlying technical architecture is stable, but it is still difficult to avoid security issues that may arise in the writing and operation of smart contracts.
2. Multi-chain bidirectional deployment. The progress in this direction is not yet clear. None of the above cases has achieved multi-chain bidirectional deployment. If any cross-chain bridge can take the lead in realizing multi-chain bidirectional deployment, it will become a great competitive advantage.
3. Whether it is a trustless ZK cross-chain bridge. From the above discussion, readers can find that the most important advantage of the ZK cross-chain bridge is that it can realize trustless cross-chain. If it cannot realize trustless cross-chain, then it will ZKP applications are of little significance in the cross-chain field.
5. Summary
We compared several well-known projects in the ZK cross-chain track from the dimensions of test network progress, Non-EVM support, product reliability, team technical capabilities, and whether to trust them, as shown in Table 2.
Table 2 Comparison of several current major zk cross-chain track projects
As can be seen from Table 2, currently several major zk cross-chain projects are basically in their infancy, and the technical solutions are roughly the same. However, the complete trustlessness of ZKP in theory will enable cross-chain implementation based on ZKP trustlessness in the future, which will be of greater significance in promoting the development of multi-chain ecology, multi-chain universe, and native multi-chain applications.
According to the roadmap announced by Multichain, there have been two solutions since the birth of Anyswap, one is a cross-chain solution based on MPC, and the other is a solution based on ZKP. Regarding the zkRouter developed by Multichain, I think there are several points worth looking forward to:
1.Multichain has a profound cross-chain technology background. Multichain has been deeply involved in cross-chain business for many years and has a profound technical background. Based on this, we can expect Multichain’s zkRouter to make greater progress on the ZK cross-chain track. After the zkRoutr test network is online, users can also experience the zkRouter experience for themselves. Of course, as a product in the POC stage, it is still difficult for ordinary users to obtain a direct trustless experience from use, including the cross-chain speed, cross-chain fees and other indicators that zkRouter may achieve in the future. These contents still need to be studied and judged by more experts from a more professional level and perspective.
2. A huge ecological partner. Multichain has in-depth cooperation with thousands of multi-chain projects, an advantage that other cross-chain protocols do not have. Therefore, once zkRouter enters the practical stage, with the help of Multichain's huge ecosystem, zkRouter is entirely likely to become a strong competitor for the next generation of cross-chains.