Why use zero-knowledge proofs to develop cross-chain protocols?

Author: Kang Shuiyue, Founder of Fox Tech, Chairman of Danyang Investment

What Kind of Cross-Chain Services Do Users Need

In the past few years, various independent public chains and Ethereum Layer 2 solutions have emerged. Due to differences in security, low costs, fast transactions, and the disparities in developer and user communities, different chains have their own unique advantages, making it common for users to switch between different chains. Compared to the Ethereum chain, transaction fees on Layer 2 and other independent public chains tend to be cheaper, and transaction speeds are often faster. Therefore, users must use cross-chain bridges to reduce transaction costs or to access higher-quality or unique applications on other chains.

If we liken cross-chain bridges to "armored trucks," then regardless of whether there are people trying to rob the armored truck or what methods are used to rob it, the armored truck itself must possess strong defensive capabilities and must not have any security issues. There should be no problems in the design, production, and manufacturing stages of the armored truck, nor in the escorting, sending, and receiving stages. Existing cross-chain bridge solutions either have architectural design issues, code vulnerabilities, or the protocol itself relies on some trust assumptions during the sending, receiving, and relaying stages. All of these significantly reduce the security of cross-chain bridges.

As bridges built on various public chains, cross-chain bridges undoubtedly serve as a very important solution for the cross-chain transfer of assets, addressing the liquidity fragmentation between numerous public chains. However, user demand for cross-chain technology will not be limited to asset transfers; asset cross-chain transfer is merely one application within the broader DeFi track of the entire cross-chain protocol. Two completely different networks gain interoperability through cross-chain protocols, which not only requires the transfer of tokens between independent platforms but also necessitates inter-chain communication of large files and data packets.

In the Web3.0 multi-chain ecosystem, users actually want to interact with all mainstream public chains for asset and data exchanges through a single application. During this interaction process, users do not want to frequently switch wallets and networks.

In the "one super and many strong" public chain landscape, users need a more secure, more universal, and more user-friendly inter-chain communication protocol.

What Are the Cross-Chain Communication Modes

Native Verification Mode

Native verification involves running a light client in the virtual machines of both the source chain and the target chain, facilitating inter-chain communication through relayers. The characteristic of this mode is that it does not require operating a chain that lies between various public chains. If zero-knowledge proofs are used, as in the case of Way Network, it can also eliminate the trust assumptions required by LayerZero.

Figure 1: Native Verification Mode

External Verification Mode

External verification involves one or a group of validators who need to monitor specific addresses on the source chain. When a user sends an asset to a specific address on the source chain, that asset will be temporarily locked. Third-party validators verify this information and need to reach a consensus. Once consensus is reached, the corresponding asset will be generated on the target chain.

The downside of this communication mode is the presence of "trust assumptions," which can lead to asset theft due to "single points of failure" or "local failures."

Figure 2: External Verification Mode

Local Verification Mode

Local verification is a localized verification mode, functioning as a peer-to-peer liquidity network. Each node itself acts as a "router," providing the original assets of the target chain rather than derivative assets.

The disadvantage of this mode is its inability to achieve "universality," as it can only be used for asset cross-chain transfers and not for the inter-chain transfer of general information and data.

Figure 3: Local Verification Mode

Upstream Chain Mode

The upstream chain requires dApps to deploy smart contracts on their chain so that messages can be replicated and sent to other Layer 1 public chains for state updates.

The main disadvantage of this mode lies in the business operation aspect, as this chain will compete with all Layer 1 chains rather than cooperate, since each is vying for dApps to be deployed on their own chain.

Figure 4: Upstream Chain Mode

Why zkRelayer is the Key to Unlocking Inter-Chain Communication

An excellent inter-chain communication solution should possess the following advantages:

• No trust assumptions, secure, i.e., Trustless, Secure

• Permissionless, decentralized, i.e., Permissionless, Decentralized

• General, universal, i.e., General, Universal

• Extensible, i.e., Extensible

• Fast, low cost, i.e., Efficient, Low Cost

Not all cross-chain solutions possess these advantages, and the importance of each advantage varies. Users can tolerate slower cross-chain services and higher cross-chain costs, and they may not immediately require various data format cross-chain transfers. However, the first point, Trustless, is indeed urgent and important. The earliest external verification mode used one chain to solve the communication problems of other public chains; from a methodological perspective, it is a relatively cumbersome approach that struggles to address the inter-chain communication challenges between EVM and Non-EVM, POW and POS chains. Meanwhile, the intermediary chain itself is a single centralized tool that is difficult to "self-verify," meaning that the external verification mode lacks both Decentralized Security and Trustless Security.

In native verification, LayerZero and Hyperlane primarily emphasize the roles of the Sender and Receiver clients, downplaying the roles of Relayers and Oracles. There are several issues here: first, users must trust that Relayers and Oracles will not collude maliciously; second, users must trust that the protocol itself will not act maliciously during the Relayer phase. In other words, none of the current solutions can achieve Trustless Security. Single points of failure and local failures are like a bomb that could explode at any moment, placed within a cross-chain communication solution that has inherent flaws.

zkRelayer is the zero-knowledge proof relayer for inter-chain communication proposed by Way Network, whose advantage is that users do not need to trust any external third parties or the protocol itself. As long as the mathematical and cryptographic proof processes are complete and correct, this system can be accepted by the public. Note that a fundamental change has occurred here: users trust the "truth," rather than any individual or organization. Individuals or organizations can make mistakes or act maliciously, but the truth cannot. In the entire process, Chain A → Sender → zkRelayer → ZK Verifier → Receiver → Chain B, the position of zkRelayer will surpass that of the Sender and Receiver light clients, becoming the core of the entire solution.

The core components of zkRelayer are the ZK Prover and Message Aggregator. The zero-knowledge proof method used by Way Network's ZK Prover is ZK-FOAKS proposed by Fox Tech, which is very fast and possesses both Recursive and Trustless characteristics, with linear proof times and sub-linear verification times reaching theoretical limits. Using ZK-FOAKS in the relayer for inter-chain communication will ensure that the entire communication is Trustless, Efficient, and Low Cost.

zkRelayer is the key to unlocking inter-chain communication. With the support of zkRelayer, inter-chain communication will usher in a new chapter.

Figure 5: Way Network's Universal Inter-Chain Communication Architecture