How does the zkRouter implement secure cross-chain

Original article by hiweiwei.eth

The rapid development of multi-chain ecology makes cross-chain protocol indispensable. However, because a large number of assets are mortgaged by cross-chain Bridges, and the logic of cross-chain protocols is more complex than that of common swaps, the possibility of cross-chain protocols being hacked becomes higher and higher. By the end of 2022, the loss caused by security problems of cross-chain Bridges has reached more than 2 billion US dollars, among which the loss of hundreds of millions of US dollars include Ronin Network, Horizon, BNB Chain, Wormhole, Nomad, etc.

Cross-chain bridge mainly solves the cross-chain interoperation problem. A large number of cross-chain bridge security incidents in the past show that the current cross-chain interoperability scheme still has great room for optimization. Recently Multichain introduced zkRouter, a de-trusted cross-chain solution based on proof of zero knowledge.

Multichain is a leading project in the cross-chain space. It received $60 million in investment led by Binance at the end of 21, and currently holds the number one share in the cross-chain market. Uniswap has had a lot of buzz about cross-chain governance voting, but Curve, the king of Stablecoin DEX, has already done multi-chain LP incentive allocation using Multichain's anyCall. Table 1 shows the relevant data comparison of the current main cross-link projects.

Table 1 Data comparison of current major cross-link projects

(source: https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148)

This article will focus on the zkRouter, Multichain's latest de-trusted product based on ZKP, as well as other excellent ZK cross-chain projects on the market.

First, ZKP becomes the best solution to de-trust cross-chain

The sovereign regional characteristics of blockchain make it difficult for on-chain contracts to obtain accurate off-chain information, and they have to rely on a third party to relay and cross-chain assets and messages, so as to maintain the security of assets between contracts on different chains and the reliability of information transmission. This is similar to the function of the prophecy machine. This means that cross-chain transactions need to be based on trust in a third party's relay cross-chain or predictor, which can sometimes be difficult to trust completely. Therefore, how to obtain information out of chain by means of trust has become an important research topic.

Cross-chain relaying, whether through relay networks, prophecy machines or chains, can be partially or completely decentralized, but not trust-free. At present, the security of the applications constructed by the mainstream cross-chain bridge in the market is entrusted to the third party. Users need to trust the cross-chain relay network so as to accept the state of the source chain transmitted by it, but cannot verify its security, which hinders the emergence of a real cross-chain ecology. In a sense, the most important feature of a cross-chain bridge is to enable complete distrust. If cross-chain services can be constructed in a way of de-trust, and the source chain information can be directly obtained by the independent verification of light clients on the chain, it will greatly promote the further development of multi-chain ecology and the large-scale emergence of native multi-chain applications.

The emergence of ZKP technology and the cross-chain bridge constructed by ZKP technology will be the best scheme to implement the de-trust cross-chain.

2. Cross-chain de-trust based on ZKP

An excellent cross-chain protocol must be safe first, ecological richness second, low cost and fast cross-chain last. Therefore, an excellent cross-chain protocol should have the characteristics of high degree of distrust, high degree of decentralization, good scalability, fast cross-chain speed and low cost. This view is accepted by most people, and the author thinks there may be some problems with this view. If a cross-chain protocol is fully de-trusted, do you need to consider decentralization?

Many cross-chain projects now use a dedicated chain to implement cross-chain operations. This approach makes the cross-chain protocol more decentralized, but does not achieve de-trust. Decentralization is still a cross-chain sponsor who places its cross-chain security on a decentralized network. But cross-chain protocols should be about de-trust, not de-centralization, because once you de-trust cross-chain operations, there is no decentralization. Imagine that the ZKP generated by the successors can be easily verified by the users themselves. Is there any need to talk about decentralization?

