What kinds of cross-chain services do users need

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

If the chain bridge is compared to an “armored vehicle”, the armored vehicle itself must have a strong defense capability and no security problem, no matter whether there is anyone to rob the armored vehicle or what means are used to rob the armored vehicle. No problems can occur in the design, production and manufacturing links of armored vehicles, no problems can occur in the escort links, and no problems can occur in the sending and receiving links. Existing cross-chain bridge solutions either have architectural design problems, code vulnerabilities, or the protocol itself relies on certain trust assumptions at the transceiver and relay links. All these have greatly reduced the safety of the chain bridge.

Cross-chain bridge, as a bridge built on each public chain, solves the liquidity split between many public chains, which is undoubtedly a very important solution for the cross-chain transfer of assets. However, users’ demand for cross-chain technology does not stop at asset cross-chain. Asset cross-chain is actually just one application of the DeFi circuit of the entire cross-chain protocol. Two distinct networks have interoperability through cross-chain protocols, which 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-chain ecosystem, users only want a single application to smoothly interact with all the major public chains for assets and data. Users don’t want to switch wallets and networks frequently during interaction.

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

What are the cross-chain communication patterns

Native Validation Mode

Native validation is done by running a light client in the virtual machines of the source and destination chains and using Repeaters for inter-chain communication. The characteristic of this model is that there is no need to operate a chain between the public chains. You can also get rid of the trust assumptions required by LayerZero if you use zero-knowledge proofs like Way Network.

External Validation Mode

External validation has one or a set of verifiers that need to monitor the specific address of the source chain. When a user sends an asset to a specific address on the source chain, the asset is temporarily locked. A third-party verifier 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”, which makes it easy for assets to be stolen due to a “single point of failure” or “local failure”.

Local Validation Mode

Local validation is a partial validation mode and a peer-to-peer liquidity network. Each node is itself a “router,” and the router provides the original asset of the target chain, not the derivative asset.

The disadvantage of this pattern is that it cannot achieve “Generality”. It can only be used for the transfer of assets across chains, but not for the interchain transfer of general information and data.

Upstream Chain Mode

The upstream chain pattern requires Dapps to deploy smart contracts on their chains so that messages can be copied and sent to other Layer 1 public chains for status updates. 

The disadvantage of this model is primarily at the business level, where this chain competes with all Layer 1 chains rather than cooperating, as each competes for Dapps to deploy on its own chain.

Why is zkRelayer the key to interchain communication

An excellent interchain communication scheme should have the following advantages:

• There is no trust assumption, Trustless Security
• Permissionless, Decentralized
• General, Universal
• Extensible
• Efficient and Low Cost

Not all cross-chain solutions have these advantages, and the priorities of each are different. Users can tolerate slower cross-chain services, but also can tolerate higher cross-chain costs, and do not necessarily do a variety of data formats across the chain transfer immediately. But the first Trustless is really urgent and important. The earliest external verification mode is to use one chain to solve the communication problems of other public chains. From the perspective of methodology, it is a relatively cumbersome way, which is difficult to solve the communication problems between EVM and Non-EVM, POW, and POS. At the same time, the intermediate chain itself is a single centralized tool, and it is difficult to be “self-certified”. That is, the external verification mode is neither decentralized nor Trustless.

However, LayerZero and Hyperlane in native verification mainly emphasize the role of the Sender and Receiver while weakening Relayer and Oracle. There are several problems. First, users must trust that Relayer and Oracle are not conspiring to do evil. Second, the user must trust that the protocol itself will not do any harm in the Relayer. That is, Trustless Security cannot be implemented in any of the current solutions. Single points of failure and local failures are like a bomb that never knows when to explode, placed in a naturally flawed cross-chain communication scheme.

zkRelayer is a zero-knowledge proof repeater for inter-chain 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 proofs are complete and correct, the public can accept the system. Note that things have fundamentally changed here, and the user believes the “truth,” not a person or an organization. People and organizations can err and do evil, but truth cannot. In the whole link, Chain A→ Sender→ zkRelayer → ZK Verifier→ Receiver→ Chain B, zkRelayer will surpass Sender and Receiver, which are 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 used by ZK Prover of Way Network is ZK-Foaks proposed by Fox Tech, which has the advantage of being very fast, Recursive and Trustless, and the linear proof time and sub-linear verification time have reached the theoretical lower limit. ZK-FOAKS used in Relayer for inter-chain communication will ensure that the entire communication is Trustless, Efficient, and Low Cost. 

zkRelayer is the key to interchain communication. With the help of zkRelayer, inter-chain communication will open a new chapter.