Author: Howe & Faust, geek web3

Foreword:

• ZetaChain is a POS public chain based on Cosmos SDK. Its blocks record cross-chain messages and data initiated on the "external chain". Users can publish messages in specific formats on "external chains" such as BTC through principles similar to the Ordinals protocol to convey their "intentions" to the ZetaChain network;

• ZetaChain's The nodes use consensus to determine which messages are to be processed and in what order. Finally, through TSS threshold signature technology, a digital signature is generated on the target chain, releasing assets from the public account of the chain and triggering subsequent transaction steps.

(The current list of ZetaChain’s verifier nodes includes many project parties or institutions, including OKX, HashKey Cloud, Dora Factory, etc.)

• Since ZetaChain itself is EVM compatible, it supports the deployment of contract logic. Full-chain DAPP project parties can write cross-chain message processing programs directly on the ZetaChain chain without deploying bridging asset contracts on multiple chains, which can save development costs; from the user side, in theory, it only needs to interact with the ZetaChain Contract interaction without having to interact multiple times with the bridge contract between the source chain and the target chain can also save handling fee costs;

• With some " Similar to the Intent project with the effect of "one-stop asset custody chain", ZetaChain itself supports the deployment of asset contracts or Defi protocols. Users can generate specific messages on the DAPP front-end on different chains and make asynchronous calls to the Defi contract or asset status on ZetaChain ( Supports BTC on-chain accounts);

• This is like letting ZetaChain directly host a unified asset account for the entire chain, but to achieve this effect, a dedicated DAPP front-end to cooperate.

• At present, the most important function of ZetaChain is to serve as the underlying facility for cross-chain and full-chain interoperability, which can both parse and process specific cross-chain Chain messaging can also be used as a business logic execution platform for multi-chain DAPPs. The main business model is a typical B to B to C.

With the continuous development of the blockchain industry, we are in an era of multi-chain interconnection. In this context, public chains with different characteristics have derived differentiated application scenarios and created diverse experiences for users. However, at the same time, the problem of "islands between chains" has become increasingly serious. Accounts on different chains are often unable to communicate with each other, and people's entire chain assets are in a state of fragmentation and not unified, which increases the threshold for use and greatly reduces the user experience.

It can be said that the separation and incompatibility between heterogeneous chains are one of the main reasons that hinder the growth of user conversion rates. The current popularity of the BTC ecosystem has further highlighted the interoperability issues of heterogeneous chains.

As Vitalik Buterin said many years ago: "Multi-chain is the future". Although the coexistence of multiple chains has become a general trend, establishing cross-chain bridges betweenheterogeneous chains is still a troublesome matter.

In order to solve the problem of multi-chain interoperability, LayerZero, Polyhedra, Map Protocol, Bool Network, and even Cosmos and Polkadot have all proposed different inter-chain messaging solutions, and ZetaChain, which recently launched Token, is also an important member of the full-chain infrastructure landscape.

In the following, we will briefly explain ZetaChain’s full-chain solution from a technical perspective strong>How ZetaChain serves as the underlying infrastructure for full-chain interoperable DAPPs toachieve cross-chain message parsing and processing.

Problems with existing cross-chain solutions

In fact, simply speaking of the problems that cross-chain bridges need to solve, the simplest scenario is the transfer of assets on different chains. To transfer assets from ETH to Polygon, you must first transfer the assets to the designated deposit address on the ETH chain, and then receive the same amount of funds on the Polygon chain.

But the problem is that Polygon's nodes cannot confirm what happened on the ETH chain, and they don't know whether you really recharged the xx amount. If someone falsely claims that he transferred 100U to the designated address on the ETH chain, and then initiates a withdrawal statement on the Polygon chain, requesting the release of his 100U, this will cause a "withdrawal problem out of thin air."

The key to the cross-chain bridge is to solve the "out of thin air withdrawal problem" here, that is, to confirm that all withdrawal statements correspond to real recharge behaviors. In essence, it is Try to prove on chain B that N transactions related to the cross-chain bridge did occur on chain A.

Currently mainstream cross-chain bridges tend to use notarization The human mechanism is to set up a group of notary nodes and achieve "consensus" through multi-signature or MPC signature. As long as the majority of notaries believe that your cross-chain behavior can be approved, your assets can be transferred smoothly.

There are also some cross-chain bridges that adopt more secure hash locks, or use on-chain contracts to implement light nodes of other chains, and confirm cross-chains by receiving merkle proof or zk proof Behavioral effectiveness, but the cost of this kind of cross-chain bridge is often relatively high, which will eventually be passed on to user fees. Therefore, most cross-chain bridges still choose the multi-signature mode of off-chain notary nodes.