In the process of cross-chain operation, trust source chain consensus and target chain consensus are the prerequisite for the existence of cross-chain operation. In addition, trusting any organization reduces the security of the asset. Cross-chain operations are best able to achieve de-trust, and de-trust is ultimately a no-trust assumption. To realize untrusted cross-chain, the best way is to use ZKP to build the underlying trust mechanism of cross-chain interoperation protocol and realize untrusted cross-chain.

A cross-chain bridge built based on ZKP generally involves three logical roles:

1. The producer of Proof, whose function is to observe the state of the original chain and use the original chain data to generate ZKP.

2. Relay, passing ZKP to the target chain.

3. On-chain light client, which is also the verifier, can independently complete the verification of ZKP.

The prover and the relay can be the same or different person, because it is the on-chain light client that decides whether to adopt ZKP. Therefore, this setup does not present any security concerns. Furthermore, in ZKP, an honest relay node is all that is needed to keep the protocol running.

All the existing ZK interoperability protocols basically revolve around Ethereum. Some implement the interoperability between Ethereum and other heterogeneous chains, while some aim to complete the interoperability between Ehtereum and its isomorphic chain. But no matter which chain Ehtereum interoperates with, you need to generate Ethereum consensus proofs and implement Ethereum Light client validation of that consensus proofs on other chains.

3. The zkRouter interoperates with other ZKS

The cross-chain protocol based on ZKP can perfectly implement the de-trust. The most typical protocol is zkRouter by Multichain.

1. How does the zkRouter implement cross-chain based on ZKP

Whether assets cross chains, messages cross chains, or cross-chain interoperation, they all 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 in a trustless way, it can support the true sense of native multichain, and it can achieve true multichain interoperation.

The zkRouter whitepaper describes passing Ethereum messages to Fantom, which involves the following steps:

First, a transaction occurs in the source chain (the transaction can be verified by the block head hash with the Merkle tree path);

The repeater submits the transaction to a light client on the target chain;

The on-chain light client validates the transaction.

The reader is left with two questions:

What is a light client versus an on-chain light client?

Where is ZKP represented in these steps, and what does ZKP do?

(1) Light client and on-chain light client

Since the LayerZero protocol was introduced, the concept of a light client seems to have been abused. There is a difference between an ultralight node in LayerZero and a light client in the normal sense. The LayerZero ultralight node simply verifies that the data passed by the repeater matches the data passed by the oracle, not directly verifies the on-chain transaction. In the general sense, the light client directly verifies the transaction on the chain. In essence, LayerZero still needs to trust that the repeater and the prophet will not cooperate to do evil, and does not implement the de-trust.

We'll start with how to verify an on-chain transaction and explore what a true light client and on-chain light client are.

What is a light client? Ethereum has a lot of transactions happening at the same time, and there have been a lot of transactions happening historically, and without a light client, a user would have to synchronize all the transaction data across all the blocks to validate the transaction, which is obviously not possible.

In the Bitcoin network, each block has a block header, which contains a pointer to the previous block and the Merkelroot of the hash of all transactions within the current blockchain. The pointer to the previous block ensures that the transaction data in the previous block is not tampered with, and the Merkle tree in each block contains all the transactions in the current block, and all the current transactions can be verified by the root hash value. See Figure 1. This ensures that all transaction information contained in the current and historical blocks is not tampered with. Ethereum inherits this verification approach. The block header of the Ethereum network also contains the Merkle root and a pointer to the previous block, which can be used to validate any type of data stored.

FIG. 1 Schematic diagram of Merkle tree structure of Bitcoin network

As shown in Figure 1, hash operations are performed on transactions L1, L2, L3 and L4 respectively to get Hsh0-0=hash(L1), Hash0-1=hash(L2), Hash1-0=hash(L3), Hash1-1=hash(L4).

To obtain the 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 unidirectional, that is, Y=Hash(X) can only be computed by X, but X cannot be computed by Y. Thus, the light client can verify the authenticity of the transaction by simply synchronizing the root hash value within the block and asking for the full node path hash data.

