ZK Cross-Chain Communication Protocol: The Future of Secure and Low-Cost Full-Chain DApps

Author: Yiping, IOSG Ventures

TL;DR

• ZK provides a secure and low-cost way for cross-chain communication.
• Cross-chain communication protocols are still in their early stages but are expected to allow DApps to access data across different chains.
• DeFi and full-chain DApps will benefit from the development of cross-chain DApps.
• The impact of cross-chain DApps is expected to be significant in the coming years, similar to the effects of globalization.
• Developers are working hard to explore the best models for building cross-chain DApps.
• Latency, security, and cost are the main metrics for ZK cross-chain information protocols.
• The four main components of ZK cross-chain protocols are: generating storage proofs, combining storage proofs and ZKP, relaying ZKP, and unfolding commitments.

Introduction

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

After the mainnet launch of these chains, we saw a paradigm shift from Ethereum and Bitcoin to ALT Chains. Users moved from Ethereum to ALT Chains in search of new opportunities. Developers migrated from Ethereum to ALT Chains to fork existing projects. These developers created new opportunities for users seeking high returns.

Ethereum once held all the liquidity in the cryptocurrency world, except for Bitcoin. By the end of 2020, Ethereum's TVL share sharply dropped to around 60%. Here is the TVL data for 165 chains.

Today, the TVL pie chart of major chains looks like this. Ethereum occupies the majority of liquidity, while Tron and BSC take the second and third positions.

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

Cross-chain asset bridges became popular in 2022. Users no longer used CEX as cross-chain bridges but began to turn to decentralized cross-chain bridges. Asset cross-chain bridges sometimes get stuck and are vulnerable to attacks, but they are easier to use and can transfer large amounts of funds.

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

Cross-chain communication offers strong customization. Developers can fully develop full-chain DApps based on cross-chain communication. DApp builders want to pass messages and obtain necessary block information across different chains. With these features, the construction paradigm of full-chain DApps shifts from non-communication to a distributed design. In a non-communicating, mutually independent model, DApp instances on different chains cannot share data with each other. In a distributed design, DApp instances can communicate with each other and can periodically synchronize data to one instance. This instance collects all data and can modify parameters on other instances.

With ZK-driven cross-chain communication, ZKP can provide concise proofs that consume less storage, relaying the source chain state to the target chain. Additionally, verifying SNARK proofs on the target chain is relatively cheap. These two important features of ZKP enable low-cost cross-chain message and state transmission. Verifying the source chain state on the target chain can achieve IBC-style cross-chain bridging, significantly enhancing cross-chain security.

Current Situation

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 like 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 that allow users to seamlessly exchange assets and tokens.

Cross-chain asset bridges cannot meet the needs of developers. Developers are looking for a more general cross-chain approach, namely cross-chain messaging protocols. To meet developers' needs, 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 like this:

Cross-chain messaging communication protocols are implemented based on their cross-chain asset protocols. With some modifications, these cross-chain asset protocols can now transmit messages between chains. This makes it difficult for them to implement customized features for cross-chain messaging protocols, as the overall design needs to be compatible with cross-chain asset transfers. They lack some key functionalities for building cross-chain applications, such as broadcasting messages from one chain to all other deployed contracts on different chains. This makes it challenging for developers to build practical full-chain DApps.

Cross-chain messaging communication protocols are still in their early stages. No large full-chain DApp has been fully built on these cross-chain communication protocols.

Why ZK?

Although these cross-chain bridges bring many conveniences, such as improved capital utilization and enhanced user experience, they also introduce security risks. Attacks on cross-chain bridges have caused significant economic losses to users. This has made security a top priority in the development of cross-chain bridges. These attacks have resulted in user losses exceeding $1.5 billion.

In one year, the total losses from hacking incidents involving cross-chain bridges amounted to approximately $1.3 billion. The usage fees for cross-chain bridges are around 5‱. Multichain is the leading project among cross-chain bridges. Multichain's 30-day trading volume is $1.7B, with fee revenue of $635K. Therefore, the annual trading volume is approximately $20.4 billion, with fee revenue of $7.6 million. Based on this estimate, the total fee revenue from 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 mitigate some security issues. Users can directly access the source chain proof on the target chain and verify the proof 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, secure cross-chain information communication.

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

• Decide which data to pass to the target chain
• Obtain storage proofs (to prove data exists in EVM storage)
• Generate ZK proofs based on the storage proofs
• Relay the ZK proofs from the source chain to the target chain
• Unfold the ZK proofs on the target chain
• Read cross-chain information on the target chain
• Generate storage proofs

Most EVM-compatible chains provide this functionality. Once users clarify the storage slots, they can use RPC to call this method to generate storage proofs.

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

Merkle Tree is a data structure used in computer science, particularly 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 Trees is to break 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 for the entire dataset, allowing for efficient and secure verification of data integrity.

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

Merkle Proofs, also known as Merkle paths, are cryptographic proofs that demonstrate that specific data is included in a Merkle Tree. Merkle Tree proofs provide a way to verify the authenticity of transactions or other data without needing to download and verify the entire Merkle Tree.

In a Merkle Proof, the user provides a series of hashes from the bottom of the Merkle Tree to the root hash, along with the specific data to be verified. By starting from the specific data and moving up the tree, the recipient can compute the root hash and compare it with the root hash stored in the block header. If the computed root hash matches the stored root hash, the recipient can be confident that the specific data is included in the block and has not been altered.

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

Combining Storage Proofs and ZKP

Publishing the entire storage proof to the target chain is impractical because it is too large, around 4kb. Verifying the proof is also expensive. Verification on Ethereum requires 600k gas. If the gas price is 30 gwei, the total cost is 0.018 ETH ($30).

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

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

Relaying ZKP

To securely relay relevant 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:

Messaging: Using some messaging protocol to relay ZKP and obtain relevant commitments through OP CODE.

Consensus Verification: Verifying relevant commitments by running a consensus algorithm.

Optimistic MPC relayer: This approach is somewhat similar to what we see in many cross-chain asset bridges and OPRU designs. There is a committee between the initial chain and the target chain. Participants in the committee decide the validity of the relayed commitments. Anyone can challenge the validity. However, when a challenge occurs, the bridge cannot roll back like a Rollup. A separate set of challengers is needed to genuinely prevent the transmission of malicious messages. In this context, the cost of challenges is high, and latency is also high because it involves continuously uploading the root hash and all CALL DATA to the initial chain. It can only work in a peer-to-peer manner.

The most important factors for relaying ZKP are:

• Latency
• Cost
• Trust
• Off-chain computation

The latency of messaging is relatively high because it takes time to confirm the messages. Users can only confirm the successful transmission after a block is generated. In terms of cost, messaging requires interaction with both chains, making it relatively high. This method requires less trust, as security is equivalent to the security of the chains. No off-chain computation is performed.

Consensus verification is a viable method. It has similar latency, trust assumptions, and costs as messaging. However, it must verify signatures off-chain. This introduces a significant overhead of off-chain computation. But consensus verification can also be done today using ZKP.

Optimistic MPC relayer sacrifices some trust but gains lower latency. Users only need to publish transactions to the relayer network. The specific latency depends on the specific optimistic MPC relayer mechanism. The challenge period may lead to greater latency. Users need to have minimal trust in the relayer network. This method does not involve a large amount of off-chain computation but requires communication and fraud proofs within the relayer network.

Unfolding Commitments

Once commitments are obtained, users on the target chain can unfold the commitments to access the past state of the initial chain.

Three common unfolding methods are:

• On-chain accumulation
• On-chain compression
• Off-chain compression

On-chain accumulation is a method of unfolding commitments within a blockchain network. In this method, the entire process of recreating the block header from the commitments is executed directly on the blockchain. The correctly encoded block header is included as CALL DATA in the transaction, and the blockchain performs the computation. The advantage of this method is that there is no additional overhead in proof time. The latency is low because the proof does not need to be verified outside the blockchain. However, the downside is that the cost may be high, as the computation can be resource-intensive.

On-chain compression is a method to reduce 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 decreasing the space it occupies on the blockchain. This can be achieved by removing redundant or unnecessary information from the data or 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 advantage 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 latency on the blockchain. Additionally, the compression algorithms used may negatively impact the security of the data, as they may be susceptible to tampering or attacks.

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

Here is a comparison table of these three methods:

Related Projects

Many ZK bridge projects aim to enhance interoperability between different chains and reduce potential hacking risks.

There are many projects in this field, such as:

• Succinct Labs
• Lagrange
• zkBridge
• Herodotous
• =nil; Foundation

Succinct Labs uses a light client approach. It verifies the consensus of the initial chain's consensus layer on the target chain using a light client. ZKP is used to generate consensus proofs.

Lagrange Labs builds non-interactive cross-chain state proofs. The Lagrange Attestation Network is responsible for creating state roots. Each Lagrange Node contains a portion of the shard private key used to prove the state of a specific chain. Each state root is a threshold-signed Verkle Root that can be used to prove the state of any contract or wallet in the chain at a specific time.

Herodotus uses ZKP storage proofs to provide smart contracts access to on-chain data from Ethereum. It has an MPC Optimistic Relayer to relay commitments. It employs off-chain compression to unfold the relayed blockchain headers and create proofs.

zkBridge uses an MPC relayer network to generate ZKP of block headers and relay them to the target chain. It uses deVrigo and recursive proofs to achieve very fast proof times, but the MPC part has higher complexity.

The first user initiates a cross-chain message request. The sender in the initial chain then forwards the block header to the relayer network. Validators in the relayer network generate proofs of the block header and pass them to the updating contract. After the updating contract verifies the proof, it accepts the proof. The updating contract forwards the proof to the receiver, who then passes it to the application and users on the target chain.

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

Mina has its own state proofs, but verifying them on Ethereum is costly. =nil; Foundation uses its own Placeholder proof system to generate auxiliary state proofs that are cheap to verify on Ethereum. This infrastructure enables Ethereum smart contracts to fully verify Mina's state proofs on-chain. Future cross-chain applications can directly use this infrastructure to validate the legitimacy of cross-chain transactions.

An asset cross-chain bridge based on this would include the following steps:

• The cross-chain bridge locks $Mina on Mina.
• This infrastructure generates Mina state proofs.
• This infrastructure submits the Mina state proofs to Ethereum.
• The contract on the Ethereum chain verifies the validity of the state proofs.
• The contract on the Ethereum chain receives and stores the Mina state proofs if the proof is valid.
• The cross-chain bridge checks the Mina and transaction state on the Ethereum chain and releases $WMINA.

Later, =nil; Foundation is working to address the unidirectionality issue. The previous demo only supported unidirectional cross-chain communication. Now they theoretically support bidirectional bridging. The state proofs on the initial chain will be generated in the Placeholder proof system and then again generate a proof using the Kimichi proof system. The proof will then be submitted to Mina validators. The validators will treat the initial chain state proof as a proof generated by Mina's native zkApp.

=nil; Foundation has also launched Proof Market. Users/projects can buy/sell most SNARK proofs there. Currently, there are two trading pairs, ARITHMETIC-EXAMPLE and MINA-STATE.

Here is a detailed comparison of these projects:

Use Cases

With ZK-based cross-chain messaging relay protocols, developers can easily extend applications to different blockchains.

In the past, contract deployments were mainly concentrated on one chain. When extending to another chain, the application had to be redeployed. Using ZK-based cross-chain messaging relay protocols will enable a paradigm shift from single-chain applications to cross-chain applications. Large projects can easily expand to different chains. This will have 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 relay protocols will open up markets with various possibilities. DeFi, DID, governance, and development will benefit from this.

DeFi

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

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

Farming can have more flexible strategies. They can now seek more profit opportunities across different chains.

Lending protocols can collaborate with more DeFi protocols on different chains and accept deposits of various tokens from different chains.

On-chain derivatives will greatly benefit from liquidity. With secure cross-chain communication, the derivatives market can reach more potential customers across different chains and aggregate more liquidity. This can provide a better trading experience.

Asset management applications can access more assets from different chains. They can also access derivatives from different chains. This allows financial managers to employ more investment strategies.

Application Chains

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 specific technical features. DApp developers can also customize fee structures to incentivize users. There are many application chains on Cosmos because it has better interoperability. ZK-supported cross-chain protocols will be better tools for connecting non-Cosmos application chains with the EVM or layer2 ecosystems. Many Rollup SDKs currently in development can benefit from ZK-supported cross-chain protocols.

The Cosmos ecosystem is leading all other major ecosystems in APP chains. Cosmos has made good progress in sharing security across application chains. ZKP may facilitate the expansion of the Cosmos ecosystem. Composable finance is working to extend Cosmos to Polkadot and NEAR. Electron Labs and zkBridge are bringing Cosmos to Ethereum.

Leveraging the Features of Different Chains

No single blockchain is perfect. They optimize for one purpose at the expense of other functionalities. With cross-chain messaging protocols, developers can leverage the strengths of each blockchain while avoiding their weaknesses.

DApp developers can deploy their DApp components across different chains. For example, some chains may be good choices for computation due to low computation costs. Some chains may be optimized for privacy, which will serve as privacy features for DApps. Some chains can host files, while others are suitable for providing front ends. Cross-chain messaging protocols can glue these components together and allow developers to fully utilize each blockchain.

Conclusion

ZKP provides a completely new way for cross-chain communication. While it cannot fully solve the security issues of traditional cross-chain bridges, the power of ZKP has significantly reduced the cost of secure cross-chain messaging communication. The size of the proofs is much smaller than before. The cost of on-chain verification has also decreased significantly. Being able to verify the source chain state on the target chain can achieve shared security similar to IBC. This was previously impossible to implement at low cost.

ZK cross-chain communication protocols empower protocols on different chains to communicate with each other. Developers can build full-chain DApps based on ZK cross-chain protocols. DeFi and application chains will benefit from this.

Cross-chain communication protocols are still in their infancy. Developers are working hard to develop these protocols, and issues such as how to synchronize states in real-time across different chains remain unresolved. Debugging cross-chain DApps can also be painful. Developers are exploring the best models for building cross-chain DApps, and we will see the impact of cross-chain DApps in the coming years. As a cross-chain communication protocol connecting different blockchains, it will have an impact similar to globalization.

References:

https://medium.com/@ingonyama/bridging-the-multichain-universe-with-zero-knowledge-proofs-6157464fbc86

https://www.youtube.com/watch?v=8mE_0qZNVjo

https://www.ingonyama.com/blogs/bridging-the-multichain-universe-with-zero-knowledge-proofs