IOSG: ZK cross-chain communication protocol - building the future of full-chain DApps securely and cost-effectively.

Original Title: "IOSG Weekly Brief | ZK Cross-Chain Communication Protocol: Building the Future of Secure and Low-Cost Full-Chain DApps"

Original Author: Yiping, IOSG Ventures

TL;DR

ZK provides a secure and cost-effective way for cross-chain communication.

The cross-chain communication protocol is still in its early stages, but it is expected to allow DApps to access data on different chains.

DeFi, the entire chain DApp will benefit from the development of cross-chain DApp.

The impact of cross-chain DApps is expected to be very significant in the next few years, just like the impact of globalization.

Developers are working hard to explore the best mode for building cross-chain DApps.

Delay, security, and cost are the main indicators of the ZK cross-chain information protocol.

ZK cross-chain protocol has four main components: generating and storing proofs, combining storage proofs and ZKP, relaying ZKP, and expanding commitments.

At the end of the article, an AI trained by this article is also provided, and you can ask any questions related to this article.

Foreword

Before, there were only Ethereum and Bitcoin. They had the most liquidity, users, applications, and transactions. After 2020, many new blockchains emerged, such as Avalanche, Polygon, and BSC.

After the launch of these mainnets, we have seen a paradigm shift from Ethereum and Bitcoin to ALT Chains. Users have moved from Ethereum to ALT Chains to find new opportunities. Developers have moved from Ethereum to ALT Chains to fork existing projects. These developers have created new opportunities for users seeking high returns.

Ethereum used to have all the liquidity in the cryptocurrency world except for Bitcoin. By the end of 2020, Ethereum's TVL ratio had dropped sharply to around 60%. Below are the TVL data for 165 chains.

Today, the TVL pie charts of various chains look like this. Ethereum occupies the majority of liquidity. Tron and BSC occupy the second and third positions.

After dispersing assets and liquidity across different chains, users begin to consider how to manage and move assets across different chains. Asset issuers also consider how to expand their user base by extending to different chains.

The cross-chain asset bridge will become popular in 2022. Users will no longer use CEX as a cross-chain bridge, but will try to turn to decentralized cross-chain bridges. Asset cross-chain bridges may sometimes get stuck and are vulnerable to attacks, but they are easier to use and transfer large amounts of funds.

However, asset cross-chain bridges are still in the early stages and cannot meet the needs of DApp developers. Asset cross-chain bridges can only allow the same assets to flow between different networks. This is too limited for developers. Developers are looking for a more universal cross-chain solution.

Cross-chain communication has strong customizability. Developers can develop full-chain DApps based on cross-chain communication. DApp builders hope to pass messages between different chains and obtain necessary block information. With these features, the construction paradigm of full-chain DApps has shifted from non-communication and independent models to distributed design. In the non-communication and independent model, Dapp instances on different chains cannot share data with each other. In distributed design, Dapp instances can communicate with each other and can regularly synchronize data to an instance. This instance obtains all data and can modify parameters on other instances.

With the help of cross-chain communication driven by ZK, because ZKP can provide concise proofs, it can consume less storage and relay the source chain state to the target chain. In addition, verifying SNARK proofs on the target chain is relatively cheap. These two important features of ZKP can achieve low-cost cross-chain messaging and state transfer. Verifying the source chain state on the target chain can achieve IBC-style cross-chain bridging, greatly increasing the security of cross-chain transactions.

Current

Most blockchain networks are isolated from each other and cannot directly exchange assets or tokens. Cross-chain asset bridges allow users to transfer assets or tokens between different blockchain networks.

With the launch of projects such as Wormhole, cbridge, and Stargate, the concept of cross-chain asset bridges has gained attention in recent years. These projects aim to create interoperable blockchain bridges, allowing users to seamlessly exchange assets and tokens.