If a light client wants to validate L1 transactions. If a light client has a root hash value, it can verify the L1 transaction by applying the values of Hash1 and Hash0-1 to the full node.

1. Calculate Hash0-0;

2. Calculate Hash0=hash(hash0-0, hash0-1) based on Hash0-1 synchronized to all nodes and hash0-0 calculated in the previous step.

3. Calculate the root hash RootH=hash (Hash0, Hash1) based on the Hash1 synchronized by all nodes and the Hash0 calculated in the previous step, and compare the root hash RootH to the Top Hash synchronized by the light client. If they are the same, prove that the L1 transaction is indeed on the chain and has not been changed. This is how the entire blockchain enables a trusted light client.

The above procedure demonstrates how a light client can validate an on-chain transaction. So if the target chain can implement the source chain light client, that is, the chain light client, is it possible to achieve the verification of the source chain transaction in the target chain?

Imagine, in the specific application of cross-chain, the key difficulty is that the target chain cannot be trusted to verify the transaction of the source chain, but needs to be relayed through a third party, which virtually reduces the security of cross-chain. If a smart contract is used to implement a light client on another chain, the transaction of the source chain can be verified on the target chain, achieving a de-trusted cross-chain.

(2) Why does the on-chain light client need to use ZKP technology

The previous section showed that cross-chain is possible with light on-chain client verification of source chain transactions. So why use ZKP technology?

Light client verification involves a large number of calculations in the process of consensus generation. If these calculations are completed on the chain, high Gas costs are required, so it is not feasible to popularize. Zero-knowledge proof technology can transfer a large number of calculations in the process of consensus generation to the chain creditively, and then generate simple proof results, which can be verified with less Gas cost on the chain.

Whenever relaying is involved, users will feel centralized suspicion, not enough to distrust. However, the repeater in the ZKP-based cross-chain bridge is only responsible for relaying messages, not validating them, which is done by the light client of the target chain. The rigorous mathematical and cryptographic proof can ensure that the light client of the target chain can complete the verification and realize the de-trust.

(3) How does zkRouter implement cross-chain using ZKP technology

The cross-chain solution implemented by the zkRouter is explained in detail in its whitepaper, but there is currently no documentation available to interpret it. To understand the zkRouter, you need to add some background.

At present, several typical Turing complete proof algorithms have appeared in the application field of zero-knowledge proof, among which the most popular one is zkSnark (zero-knowledge succinct non-interactive arguments of knowledge, Zero-Knowledge concise non-interactive Knowledge Argument) and zk-Stark (zero-knowledge Scalable Transparent Argument of Knowledge, zero-knowledge Scalable Transparent argument of knowledge). The size of the ZKP file generated by zk-Stark is about 200KB, and that generated by zk-Snark is about 192B. The ZKP file generated by zk-Stark is too large. If zk-Stark is used for cross-chain implementation, the target chain consumes a lot of Gas. Therefore, it has no economic advantage in specific applications. ZKP generated by Zk-Snark, due to its advantages of non-interaction, fast generation of proof and short proof results, is widely used in blockchain. At present, most zk cross-chain Bridges in the market are Zk-Snark, or a variant of Zk-Snark technology. The zkRouter also uses zk-Snark.

The zkRouter protocol consists of four steps.

1. Initial Setup

For the target chain light client to complete 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 has continuity, that is, the current block consensus result is an update based on the consensus result of the previous block. Therefore, the target chain light client must first obtain the current consensus state of the source chain before verifying the correctness of the subsequent block consensus.

Light clients of the target chain need initial initial_data at first, which includes the initial block height, block header hash, etc. This initial setting only needs to be set once and is automatically updated as cross-chain activity occurs.

2. Proof Gen Generation

This step occurs in specific cross-chain behavior. When the source chain generates a new block, the target chain needs to synchronize the new information, including the state of the previous block, the selection of the outgoing block node, the legitimacy of the signature node, etc. For the non-immediate finality consensus mechanism, a certain number of redundant blocks should be set to avoid the loss caused by bifurcation. The repeater then computes the ZKP down chain through the ZKP down chain technique and synchronizes it to the target chain.