Reference materials: Vernacular science: What should be considered when designing a cross-chain bridge? .

Cross-chain bridges based on notaries often face huge risks: they are vulnerable to hacker attacks or self-theft. According to statistics from SlowMist Hacked, there were a total of 16 cross-chain bridge security incidents in 2022, with losses Reaching US$1.21 billion, accounting for 32% of the total losses from on-chain attacks that year, this shows the harm of cross-chain bridge security vulnerabilities.

At the same time, most of the existing cross-chain bridge solutions choose The Lock-Mint model is to lock assets on chain A and issue corresponding mapped assets on chain B, thereby realizing cross-chain assets. However, in the deposit and withdrawal process of this type of scheme, multiple interactions with the mapped asset contract are required, and the handling fee friction is large, and there is a problem of capital loss.

In addition, many cross-chain bridge solutions only support asset transfer between EVM-compatible chains. Cross-chain behavior in heterogeneous chains such as Solana and Bitcoin is often subject to different technical standards. , development is more difficult.

Due to comprehensive security and handling fee issues, current mainstream cross-chain bridge solutions often fail to achieve very good results, let alone guarantee the "native cross-chain" of assets. In today's Bitcoin ecosystem, more and more people are eager to achieve a native and seamless cross-chain interactive experience, looking forward to finding a better solution. ZetaChain has come up with its own solution for this.

The function of ZetaChain: the underlying infrastructure of full-chain interoperable DAPP

ZetaChain’s self-positioning is the The infrastructure of chain interoperable DAPP specifically supports various full-chain interactive application protocols and is a typical B To B To C underlying infrastructure. Through the PoS admission mechanism, it allows any node that pledges assets to enter the network and act as a notary. All PoS nodes participate in the verification and processing of cross-chain messages through TSS threshold signature technology to improve security as much as possible.

At the same time, smart contracts can be deployed on ZetaChain to add business logic related to asset swaps. Users can send messages in a specific format on any chain and call ZetaChain or its supported Defi contracts on multiple chains can indirectly call the DeFi function on Polygon on the BTC chain. The effect achieved in this way is: message transmission between different blockchains to achieve interoperability.

DAPP based on full-chain interoperability scenarios The business logic of asset swap can be deployed on ZetaChain to help users automatically exchange gas tokens on different chains.

For example, you can use the front-end of some full-chain DAPP to send a message in a specific format on BTC through a data publishing method similar to the Ordinals protocol, indicating the desired Call the XX contract on Solana, and this message will be monitored by the ZetaChain node.

After that, the AMM contract on ZetaChain can automatically calculate the exchange ratio between BTC and SOL, then release an equal amount of SOL on the Solana chain, complete subsequent complex operations such as calling the contract, and finally Then transfer the assets you deserve back to your BTC address or Solana address. This is the so-called "full chain interoperability". You only need to publish a message on one chain to remotely call multiple DAPP on the chain,Of course, this involves the publishing and triggering process of several asynchronous messages.

Here, we can understand ZetaChain as a "chain-in-chain settlement layer", all multi-chain interaction scenarios, such as calls initiated on chain A A certain DAPP of chain B is equivalent to chain A first "settling" with ZetaChain, and then ZetaChain synchronizes the pre-processed settlement results to the corresponding account of chain B, and then completes the subsequent steps.

There is no excessive interaction and handling fee friction with the mapped asset contract in the entire process. The asset circulation is completed through ZetaChain’s public accounts on different chains. This eliminates the need to frequently deploy mapping asset contracts on different chains like traditional cross-chain applications.

At present, it seems that full-chain applications based on ZetaChain can It saves a lot of trouble, at least there is no need to go to great lengths to design mapping asset contracts on different chains. All details about the entry and exit of assets between the source chain and the target chain are "contracted" by ZetaChain. In other words, you only need to deploy business logic related to cross-chain transactions on ZetaChain.

This makes it easier for different full-chain applications to support non-EVM chains such as Solana, Algorand, Bitcoin and DogeCoin on the front end, without the need to go to great lengths to implement exclusive contracts for cross-chain applications on different chains. .

In addition, ZetaChain itself also supports the deployment of asset contracts or AA accounts. Users on different chains can send messages in a specific format to call, as if operating a unified account across the entire chain. , this design idea is also reflected in the Particle chain of Particle Network, and the final effect is:

Users can try their best to record asset data in one chain, ZetaChain or Particle Chain When necessary, send a call message through the DAPP front-end on the "external chain" to asynchronously call its own asset contract on ZetaChain. Then ZetaChain will transfer certain assets to the address specified by the user message through the public account on the external chain. Or interact with the user-specified Defi protocol.

