Why use zero-knowledge proof to develop cross-chain protocols

康水跃

2023-01-19 09:38

Read this article in 13 Minutes

In the "one super many strong" public chain pattern, users need more secure, more general, more friendly inter-chain communication protocol.

Why to Use Zero-Knowledge Proof to Develop cross-chain Protocols

Kang Shuiyue is the founder of Fox Tech and chairman of Danyang Investment

What cross-chain services do users need

Over the past few years there have been various independent public chains and Ethereum Layer 2. It is not uncommon for users to switch between different chains due to their distinct advantages in terms of security, low costs, fast transactions, and differences between developer and user communities. Layer2 and other independent public chains are cheaper and faster than Ethereum. As a result, users must use cross-chain Bridges in order to reduce transaction costs or to use other higher-quality or unique applications on the chain.

If the cross-chain bridge is compared to "armored vehicle", no matter whether there is anyone to rob the armored vehicle, and no matter what means is adopted to rob the armored vehicle, the armored vehicle itself must have a strong defense capability, without any security problems. Armored car from the design, production, manufacturing links can not appear problems, transport links can not appear problems, sending, receiving links can not go wrong. Existing bridge solutions either have architectural design problems, code vulnerabilities, or the protocol itself relies on a certain assumption of trust for sending, receiving, and relaying. All of this greatly reduces the security of cross-chain Bridges.

As a bridge built on various public chains, cross-chain bridge can solve the liquidity separation among many public chains. Undoubtedly, it is a very important solution for asset cross-chain transfer. However, the demand of users for cross-chain technology does not just stop at asset cross-chain. In fact, asset cross-chain is just an application of the DeFi circuit of the entire cross-chain protocol. Two distinct networks have interoperability through cross-chain protocol. This interoperability requires not only the transfer of tokens between independent platforms, but also the inter-chain communication of large files and data packets.

In the Web3.0 multi-link ecosystem, users just want to smoothly interact with assets and data of all major public chains through one application. Users don't want to switch wallets and networks frequently during interactions.

In the "one super many strong" public chain pattern, users need more secure, more general, more friendly inter-chain communication protocol.

What are the modes of cross-chain communication

Native validation mode

Native validation is done by running a light client in the virtual machines of both the source and target chains and using a repeater to communicate between the chains. The characteristic of this model is that there is no need to operate a chain between the various public chains. If zero-knowledge proof is adopted like Way Network, the trust assumption required by LayerZero can also be eliminated.

Figure 1: Native validation pattern

External validation mode

External validation has one or a group of validators who need to monitor a particular address in the source chain. When a user sends an asset to a specific address on the source chain, it is temporarily locked. A third party validator verifies this information and needs to reach a consensus. When a consensus is reached, the corresponding asset is generated in the target chain.

The disadvantage of this mode of communication is that it has a "trust assumption" and is prone to asset theft due to "single point of failure" or "local failure".

Figure 2: External validation pattern

Local authentication mode

Local verification is a kind of local verification mode, which is a kind of point-to-point liquidity network. Each node is a "router" in itself, and the router provides the original assets of the target chain, rather than derived assets.

The disadvantage of this mode is that it cannot achieve "universality". It can only be used for cross-chain transmission of assets, but not for inter-chain transmission of general information and data.

Figure 3: Local validation pattern

Upstream chain pattern

Upstream chains require Dapps to deploy smart contracts on their chains so that messages can be copied and sent to other Layer1 public chains for status updates.

The downside of this model is mainly at the business level, where the chain will compete with all Tier 1 chains rather than cooperate, as each is competing for DApps to deploy on its own chain.

Figure 4: Upstream chain pattern

Why is zkRelayer the key to interchain communication

A good interchain communication solution should have the following advantages:

Untrusted assumption, security, Trustless, Secure

Permissionless, Decentralized. Permissionless, decentralized

That's General, Universal

It's extendable, it's extendable.

Fast, Low Cost, Efficient, Low Cost

These advantages are not shared by all cross-chain solutions, and the importance of each advantage varies. Users can tolerate slower cross-chain services, can tolerate higher cross-chain costs, and do not necessarily want to do cross-chain transmission of various data formats immediately. But the first Trustless is really urgent and important. The earliest external authentication mode is to use one chain to solve the communication problem of other public chains. From the perspective of methodology, it is a cumbersome way, which is difficult to solve the communication problem between EVM and Non EVM, POW and POS chain. At the same time, the middle chain itself is a single centralized tool, and it is difficult to "self-prove", that is, external verification model has neither Decentralized Security nor Trustless Security.

In contrast, LayerZero and Hyperlane in native authentication mainly emphasize the functions of Sender and Receiver, while weakening Relayer and Oracle. There are several problems here. First, users must trust that Relayer and Oracle are not conspiring. Second, the user must trust that the agreement itself does not do evil in Relayer. That is, Trustless Security is not implemented in any current solution. Single point failures and local failures are like a bomb that never knows when it will explode, embedded in a naturally flawed cross-chain communication scheme.

zkRelayer is a zero-knowledge proof repeater for interchain communication proposed by Way Network. Its advantage is that users do not need to trust any external third party, nor do they need to trust the protocol itself. As long as the mathematical and cryptographic proof process is complete and correct, the system can be accepted by the public. Notice that things have fundamentally changed here, and the user believes the "truth," not the person or organization. People and organizations make mistakes and do evil, but truth does not. In the whole process, Chain A Sender zkRelayer ZK Verifier Receiver Chain B, zkRelayer's status will go beyond the Sender and Receiver two light clients and become the core of the whole solution.

The core components of zkRelayer are ZK Prover and Message Aggregator. The zero-knowledge proof method adopted by ZK Prover of Way Network is ZK-Foaks proposed by Fox Tech, which is characterized by quickness and Recursive and Trustless. The linear proof time and sublinear verification time have reached the theoretical lower limit. The use of ZK-FOAKS in relayers for interchain communication ensures that the overall communication is Trustless, Efficient, and Low Cost.

zkRelayer is the key that unlocks interchain communication. With zkRelayer's blessing, the next chapter in chain-link communication will begin.