3. ProofVerify

Once the succinct ZKP has been submitted to the target chain by the repeater, the ZKP needs to be validated. This is done by the light clients 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. Interoperable contract Call

When the target chain light client passes the verification of the source chain consensus (including the source chain transaction), the participant can initiate the cross-chain contract interoperability call and complete the cross-chain interaction.

For example, for cross-chain Swap, any participant submits the TXS and Merkle tree proof path of the corresponding source chain transaction. According to the existing source chain consensus information of the light client, the contract can easily verify the authenticity of the transaction.

There's also a fair bit of Ethereum in the Multichain white paper. Fantom ZK cross-chain implementation of the description, the steps are similar to the above process, will not be repeated here.

2. Other major ZK cross-chain solutions

Many teams are currently working on the development of ZK cross-chain Bridges. Because the generation of ZKP is closely related to the source chain consensus, and the way the consensus is reached and the signature algorithm used is different from one chain to another, the method used by the project to implement the light client on the different chain will be different in practice, but the core algorithm is basically similar to that of the zkRouter.

(1) Electronic LABS

Electronlabs implements a bidirectional cross-chain bridge from Ethereum test net to Near test net, which shows that Electronlabs not only implements Ethereum light client on Near, A light client for Near has also been implemented on the Ethereum network. Cosmos support 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 (verifier signatures). Therefore, a concise verification of a batch of Ed25519 signatures is required.] Signature algorithm, which Ethereum does not support. As a result, some extra work is required to validate Ethereum's Ed25519 signature on the chain.

In addition, Ed25519 algorithm does not support aggregation signature, so Eletronlabs uses recursive way to achieve a large number of Ed25519 algorithm verification. Verifying signatures generates large circuits, so the key issue 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 proof that zk-Snark generates the validity of the signature down the chain, and verifies that proof only on the Ethereum chain.

According to the current achievements of Electronlabs, there are some advances in heterogeneous chain deployment, including the Cosmos public chain signature algorithm Ed25519. In the future, Electronlabs should be able to expand the public chain of Ed25519 signature algorithm.

(2) Succinct

Succinct similarly launched only the one-way ZK cross-chain bridge inside, except that it ran Goerli-> Gnosis, Optimism, Polygon, Avalanch and others test the ZK bridge across the chain of networks. The source chain has only one chain, Goerli.

The most complex part of ZK cross-chain is setting up the circuit according to the source chain consensus, and the development of the target chain client is not much. So the Succinct went live. Gnosis, Optimism, Polygon, Avalanch and others have tested the ZK bridge with the same progress as the one with only one one-way bridge. Succark also used the zk-Snark scheme, and its basic scheme was not very different from the common one; it will not be detailed here.

Succinct's main goal was to expand around the Ethereum layer 2 network around it. Gnosis, Optimism, Polygon, Avalanch-> Gnosis, optimism, Polygon, Avalanch-& GT; Goerli's cross-chain is more imaginative. However, given that the generation of source chain ZKP required a large number of circuit Settings, consensus varied greatly. This part of the work was the most time-consuming part of ZK cross-chain implementation, Succinct, which has not been completed yet.

(3) nil.foundation

Nil realized the verification of the state of the Ethereum test net and Polygon test net on the Ethereum test net and Polygon test net, but did not realize the verification of the state of the Ethereum test net and Polygon test net on the Mina test net, so in terms of schedule, Nil is in the same echelon as other ZK cross-chain projects.

But the nil.foundation project, with funding from ZK track heads Starkware and Mina, shows its technical prowess. In addition, Nil open-source the zkLLVM product, which is positioned to help developers compile ZKP in a high-level language, significantly lowering the barrier to entry for developers. With this tool, developers can focus on circuit design using a language they are familiar with, rather than getting stuck in a domain-specific language -DSL learning cycle. Compiling zero-knowledge circuits often requires domain-specific languages and toolkits and takes a lot of time.