Of course, this series of operations requires a specialized front-end DAPP To achieve this, in other words, ZetaChain itself only provides services for the underlying facilities of the entire chain, and a dedicated front-end entrance is required on the application side to generate messages in special formats.

ZetaChain’s security model: Large-scale notary node network based on POS staking

In the final analysis, ZetaChain is essentially a cross-chain Message processing, and the set up notary node network, which is based on the Cosmos SDK, consists of many Validator verification nodes, and uses POS as the access mechanism to achieve node anti-witch and underlying security.

Validator nodes are in the ZetaChain network, As decentralized notaries, they will confirm which pending cross-chain requests have been triggered on other chains, and through consensus, record these cross-chain behaviors and proceed with subsequent steps. Through TSS distributed key signature, ZetaChain can generate transaction instructions on other chains.

It can be said that what Validator does is partially similar to the cross-chain bridge in the notary mode, but through POS pledge, the notary node is more trustworthy to solve the witch problem.

(The current list of Zetachain validator nodes has many project parties. or institution)

Zetachian’s Validator client contains two modules, ZetaCore and ZetaClient. The ZetaCore module participates in the generation and consensus process of ZetaChain blocks, while the ZetaClient module observes events on the external chain and signs outbound transactions.

The outbound here can be simply understood as sending the transaction log records on ZetaChain to the "external chain" (referring to other chains outside ZetaChain), thus The corresponding behavior is triggered on the target chain. The content sent mainly includes the contract address, chain ID, and message content that the user declares in the message to be called. In fact, it is similar to the Log part in the Ethereum transaction.

On the contrary, inbound can be understood as ZetaChain Related messages/transactions on external external chains, such as cross-chain requests, calls to smart contracts on zEVM, etc., are recorded on ZetaChain.

It should be noted here that when actually running the Validator node of ZetaChain, the client code contains three modules: verifier, observer, and TSS signer. These three modules are responsible for different functions, but they all belong to the ZetaChain client.

Observer and TSS signer module

First of all, all ZetaChain nodes have a "validator" module, which is basically the same function as the Validator node in the PoS public chain, and must participate in the block generation and consensus process. In addition, nodes can vote to participate in on-chain proposals in proportion to the pledged tokens (ZETA). ZetaChain's blocks include all cross-chain records processed, full-chain smart contract interactions and other behaviors, which are equivalent to log records.

The "Observer" module in the ZetaChain client , which will monitor cross-chain transactions/messages in specific formats by running full nodes/light nodes of other public chains. The observer module can be divided into two modes: active mode and passive mode.

Different ZetaChain nodes can make choices to switch the observer module to one of two modes. The observer module will continue to monitor whether there are cross-chain messages/events related to ZetaChain on other chains. If so, the observer module of the ZetaChain node will report the situation to the verifier module. These observed cross-chain messages will be submitted to ZetaChain's blocks and fully confirmed through consensus.

The observer module has two modes: active mode and Passive mode. In active mode, nodes will continuously scan transactions/events/status on blockchains outside ZetaChain and run fullnodes of other chains; while in passive mode, nodes do not synchronize complete blocks of other blockchains and passively read from other ZetaChain nodes. At, receive the parsed cross-chain message.

However, although nodes in passive mode do not synchronize complete external chain blocks, they will synchronize block headers and confirm through Merkle proof that these cross-chains really exist on the external chain. Message/Transaction Data.

The advantage of active mode is that most ZetaChain nodes will Synchronizing the data on the external chain is the most censorship-resistant at this time. If any user wants to interact with ZetaChain, as long as a node detects it, you can initiate a request on the external chain.

But in active mode, the cost of running nodes is higher. In addition to running ZetaChain's own node client, it is also necessary to run the full nodes of external chains, synchronize data and scan at all times. In passive mode, the running cost of ordinary observer nodes is much lower. Only specific nodes run the full node client of the external chain, and other nodes only run the light clients of the external chain, without synchronizing the complete blocks of the external chain.

In this way, the cost in passive mode is cheaper, and it is easier to expand the number of nodes and facilitate the docking of multiple external links. However, the disadvantage of the passive mode is that the data observation activity on the external chain depends on a few nodes and has poor censorship resistance.

To alleviate this situation, ZetaChain will incentivize nodes to run active mode observer modules.

(In active mode, the node also needs to run external links Full node client; in passive mode, only run the light client of the external chain, receive cross-chain messages + merkle proof from the ZetaChain node in active mode, and confirm the validity of the message)

