What kind of cross-chain services do users need?
Various independent public chains and Ethereum Layer 2 have emerged in the past few years. Due to the different advantages of different chains in terms of security, low cost, fast transactions, and differences in developer and user communities, it is very common for users to switch between different chains. Compared with the Ethereum chain, the fees on Layer2 and other independent public chains will be cheaper, and the transaction speed will be faster. Therefore, users must use cross-chain bridges in order to reduce transaction costs or use other higher-quality or unique applications on the chain.
If the cross-chain bridge is likened to a "money transport vehicle", then no matter whether someone comes to rob the cash transport vehicle, and no matter what means are used to rob the cash transport vehicle, the cash transport vehicle itself must have strong defense capabilities, and there cannot be any Security Question. There should be no problems in the design, production and manufacturing links of the cash transport vehicle, no problems in the escort link, and no problems in the sending and receiving links. In the existing cross-chain bridge solutions, either there are architectural design problems, or there are code loopholes, or the protocol itself relies on certain trust assumptions in the sending, receiving and relaying links. All of the above greatly reduce the security of the cross-chain bridge.
As a bridge built on various public chains, the cross-chain bridge solves the liquidity split between many public chains, and is undoubtedly a very important solution for cross-chain transfer of assets. However, users' demand for cross-chain technology will not only stop at asset cross-chain. Asset cross-chain is actually just an application of the entire cross-chain protocol's DeFi track. Two completely different networks have interoperability through cross-chain protocols. This interoperability requires not only the mutual 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 actually only want to smoothly interact with all mainstream public chains for assets and data through one application. During the interaction process, users do not want to switch wallets and networks frequently.
Under the "one super, many strong" public chain structure, what users need is a safer, more versatile, and more friendly inter-chain communication protocol.
What are the cross-chain communication modes
native authentication mode
Native verification is performed by running a light client in the virtual machine of the source chain and the target chain, and communicating between the chains through the relay. The characteristic of this model is that there is no need to operate a chain between various public chains. If zero-knowledge proofs are adopted like Way Network, the trust assumption required by LayerZero can also be eliminated.
Figure 1: Native authentication schema
external authentication mode
External validators have a validator or group of validators who need to monitor a 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. Third-party validators verify this information and consensus is required. When a consensus is reached, the corresponding assets will be generated in the target chain.
The disadvantage of this communication mode is that there is a "trust assumption", which is prone to asset theft due to "single point of failure" or "partial failure".
FIGURE 2: EXTERNAL VERIFICATION MODE
local authentication mode
Local verification is a local verification mode and a 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 derivative assets.
The disadvantage of this model is that it cannot achieve "universality", and 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 Authentication Mode
upstream chain mode
The upstream chain requires dApp to deploy smart contracts on its chain, so that messages will be copied and sent to other Layer1 public chains for status updates.
The disadvantage of this model is mainly reflected in the commercial operation level. This chain will compete with all layer 1 chains rather than cooperate with each other, because each other is competing for dApps to be deployed on their own chains.
Figure 4: Upstream Chain Pattern
Why zkRelayer is the key to unlock interchain communication
An excellent inter-chain communication solution should have the following advantages:
-
No trust assumption, security, that is, Trustless, Secure
-
Permissionless, decentralized, that is, Permissionless, Decentralized
-
General, that is, General, Universal
-
Extensible, that is, Extensible
-
Fast, low cost, that is, Efficient, Low Cost
Not all cross-chain solutions have the above advantages, and the priority of each advantage is also different. Users can tolerate slow cross-chain services and high cross-chain costs, and they don't necessarily need to do cross-chain transmission of various data formats right away. However, the first Trustless is indeed urgent and important. The earliest external verification mode is to use a chain to solve the communication problems of other public chains. From a methodological point of view, it is a relatively cumbersome way, and it is difficult to solve the inter-chain 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 "prove its innocence", that is, the external verification mode has neither Decentralized Security nor Trustless Security.
However, LayerZero and Hyperlane in native verification mainly emphasize the role of the Sender and Receiver clients, and weaken the Relayer and Oracle. There are several problems here: first, users must believe that Relayer and Oracle will not conspire to do evil; second, users must believe that the protocol itself will not do evil in the Relayer link. In other words, Trustless Security cannot be implemented in all current solutions. Single-point failures and partial failures are like a bomb that does not know when it will explode, placed in a cross-chain communication scheme with natural flaws.
zkRelayer is a zero-knowledge proof relayer for inter-chain communication proposed by Way Network. Its advantage is that users do not need to trust any external third parties, nor do they need to trust the protocol itself. As long as the proof process of mathematics and cryptography is complete and correct, this system can be accepted by the public. Please note that things have changed fundamentally here, and what users believe is the "truth" rather than someone or an organization. People or organizations make mistakes and do evil, but truth does not. In the whole link, Chain A→Sender→zkRelayer→ZK Verifier→Receiver→Chain B, the status of zkRelayer will surpass the two light clients of Sender and Receiver, 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 Way Network's ZK Prover is ZK-FOAKS, which has the advantage of being very fast and has two characteristics: Recursive and Trustless, and its linear proof time and sub-linear verification time have reached the theoretical lower limit. ZK-FOAKS used in the Relayer of inter-chain communication will ensure that the entire communication is Trustless, Efficient and Low Cost.
zkRelayer is the key that unlocks inter-chain communication. With the blessing of zkRelayer, inter-chain communication will open a new chapter.
Figure 5: Way Network's general inter-chain communication architecture