The cross-chain asset bridge cannot meet the needs of developers. Developers are looking for a more universal cross-chain method, namely cross-chain messaging protocol. In order to meet the needs of developers, most of these cross-chain bridges have their own cross-chain messaging protocols, such as Celer IM, LayerZero, Multichain's anyCall, and Connext's xcall. They provide APIs similar to this.

The cross-chain message communication protocol is based on its cross-chain asset protocol. Through some modifications, these cross-chain asset protocols can now pass messages between chains. This makes it difficult to customize functions for the cross-chain message protocol implementation, as the overall design needs to be compatible with cross-chain asset transfers. They lack some key features for building cross-chain applications, such as broadcasting messages from one chain to all other deployed contracts on different chains. This makes it difficult for developers to build practical full-chain DApps.

The cross-chain messaging communication protocol is still in its early stages. No large-scale full-chain DApp is fully built on these cross-chain communication protocols.

Why do we need ZK?

Although these cross-chain bridges have brought a lot of convenience, such as improving capital utilization and enhancing user experience, they have also brought security risks. Attacks on cross-chain bridges have caused huge economic losses to users. This makes security a top priority in the development of cross-chain bridges. These attacks have caused users to lose more than $1.5 billion.

Within a year, the total loss of cross-chain bridges in hacking incidents was approximately $1.3 billion. The transaction fee for using cross-chain bridges is around 5. Multichain is a leading project in cross-chain bridges. Multichain's 30-day trading volume is $1.7 billion, with a fee income of $635,000. Therefore, the annual trading volume is about $20.4 billion, with a fee income of $7.6 million. Based on this estimation, the total fee revenue of the cross-chain bridge market is far less than the funds stolen by hackers.

By verifying the source chain block header, the ZKP cross-chain messaging protocol can alleviate some security issues. Users can directly access the source chain proof on the target chain and verify it themselves. Without ZKP, this would be difficult to achieve. In traditional projects, the cost of such verification is too high for users to bear.

Design

In this section, we will discuss how ZKP achieves low-cost and secure cross-chain information communication.

The idea of using ZKP to relay messages is intuitive, but the detailed design may be complex. The entire workflow can be broken down into the following steps:

Deciding which data to transmit to the target chain.

Get storage proof (proof that data exists in EVM storage)

Generate ZK proof based on storage proof

Transfer the ZK proof from the source chain to the target chain.

Expand ZK proof on target chain.

Read cross-chain information in the target chain.

Most EVM-compatible chains provide this feature. Once the user has identified the storage slot, they can use RPC to call this method to generate a storage proof.

EVM compatible chains use Merkle Trees to store accounts and data. This makes it relatively easy to create Merkle Proofs to verify this data.

Merkle Tree is a data structure used in computer science, which is widely used in cryptography and blockchain. It is named after its inventor, Ralph Merkle, and is also known as a binary hash tree. The basic idea behind Merkle Tree is to divide a large amount of data into smaller parts, hash each part, and then combine the hash values to form a single root hash value. This root hash serves as a fingerprint of the entire dataset, allowing for efficient and secure verification of data integrity.

In blockchain, Merkle Tree is used to summarize and verify transactions in a block. Each transaction is hashed and added to the tree, and the hash values are combined in a specific way to form a single root hash value, which is then added to the block header. This allows for efficient and secure validation of a large number of transactions in a block without individually verifying each transaction. If any data in the transactions is changed, the root hash will also change, indicating that the data has been tampered with.

Merkle Proof, also known as Merkle Path, is a cryptographic proof that demonstrates specific data is contained within a Merkle Tree. Merkle Tree Proof provides a method for verifying the authenticity of transactions or other data without the need to download and verify the entire Merkle Tree.

In Merkle proof, users provide a series of hashes from the bottom to the root hash of the Merkle tree, as well as the specific data to be verified. By starting from a specific data and going up the tree, the receiver can calculate the root hash and compare it with the root hash stored in the block header. If the calculated root hash value matches the stored root hash value, the receiver can be sure that the specific data is included in the block and has not been changed.