(4) Herodotus

Herodotus' official description uses the "MPC+ Light client +ZKP" cross-chain bridge implementation, which uses an optimistic MPC approach to challenge messages relayed by Repeaters. But since any repeater can relay the generated ZKP to the target chain, verification is done by a light client on the target chain. If you still need a trusted MPC network, adding ZKP is of little significance. Of course, its test network has not been launched yet, and the specific scheme has yet to be announced by the project side.

(5) Polyhedra

Polyhedra is currently the most online test network of the cross-chain bridge, including Goerli, BNB Chain Testnet, Polygon Testnet, Fantom Testnet, Avalanche Testnet. Polyhedra's current offering is NFT transchain, which allows users to generate transchain NFT through Polyhedra, which can then be transchain using its NFT transchain bridge. Polyhedra has received $10 million in funding from Binance Labs, Polychain Capital and others.

However, after analysis and testing, we found that the project test network did not use ZKP, and the light client did not verify the Merkle tree, as follows.

Test transaction source link 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

Final call to verify 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 validation returns true directly. There is no ZK technique that is not used, and the hash header is not validated, which defaults to the correctness of the cross-chain message. From the test network contract, we can not see its progress, of course, we will continue to monitor the test network.

Iv. Development prospect of cross-chain projects based on ZKP

At present, ZK cross-chain has become a hot topic in the industry, and there are many related solutions. The future competition is likely to revolve around the following aspects.

1. Contract security. While many ZK cross-chain solutions strive to de-trust, ZKP provides only the underlying technical architecture. The underlying technical architecture is solid, but it's hard to avoid the security issues that can arise when smart contracts are written and run.

2. Multi-chain bidirectional deployment. Progress in this direction is not clear at present, and none of these cases have achieved multi-chain bidirectional deployment. It will be a great competitive advantage if the cross-chain bridge can realize multi-chain bidirectional deployment first.

3. Is it a ZK cross-chain bridge to be untrusted? From the above discussion, readers can find that the most important advantage of ZK cross-chain bridge is that it can realize the cross-chain to be untrusted. If the cross-chain to be untrusted cannot be realized, then ZKP application in the cross-chain field is of little significance.

V. Summary

We compared several well-known projects within ZK cross-chain track from the aspects of test network progress, Non-EVM support, product reliability, team technical ability, whether to trust, as shown in Table 2.

Table 2 Comparison of several major zk cross-chain track projects at present

As can be seen from Table 2, currently several major zk cross-chain projects are basically in the initial stage, and the technical schemes are roughly the same. However, the complete distrust of ZKP in theory makes the realization of cross-chain based on ZKP distrust in the future, and thus has a more important significance to promote the development of multi-chain ecology, multi-chain universe and primary multi-chain applications.

According to Multichain's published roadmap, it has had two solutions since the inception of Anyswap, an MPC-based cross-chain solution and a ZKP based solution. As for the zkRouter developed by Multichain, I think there are several values to be expected:

1. Deep cross-chain technology background. Multichain has been deeply engaged in cross-chain business for many years and has a deep technical background. Based on this, we can expect the zkRouter of Multichain to make greater progress on the track of ZK cross-chain. After testing the zkRoutr online, users can also get a hands-on experience with the zkRouter. Of course, as a product of POC stage, it is still difficult for ordinary users to obtain direct trust experience from the use, including the possible cross-chain speed and cross-chain cost of zkRouter in the future. These contents still need to be studied and judged by more experts from a more professional level and perspective.

2. Huge ecological partner. Multichain has deep cooperation with thousands of multi-chain projects, an advantage that other cross-chain protocols do not have. Therefore, once zkRouter enters the practical stage, it is entirely possible for zkRouter to become a strong cross-chain competitor in the next generation by virtue of the huge ecosystem of Multichain.

Original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia