The ZK Cross-chain Message Protocol and How it Paves a New Way of Cross-chain Communication

TL;DR ZK technology offers a secure and cheap way for cross-chain communication Cross-chain communication protocols are still in their early stages but promise to allow Dapps to access data on different chains The DeFi and development sectors stand to benefit from the development of cross-chain Dapps The impact of cross-chain Dapps is expected to be significant in the coming years, akin to the impact of globalization Developers are working hard to explore the best schema for building cross-chain Dapps Latency, security and costs are main benchmarks for ZK cross-chain applications Four components of ZK message protocol: Storage Proof Geneartion, ZKP for storage proof, Relay ZKP and Unrolling We also provide an trained by this article, you can ask any questions related to this article. AI Intro In the past, there were only Ethereum and Bitcoin. They have the most liquidity, the most players, the most applications, and the most txs. In 2020, many new blockchains were launched, such as Avalanche, Polygon, and BSC. After the launch of these mainnets, we saw a paradigm shift from Ethereum and Bitcoin to ALT. Users are moving from Ethereum to ALT to find new opportunities. Builders move from Ethereum to ALT to fork existing projects. These builders create new opportunities for users looking for high returns. Ethereum used to have all the liquidity in the crypto world apart from bitcoin. By the end of 2020, it dropped dramatically to around 60%. Below is the TVL for 165 chains from DefiLlama. DefiLlama Today, the TVL pie chart looks like this. Ethereum takes up the majority of the liquidity. Tron and BSC take the second and third positions. After spreading assets and liquidity across different chains, users start to think about how to manage and move assets across different chains. Asset issuers also think about how to increase their acceptance by expanding to different chains. Cross-chain asset bridges become popular in 2022. Instead of using CEX as a cross-chain bridge, users are trying to move to a decentralized cross-chain bridge. Again, it is sometimes stuck and vulnerable, but it is easier to use and move large amounts of funds. However, asset bridges are still in the early stages and cannot meet the demands of Dapp builders. Assets bridges can only exchange assets on different chains. This is too limited to builders. Builders are looking for a more generalized way to meet cross-chain demands. With cross-chain communication, builders will have a new way to build cross-chain Dapps. With such a feature, the all-chain Dapp building paradigm shifts from distributed and isolated to integrated. In an isolated model, Dapp instances in different chains can’t communicate with each other. They can’t share data with each other. In the integrated model, the Dapp instances can talk with each other and may periodically sync data to one instance. This instance gets all the data and can modify the parameters on other instances. With ZK-powered cross-chain communication, it can relay the source chain states to the destination in a more concise format, because ZKP can provide concise proof. Also SNARK proof is relatively cheap to verify on the destination chains. These two important characteristics of ZKP enable low-cost cross-chain messaging. Verifying the source chain states on the destination chain enables an IBC style of cross-chain bridges. This greatly increases the security in the cross-chain backgrounds. Where are we A cross-chain asset bridge is a mechanism that allows for the transfer of assets or tokens between different blockchain networks. This is important because most blockchain networks are isolated from each other and cannot directly exchange assets or tokens. The concept of cross-chain asset bridges started to gain attention in the last few years, with the launch of projects such as Wormwhole, cbridge, and Stargate. These projects aimed to create interoperable blockchain bridges that could exchange assets and tokens seamlessly. There are several cross-chain bridges available in the market, including Binance Bridge, Celer cBridge, Wormhole, Anyswap, and Stargate. Cross-chain asset bridges cannot satisfy developers’ needs. Developers are looking for a more generalized cross-chain method, which would be a cross-chain message protocol. To satisfy the new demands in a quick and easy manner, most of these cross-chain bridges have their own cross-chain message relaying protocol, such as Celer IM, LayerZero, anyCall from Multichain, xcall from Connext. They provide some kind of API like this sendMessage(destinationChain, tragetAddress, payload) receiveMessage(sourceChain, sourceAddress, payload) The cross-chain message communication protocols are implemented based on their cross-chain asset protocol. With some modifications, these cross-chain asset protocols can now pass messages between chains. This made them difficult to implement customized functions for cross-chain message protocol apart from their cross-chain asset bridge because the overall design needs to be compatible with the cross-chain asset transfer. 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 omnichain Dapps. They are still in their early stages. No giant cross-chain Dapps are fully built on top of these cross-chain communication protocols. Why We Need ZK While these bridges bring several benefits, such as increased asset efficiency and improved user experience, they also pose security risks. Recurring attacks against cross-chain bridges have caused significant financial loss to users, making security a top priority in the development of these systems. These attacks cost users more than $1.5 billion. In one year, the total loss of the bridge in hacking events is about $1.3 billion. The fee for the bridge is around 5‱. Multichain is a big player in the cross-chain bridges. Thirty days volume for Multichain is $1.7B and fees are $635K. One year is about $20.4 billion in volume with a $7.6 million fee. It is certain that the total revenue of the cross-chain bridge market is still less than the loss fund. By verifying the ZKP of the source chain block headers, ZKP cross-chain message protocol can mitigate part of the security concerns. Users can directly access the proof on the destination chain and verify the proof by themselves. This would be hard to do without ZKP. In the traditional setting, this kind of verification would too expensive to afford. Design Architecture In this part, we will discuss how ZKP enables cross-chain message protocol in a secure and cost-effective way. The idea of relaying messages with ZK is relatively simple, but the detailed design can be complex. The overall workflow can be broken down into the following steps: Decide what data to pass to the target chain Obtain the storage proof(proof of some data is in the EVM storage) Generate the ZK proof based on the storage proof Pass the ZK proof from the source chain to the target chain Unroll the ZK Proof on the target chain Read the result from the target chain Storage Proof Generation Most EVM-compatible chains offer this functionality out of the box. Once users have identified the storage slot, they can use RPC calls to generate the appropriate storage proof. eth_getProof(DATA,ARRAY,QUANTITY|TAG) DATA, 20 Bytes - address of the account. ARRAY, 32 Bytes - an array of storage-keys that should be proofed and included. See eth_getStorageAt QUANTITY|TAG - integer block number, or the string "latest" or "earliest", see the default block parameter EVM-compatible chains use Merkle Tree to store accounts and storage data. This makes verification of these data relatively simple through creating Merkle Proof. A Merkle Tree is a type of data structure used in computer science, specifically in cryptography and blockchain technology. It is named after its inventor, Ralph Merkle, and is also known as a binary hash tree. The basic idea behind a Merkle Tree is to divide a large amount of data into smaller parts, hash each part, and then combine the hashes to form a single root hash. This root hash acts as a fingerprint for the entire data set, allowing for efficient and secure verification of the data’s integrity. In blockchain, a Merkle Tree is used to summarize and verify transactions in a block. Each transaction is hashed and added to the tree, and the hashes are combined in a specific way to form a single root hash, which is then added to the block header. This allows for an efficient and secure way to verify the validity of a large number of transactions in a block, without having to verify each transaction individually. In the event that any data in a transaction is changed, the root hash will also change, indicating that the data has been tampered with. A Merkle proof, also known as a Merkle path, is cryptographic proof that a specific piece of data is included in a Merkle Tree. A Merkle proof provides a way to verify the authenticity of a transaction or other piece of data without having to download and verify the entire Merkle Tree. In a Merkle proof, a series of hashes from the bottom of the Merkle Tree to the root hash is provided, along with the specific data being verified. By starting with the specific data and following the hashes up the tree, a recipient can calculate the root hash and compare it to the root hash stored in the block header. If the calculated 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 for the verification of specific data without having to download and verify the entire Merkle Tree, Merkle proofs reduce the amount of data that needs to be transmitted and processed, improving the overall performance of the network. ZKP for Storage Proof It is not practical to post the entire storage proof on the target chain because it is too large, around 4kb. Verification of the proof is also expensive. It takes 600k gas to do the verification on Ethereum. If the gas price is 30 gwei, the total fee would be 0.018 ETH(30 USD). ZKP has some great features for this scenario. ZKP can provide compression and composability. Developers can create a ZKP based on the Merkle Tree Proof. This can greatly reduce the size of the proof and make it easier to verify. Verifying a Plonk takes about 290k gas. If the gas price is 30 gwei, the total fee would be 0.009 ETH(15 USD). A Groth16 verification used about 210k gas. If the gas price is 30 gwei, the total fee would be 0.006 ETH(10 USD). With composability, developers can even combine different storage proofs into a single ZKP to save resources. Relay ZKP To securely relay related commitments, like state root or related ZKP to the destination chain, we need to design a consensus mechanism to do this. There are three common ways to relay the ZKP: Messaging: Use some messaging protocol to pass the ZKP and get related commitment by OP code Consensus Validation: The related commitment is verified by running the consensus algorithm Optimistic MPC relayer: Part of the ideas are similar to what we see in many cross-chain asset bridges and OPRU designs. There is a committee between the source chain and the destination chain. The participants in the committee decide on the validity of the relayed block commitment. The validity can be challenged by anyone. When challenges happen, bridges cannot roll back like the rollup. A separate set of challengers need to actually stop the malicious message from being delivered. This challenge costs a lot and has a high latency because this involves overhead to constantly upload root hash and all call data to the source chain. It also only works in point to point manner. The main benchmarks for relaying ZKP are: Latency Gas cost Trust Off-chain computation overhead Messaging is quite slow in terms of latency because message delivery takes time to confirm. Users have to wait for delivery confirmation after new blocks have been created. In terms of gas cost, messaging requires interaction with two chains. In terms of the trust, the assumptions are fair because the security is equal to the security of the chain. In terms of off-chain computation overhead, there is no need to do anything off-chain. Consensus validation is a viable approach. It has similar trust, gas cost, and trust with messaging. However, it has to verify the signature off-chain. This introduces a large off-chain computation overhead. Consensus validation can also be done in ZKP today. An optimistic MPC relayer sacrifices some trust but gains much better latency. Users only need to post the transaction to the relayer network. The latency is low. Depending on the specific optimistic MPC relayer mechanism, the challenge period may cause larger latency. For the trust, users need to have minimal trust in the relayer network. There is not a lot of off-chain computation, but there is a need for communication in the relayer network and fraud-proof. Unrolling After getting the commitment, users on the destination chain can unroll the commitment, like headers or block hash to access the past states. Three common ways to do the unrolling are: Onchain accumulation Onchain compression Offchain compression On-chain accumulation is a method for unrolling commitments in a blockchain network. In this approach, the entire procedure of recreating block headers from a commitment is performed directly on the blockchain. The properly encoded block headers are provided as part of the call data in a transaction, and the blockchain can be trusted to perform the computation. The benefit of this approach is that there is no overhead in terms of proving time, and the latency is low because the proof does not need to be verified outside the blockchain. However, the downside is that the gas cost can be high, as the computation can be resource-intensive. On-chain compression is a method for reducing the amount of data that needs to be stored on a blockchain network. It is used to minimize the storage cost associated with storing large amounts of data on a blockchain. The idea behind on-chain compression is to use a compression algorithm to reduce the size of the data so that it takes up less space on the blockchain. This can be done by removing redundant or unnecessary information from the data, or by using data structures that are optimized for space efficiency. The compressed data is then stored on the blockchain and can be decompressed when it is needed for use. On-chain compression has the advantage of reducing storage costs and improving the scalability of the blockchain network. However, it also has some disadvantages. For example, the process of compressing and decompressing the data can be computationally expensive, which can increase the latency of the blockchain. Additionally, the compression algorithm used may have a negative impact on the security of the data, as it may be vulnerable to tampering or attack. Similarly, off-chain compression compresses the data and stores it off-chain. Here is a comparison table for these three methods: Related Projects Many players join this field with the hope to improve the interoperability of different chains and decrease the potential hacking risks. The most popular and promising projects in the fields are the following: Succinct Labs Lagrange zkBridge Herodotous =nil; Foundation Succinct Labs uses light client approaches. It uses a light client to verify the consensus from the source chain to the consensus layer of the target chain. ZKP is used to generate proof of consensus. 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 a sharded private key that it uses to attest to the state of a particular chain. Each State Root is a threshold signed Verkle Root that can be used to prove the state of a particular chain at a particular time. State Roots are fully generalized and can be used within State Proofs to prove the current state of any contract or wallet in a chain. Herodotus uses storage proofs with ZKP to provide smart contracts with synchronous access to on-chain data coming from other Ethereum layers. It has an MPC Optimistic Relayer to relay the commitment. The off-chain compression unrolls the relayed blockchain headers off-chain and creates the proof. zkBridge uses an MPC relay network to generate and relay the ZKP of block headers to the target chains. It uses deVrigo and recursive proof to achieve very fast proof times, but there is complexity in MPC computation. The first user initiates the cross-chain message request. The sender in the source chain then forwards the block header to the relay network. The verifiers in the relay network generate the ZKP of the block header and pass it to the updater contract. The updater contract verifies the proof. After accepting the proof, the updater contract forwards the proof to the receiver, which forwards it to the application and users in the destination chain. also works on ZK cross-chain message protocol. It empowers developers to access Mina state on Ethereum. They launched a at the end of 2021 to verify Mina states on Ethereum. This infra allows smart contracts on Ethereum to verify the validity of Mina state. With this infra, smart contracts have the ability to recognize invalid cross-chain tx. =nil; Foundation demo Mina has its own state proofs but it is expensive to verify them on Ethereum. =nil; Foundation uses its own Placeholder prove system to generate auxiliary state proofs which would be cheap to verify on Ethereum. This infra enables Ethereum smart contract to verify Mina state proof totally on-chain. In the future, cross-chain apps can directly verify the cross-chain tx validity with this infra. We can use this infra to build a bridge from Mina to Ethereum with the following steps: The bridge locks $MINA on Mina The infra generates Mina state proof The infra put Mina state proof onto Ethereum Ethereum checks if the state proof is valid Ethereum accepts and stores the proof in case it is valid and rejects it otherwise The bridge checks the state and releases $WMINA on the Ethereum Later =nil; Foundation is working hard to solve the direction issues. In the previous demo, it was only one-way cross-chain communication. Now they theoretically support bidirectional bridging. The state proof on the source chain would be generated in the Placeholder proof system and wrapped in Kimchi proofs. The proof is then submitted to the Mina verifier. The verifier will treat the source chain state proof the same as a Mina native zkApp generated proof. =nil; Foundation has also released the Proof Market, where users/projects can buy/sell mostly SNARK proofs. Currently, there are two pairs open, ARITHMETIC-EXAMPLE and MINA-STATE. Here is a detailed comparison of these projects. Application Scenario With the ZK-based cross-chain message relay protocol, developers can easily extend their applications to different blockchains. In the past, the development scheme was focused on one chain. When extending to another chain, the application has to be deployed again. With the ZK-based cross-chain message relay protocol, there would be a paradigm shift from a single-chain application to a cross-chain application. Large projects can easily be extended to different chains. This would have a similar effect to globalization. We would like to see more international companies or giant cross-chain Dapps. With low latency/real-time and low-cost cross-chain message relay protocol, it opens up the market with many possibilities. The main application would be DeFi, DID, governance, and development DeFi DeFi can benefit a lot from this. The cross-chain message relay protocol can help DeFi products integrate liquidity from different chains. DEXs, cross-chain swaps, and aggregators can provide a better user experience, lower slippage, and more liquidity on trading pairs. There would be one united liquidity pool for one trading pair on different chains. There would be the smaller price differences between different chains. On-chain exchanges can obviously gather more liquidity and provide CEX comparable user experience. Yield farming can have a more flexible strategy. They can now reach different yield opportunities on different chains. Lending protocols can coordinate with more DeFi protocols on different chains and accepts deposits on more chains. On-chain derivatives suffer a lot on liquidity. With safe cross-chain communication, it can reach more potential customers on different chains and gather more liquidity. This could provide a better trading experience. Money management can access more assets on different chains. They can also access derivatives from different chains. This makes more investment strategies available to portfolio managers. APP chain App chain or custom rollup gives Dapps more freedom. Dapp developers can customize the app chain to suit their own needs, such as performance or technical features. Dapp developers can also customize the fee structures to incentivize users. There are many app chains on Cosmos because of its better interoperability. ZK-powered cross-chain protocol would be a better tool to connect these non-Cosmos app chains with EVM or layer2 ecosystem. Many ongoing rollup SDKs can benefit from ZK-powered cross-chain protocol. The Cosmos ecosystem is ahead of all other major ecosystems on the APP chain, achieving good traction on shared security across different APP chains. The expansion of the Cosmos ecosystem may be facilitated by ZKP. Composable finance is working to expand Cosmos to Polkadot and NEAR. Electron Labs and zkBridge are bringing Cosmos to Ethereum. Leverage the power of different chains No blockchain is perfect. They are optimized for one purpose at the expense of other functionalities. With a cross-chain messaging protocol, developers can harness the power of each blockchain and avoid its drawbacks. Dapp developers can deploy components of their Dapps in different chains. For example, some chains may be a good choice for computation because of the low computation fee. Some chains may be optimized for privacy and this would serve as the privacy function for the Dapp. Some chains can host the file storage and some would be suitable for providing the front end. A cross-chain messaging protocol can glue these components together and allow developers to take advantage of each blockchain. Conclusion ZKP offers a new way for cross-chain communication. Although it doesn’t necessarily solve the security problem of the cross-chain bridge, with the power of ZKP, secure cross-chain message communications now become affordable. The size of the proof is much smaller than before. The on-chain verification costs also reduce a lot. Verifying the source chain state on the destination chain enables an IBC-style shared security. This is not applicable to achieving this at a low cost in the past. ZK cross-chain message protocols enable Dapps to communicate with each other on different chains and access states of different chains. This enables the possibility to build omnichain Dapps. DeFi, App chains can benefit from it. Cross-chain communication protocols are still in their infancy. Developers are working hard on these protocols. Problems like how to real-time sync states between different chains are still not solved. Debugging cross-chain Dapps can also be painful. Developers are exploring the best schema to build cross-chain Dapps. We will see the impact of cross-chain Dapps in the next few years. It would be as impactful as globalization as a cross-chain communication protocol connecting different blockchains. Source https://medium.com/@ingonyama/bridging-the-multichain-universe-with-zero-knowledge-proofs-6157464fbc86 https://www.youtube.com/watch?v=8mE_0qZNVjo Also Published Here