TSS signature

All cross-chain messages observed and verified by ZetaChain nodes will eventually trigger a transaction on the target chain through ZetaChain’s public account address. and then perform subsequent operations. In this process, a digital signature needs to be generated for the cross-chain transaction on the target chain.

In order to ensure security and trustlessness, the generation of signatures is undertaken by all nodes of ZetaChain, and the key fragments used to generate signatures are jointly stored. These key fragments are distributed among multiple signers. Only when the vast majority of signers sign can a digital signature of the transaction be generated on the external chain. At any time, a single entity or a small group of nodes cannot trigger transactions/sign messages on external chains on behalf of ZetaChain

(Under ZetaChain’s cross-chain model, you only need to have a public account address on different chains without having to deploy complex smart contracts)< /p>

ZetaChain’s multi-signature algorithm uses TSS, which is called Threshold Signature Scheme. To the outside world, the transaction digital signature we can see only corresponds to a private key, public key and address, but in fact, this private key is generated from many fragments without an intermediary. Fragments are distributed locally on all ZetaChain node devices. At any time, no single entity or small number of validators can piece together private key fragments and sign messages on behalf of the network as a whole.

TSS’s key generation and signing process is completed through multi-party computation (MPC), which will not reveal the secrets of any participating nodes. ZetaChain's nodes can generate transaction signatures on different chains. On the basis of compatibility with various EVM chains, the function of remotely calling smart contracts is added for accounts on Bitcoin/non-smart contract chains. The intuitive experience is just like BTC users can directly call Some defi features.

This scenario is actually particularly suitable for many companies equipped with the BTC ecosystem. Chain Defi applications, because too complex business logic cannot be implemented on the BTC chain, and can only rely on external facilities to remotely call certain Defi contracts. These characteristics of ZetaChain are suitable for users in the BTC ecosystem to use asynchronous calls,

zEVM: a one-stop full-chain DAPP contract platform

Unlike traditional cross-chain solutions that require the deployment of mapping asset contracts on each chain, ZetaChain can only deploy smart contracts once on its own chain, that is, to achieve multi-chain cross-chain functionality. In ZetaChain, there is an EVM-compatible execution layer called zEVM, and cross-chain smart contracts can be deployed directly on zEVM.

zEVM supports the following functions:

Anyone can send transaction data in a specific format on the external chain and call a contract on zEVM ;

The contract logic on zEVM can control the outbound transaction data generated on the external chain.

These two additional features enable zEVM to support general programming, deploy specific business logic, and atomically modify the status of different chains. If a cross-chain operation occurs and ZetaChain detects that the subsequent steps of this cross-chain operation are not successful on the target chain, the data modified by the cross-chain transaction in the ZetaChain contract can be rolled back, as if nothing happened. Didn't happen.

At the same time, full-chain application DAPP does not need to deploy mapping asset contracts on different chains. It only needs to use the contracts on the ZetaChain chain to process messages across chains in one stop. The logic is centralized and there is no need to frequently deploy cross-chain contracts to multi-chain networks.

This can greatly save the development cost of the whole chain DAPP. At the user level, because there is no need to frequently interact with mapped asset contracts on multiple chains, the cost is lower than those of mainstream cross-chain bridges that require deploying mapped asset contracts on different chains.

In addition, special Defi contracts and ZRC-20 or even NFT assets can also be deployed on ZetaChain to synchronize data on asset status, or deploy AA accounts. This enables it to function as a unified asset management (status recording) platform. Because we no longer need to work hard to own assets on multiple chains, this scenario of unified asset accounts across the chain can give more imagination in the future.

Summary

Through the previous content, we more or less have a better understanding of ZetaChain's "full-chain interoperability infrastructure" identity. It monitors specific messages/transactions in the external chain through the observer module in the Validator client, and reports them to the verifier module, and finally reaches consensus on the messages in the ZetaChain network. Then the data contained in the message is parsed, TSS is used to generate a digital signature, and the subsequent transaction process is triggered on the corresponding target chain, thereby realizing interaction on the entire chain.

At the same time, the full-chain smart contract based on ZetaChain allows us to interact with different blockchains close to native, without using mapping asset contracts on different chains. This It can avoid calling redundant contract logic and save handling fee costs.

At the same time, because ZetaChain itself is EVM compatible, any DAPP developer or even individual user can deploy customized cross-chain message processing logic. In theory, the entire chain can be deployed in one stop With DAPP contracts, cross-chain application developers do not need to frequently deploy/update mapping asset contract logic on different chains, eliminating the cost of reinventing the wheel.