Merkle Proof is an important component in ensuring the efficiency and scalability of blockchain networks. By allowing specific data to be verified without the need to download and verify the entire Merkle Tree, Merkle Proof reduces the amount of data that needs to be transmitted and processed, thereby improving the overall performance of the network.

Combining Storage Proofs and ZKP

It is impractical to publish the entire storage proof on the target chain because it is too large, approximately 4kb. It is also expensive to verify the proof. Verifying it on Ethereum requires 600k gas. If the gas price is 30 gwei, the total cost would be 0.018 ETH (30 USD).

In this case, ZKP can provide compression and composability. Developers can create ZKP based on Merkle Tree Proof. This can greatly reduce the size of the proof and make it easier to verify. Verifying Plonk requires approximately 290k gas. If the gas price is 30 gwei, the total cost is 0.009 ETH (15 USD). One Groth16 verification uses approximately 210k gas. If the gas price is 30 gwei, the total cost is 0.006 ETH (10 USD).

With composability, developers can even combine different storage proofs into one ZKP to save resources.

中继 ZKP

translates to

Relay ZKP

.To securely transfer related commitments, such as state roots or related ZKP, to the target chain, we need to design a consensus mechanism.

There are three common ways to relay ZKP:

Message delivery: Use some message delivery protocols to transmit ZKP and obtain relevant commitments through OP CODE.

Consensus Verification: Verify relevant commitments by running consensus algorithms.

Optimistic MPC relayer: Similar to what we have seen in many cross-chain asset bridges and OPRU designs, there is a committee between the initial chain and the target chain. The participants of the committee determine the validity of the relay commitment. Anyone can challenge the validity, but when a challenge occurs, the bridge cannot roll back like Rollup. A separate group of challengers is needed to truly prevent the spread of malicious messages. In this context, the cost and delay of challenges are high because it involves constantly uploading the root hash and all CALL DATA to the initial chain. And it can only work in a peer-to-peer manner.

The most important factors for ZKP in relay are:

DelayCost

TrustOff-chain computing.

The delay of message transmission is quite high because it takes time for the message to be confirmed. After the block is generated, users can confirm the successful transmission. In terms of cost, message transmission requires interaction with two chains, so it is relatively high. This method requires less trust because the security is equivalent to the security of the chain. This method does not involve any off-chain computation.

Consensus verification is a feasible method. It has similar delays, trust assumptions, and costs as information transmission. However, it must verify signatures off-chain. This introduces a lot of off-chain computation overhead. But consensus verification can also be achieved through ZKP today.

Optimistic MPC relayers sacrifice some trust but gain lower latency. Users only need to submit transactions to the relayer network. The specific latency depends on the specific optimistic MPC relayer mechanism. The challenge period may result in greater latency. Users need to have minimal trust in the relay network. This approach does not involve a large amount of off-chain computation, but requires communication and fraud proofing within the relay network.

展开承诺

translates to

Expand Commitment

After receiving the commitment, users on the target chain can unfold the commitment and access the past state of the initial chain.

Three common ways of expansion are:

On-chain accumulation.On-chain compression.

Off-chain compression

On-chain accumulation is a method of fulfilling commitments in a blockchain network. In this method, the entire process of recreating the block header from the commitment is executed directly on the blockchain. The correctly encoded block header is executed as CALL DATA in a transaction by the blockchain. The advantage of this method is that there is no additional overhead in proof time. Additionally, the delay is low because the proof does not need to be verified outside the blockchain. However, the disadvantage is that the cost may be high because the computation may consume a lot of resources.

On-chain compression is a method of reducing the amount of data that needs to be stored on the blockchain. It is used to minimize the cost of storing large amounts of data on the blockchain. The idea behind on-chain compression is to use compression algorithms to reduce the size of the data, thereby reducing the space it occupies on the blockchain. This can be achieved by removing redundant or unnecessary information from the data, or by using data structures optimized for space efficiency. The compressed data is then stored on the blockchain and can be decompressed when needed.

On-chain compression has the advantages of reducing storage costs and improving blockchain scalability. However, it also has some drawbacks. For example, the process of compressing and decompressing data can be computationally expensive, which can increase the latency of the blockchain. In addition, the compression algorithm used may have a negative impact on the security of the data, as it may be vulnerable to tampering or attacks.

Off-chain compression is similar to on-chain compression.

Here is a comparison table for these three methods:

Related Projects

Many ZK bridge projects hope to improve interoperability between different chains and reduce potential hacker risks.

There are many projects in this field, such as:

Succinct Labs

Lagrange

zkBridge

Herodotous

=nil; Foundation

Succinct Labs uses a lightweight client approach. It uses a lightweight client to verify the consensus of the starting chain at the consensus layer of the target chain. ZKP is used to generate consensus proofs.

Lagrange Labs has built a non-interactive cross-chain state proof. The Lagrange Attestation Network is responsible for creating the state root. Each Lagrange Node contains a portion of the shard private key, which is used to prove the state of a specific chain. Each state root is a Verkle Root of a threshold signature, which can be used to prove the state of a specific chain at a specific time. The state root is fully universal and can be used in state proofs to prove the current state of any contract or wallet in the chain.

Herodotus uses ZKP's storage proof to provide access to on-chain data from Ethereum for smart contracts. It has an MPC Optimistic Relayer to relay promises. It uses off-chain compression to expand the blockchain header of the relay and create a proof.

zkBridge uses MPC relay network to generate ZKP block headers and relay them to the target chain. It uses deVrigo and recursive proof to achieve very fast proof time, but the MPC part has high complexity.

The first user initiates a cross-chain message request. The sender in the initial chain then forwards the block header to the relay network. Validators in the relay network generate proof of the block header and pass it on to the update contract. After verifying the proof, the update contract accepts it and forwards it to the recipient, who then forwards it to the application and user in the target chain.

=nil; Foundation is also committed to ZK cross-chain messaging protocol. It enables developers to access Mina's state on Ethereum. They launched a demo at the end of 2021 that verifies Mina's state on Ethereum. This infrastructure allows smart contracts on Ethereum to verify the validity of Mina's state. With this infrastructure, smart contracts are able to identify invalid cross-chain transactions.

Mina has its own state proofs, but the cost of verifying them on Ethereum is high. The =nil; Foundation uses its own Placeholder proof system to generate auxiliary state proofs, which are cheap to verify on Ethereum. This infrastructure enables Ethereum smart contracts to fully verify Mina state proofs on-chain. In the future, cross-chain applications can directly use this infrastructure to verify the legitimacy of cross-chain transactions.

A cross-chain bridge for assets based on this will include the following steps:

Cross-chain bridges lock $Mina on Mina.This infrastructure generates Mina state proofs.This infrastructure submits Mina state proofs to Ethereum.The validity of contract verification status proof on the Ethereum blockchain.On the Ethereum blockchain, contracts receive and store Mina state proofs. If the proof is valid.

The cross-chain bridge verifies Mina and transaction status on the Ethereum chain, releasing $WMINA.

Later =nil; Foundation is working hard to solve the unidirectional problem. In the previous demo, only unidirectional cross-chain communication was supported. Now they theoretically support bidirectional bridging. The state proof on the initial chain will be generated in the Placeholder proof system and then generated again in the Kimichi proof system to obtain a proof. The proof will then be submitted to the Mina validator. The validator will consider the initial chain state proof as a proof generated by Mina's native zkApp.

=nil; Foundation also released Proof Market. Users/project parties can buy/sell most SNARK proofs in it. Currently, there are two trading pairs, ARITHMETIC-EXAMPLE and MINA-STATE.

Here is a detailed comparison of these projects:

Application Scenarios

With the help of the ZK-based cross-chain message relay protocol, developers can easily extend their applications to different blockchains.

In the past, contract deployment was mainly focused on a single chain. When expanding to another chain, the application had to be redeployed. With the use of ZK-based cross-chain message relay protocols, a paradigm shift from single-chain applications to cross-chain applications will be achieved. Large-scale projects can easily expand to different chains, resulting in effects similar to globalization. We hope to see more international companies or large cross-chain DApps.

Low-latency/real-time and low-cost cross-chain messaging protocols will open up a market with multiple possibilities. DeFi, DID, governance, and development will benefit from it.

DeFi

DeFi can benefit greatly from it. Cross-chain message relay protocols can help DeFi products integrate liquidity from different chains.

DEX, cross-chain trading, and aggregators can provide better user experience, lower slippage, and higher trading pair liquidity. The same trading pair on different chains will have a unified liquidity pool. Price differences between different chain DEXs will be smaller. DEXs can obviously gather more liquidity and provide a user experience comparable to CEXs.

Farming can have more flexible strategies. They can now search for more profit opportunities on different chains.

The lending agreement can collaborate with more DeFi protocols on different chains and accept deposits of different Tokens on different chains.

On-chain derivatives will benefit greatly in terms of liquidity. Through secure cross-chain communication, the derivatives market can reach potential customers on different chains and gather more liquidity. This can provide a better trading experience.

The fund management application can access more assets from different chains. They can also access derivatives from different chains. This allows financial managers to use more investment strategies.

Application Chain

Application chains or custom Rollups provide more freedom for Dapps. Dapp developers can customize application chains to meet their own needs, such as performance or some technical features. Dapp developers can also customize the fee structure to incentivize users. There are many application chains on Cosmos because Cosmos has better interoperability. The cross-chain protocol supported by ZK will be a better tool for connecting non-Cosmos application chains with the EVM or layer2 ecosystem. Many Rollup SDKs under development can benefit from the cross-chain protocol supported by ZK.

The Cosmos ecosystem is leading all major ecosystems on the APP chain. Cosmos has made good progress in cross-application chain sharing security. ZKP may promote the expansion of the Cosmos ecosystem. Composable finance is working to expand Cosmos to Polkadot and NEAR. Electron Labs and zkBridge are bringing Cosmos to Ethereum.

Utilizing the characteristics of different chains

No blockchain is perfect. They optimize for one purpose at the cost of sacrificing other functionalities. With cross-chain messaging protocols, developers can leverage the advantages of each blockchain and avoid their shortcomings.

DApp developers can deploy their DApp components in different chains. For example, some chains may be a good choice for computation due to low computational costs. Some chains may have optimized for privacy, which will serve as the privacy feature of the DApp. Some chains can host files, while others are suitable for providing front-end services. Cross-chain messaging protocols can glue these components together and allow developers to fully utilize each blockchain.

Summary

ZKP provides a new way for cross-chain communication. Although it cannot completely solve the security issues of traditional cross-chain bridges, with the power of ZKP, secure cross-chain message communication now greatly reduces costs. The size of the proof is much smaller than before. The on-chain verification cost has also been greatly reduced. It is possible to verify the source chain state on the target chain, which can achieve shared security similar to IBC. This was impossible to achieve at low cost in the past.

The ZK cross-chain communication protocol enables different chain protocols to communicate with each other. Developers can develop full-chain DApps based on the ZK cross-chain protocol. DeFi and application chains will benefit from it.

The cross-chain communication protocol is still in its infancy. Developers are working hard to develop these protocols, and issues such as how to synchronize states in real time between different chains have not yet been resolved. Debugging cross-chain DApps can also be painful. Developers are exploring the best mode of building cross-chain DApps, and we will see the impact of cross-chain DApps in the coming years. As a cross-chain communication protocol that connects different blockchains, it will be as influential as globalization.

Original article 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