One-stop Omnichain DAPP Infrastructure

Forward the Original Title：Technical Insights into ZetaChain: A One-stop OmniChain DAPP Infrastructure

ZetaChain is a POS public chain based on the Cosmos SDK, where its blocks record cross-chain messages and data initiated on “external chains.” Users on external chains like BTC can communicate their intentions to the ZetaChain network by publishing messages in a specific format, akin to the Ordinals protocol. ZetaChain nodes employ a consensus mechanism to determine which messages to process and their sequences and ultimately utilize the Threshold Signature Scheme (TSS) to generate a digital signature on the target chain. This process involves releasing assets from the chain’s public account, triggering subsequent transaction steps.

The current list of validator nodes on ZetaChain includes numerous project parties and institutions, such as OKX, HashKey Cloud, Dora Factory, among others. Due to ZetaChain’s inherent EVM compatibility, it supports the deployment of contract logic. Full-chain DApp developers can directly write cross-chain message processing programs on the ZetaChain, eliminating the need to deploy bridging asset contracts across multiple chains and thus saving development costs. From the user’s perspective, theoretically, interacting with ZetaChain’s contracts is sufficient, eliminating the need for multiple interactions with bridging contracts between source and target chains and reducing transaction fee costs. Similar to some Intent projects with a “one-stop asset custody chain” effect, ZetaChain supports deploying asset contracts or DeFi protocols. Users can generate specific messages on the frontend of DApps on different chains to asynchronously call ZetaChain’s DeFi contracts or asset states. This setup supports BTC chain accounts as well. It is akin to letting ZetaChain directly host a universally unified asset account across all chains. However, achieving this effect requires a dedicated DApp front end to collaborate. As of now, ZetaChain’s primary function is to serve as the underlying infrastructure for omnichain interoperability. It can parse and process specific cross-chain messages and also act as the business logic execution platform for multi-chain DApps. The main business model revolves around typical B to B to C scenarios.

Body: With the continuous development of the blockchain industry, we find ourselves in an era of multi-chain interconnection. In this era, different public chains with distinct characteristics have given rise to diversified application scenarios, creating varied experiences for users. However, simultaneously, the isolation between chains has become more pronounced. Often, accounts on different chains cannot communicate, and users’ assets across chains remain in a fragmented and non-unified state. This increases the usage threshold and significantly diminishes the user experience.

It can be said that the problem of fragmentation and incompatibility between heterogeneous chains is one of the main obstacles to increasing user conversion rates. The popularity of the BTC ecosystem today further highlights the interoperability issues between heterogeneous chains. As Vitalik Buterin stated many years ago, “Multichain is the future.” Although the coexistence of multiple chains has become an unstoppable trend, establishing cross-chain bridges between heterogeneous chains remains a challenging task.

To address the issue of omnichain interoperability, LayerZero, Polyhedra, Map Protocol, Bool Network, and even Cosmos and Polkadot have proposed different solutions for cross-chain messaging. Recently launched ZetaChain, which introduced its token, is an essential player in the landscape of omnichain infrastructure.

Below, we will provide a brief technical perspective on ZetaChain’s omnichain solution, explaining how it serves as the underlying infrastructure for omnichain interoperable DApps, achieving cross-chain message parsing and processing.

Challenges with Existing Cross-chain Solutions

In reality, the simplest scenario that a cross-chain bridge needs to address is the transfer of assets across different chains. For example, when transferring assets from ETH to Polygon, you need to first transfer assets to a designated deposit address on the ETH chain and then receive an equivalent amount on the Polygon chain. The challenge arises because Polygon nodes cannot confirm what happened on the ETH chain and do not know if you indeed deposited the specified amount. If someone falsely claims to have deposited 100 USDT into the designated ETH address and initiates a withdrawal claim on the Polygon chain to release their 100 USDT, it leads to the “withdrawal out of thin air” problem. The key to a cross-chain bridge is to solve such a problem by confirming that all withdrawal claims correspond to actual deposit activities. Essentially, it involves proving on Chain B that there were indeed N transactions related to the cross-chain bridge on Chain A.

Currently, mainstream cross-chain bridges tend to adopt a notary mechanism, which involves setting up a group of notary nodes that reach “consensus” through multi-signature or MPC signatures. As long as the majority of notary nodes agree that your cross-chain action can be approved, your assets can smoothly cross. Some cross-chain bridges use a more secure hash-lock or implement light nodes of other chains through on-chain contracts. These bridges confirm the validity of cross-chain activities by receiving merkle proofs or zk proofs. However, the cost of such cross-chain bridges is often higher and is eventually transferred to users’ transaction fees. Therefore, most cross-chain bridges still choose the off-chain notary node model for multi-signature consensus. Reference: Explaining What Considerations Are Important When Designing Cross-Chain Bridges? Notably, notary-based cross-chain bridges often face significant risks, including vulnerability to hacking or insider theft. According to statistics from SlowMist Hacked, there were 16 security incidents involving cross-chain bridges in 2022, resulting in a total loss of $1.21 billion. This accounted for 32% of the total losses from on-chain attack incidents that year, highlighting the dangers of security vulnerabilities in cross-chain bridges.

Additionally, many existing cross-chain bridge solutions mostly adopt the Lock-Mint model, where assets are locked on Chain A and corresponding mapped assets are issued on Chain B to achieve cross-chain asset transfer. However, the processing flow of deposit and withdrawal in such solutions requires multiple interactions with the mapped asset contract, leading to significant friction and potential loss of funds. Additionally, numerous cross-chain bridge solutions only support asset transfers between EVM-compatible chains, facing challenges in cross-chain interactions between heterogeneous chains such as Solana and Bitcoin due to differences in technical standards. Considering security and fee-related issues, mainstream cross-chain bridge solutions often struggle to achieve optimal results and cannot ensure the “native cross-chain” transfer of assets. In today’s Bitcoin ecosystem, there is a growing desire for a seamless and native cross-chain interaction experience, anticipating a more efficient solution. ZetaChain addresses this challenge with its unique approach.

ZetaChain’s Functionalities: The Underlying Infrastructure for Cross-chain Interoperable DAPPs

ZetaChain positions itself as the foundational infrastructure for omnichain interoperable DApps, specializing in supporting various application protocols for cross-chain interactions—an exemplar of B To B To C underlying infrastructure. It employs a PoS admission mechanism, allowing nodes staking assets to enter the network and serve as notaries. All PoS nodes, utilizing TSS technology, participate in the verification and processing of cross-chain messages, aiming to enhance security as much as possible. Simultaneously, ZetaChain facilitates the deployment of smart contracts, incorporating business logic related to asset swaps. Users can send messages in a specific format on any chain, calling ZetaChain or its supported DeFi contracts on multiple chains. For instance, on BTC, users can indirectly call DeFi functionalities on Polygon. The outcome is the facilitation of message transmission between different blockchains, achieving interoperability.

DApps based on the scenario of omnichain interoperability can deploy asset exchange business logic on ZetaChain, facilitating automatic conversion of gas tokens across different chains for users. For example, using the frontend of certain omnichain DApps, you can issue a specific format message on BTC, similar to the Ordinals protocol, indicating a call to a contract on Solana. ZetaChain nodes will detect this message, and subsequently, the AMM contract on ZetaChain can automatically calculate the exchange ratio between BTC and SOL. It then releases an equivalent amount of SOL on the Solana chain, completing subsequent steps such as calling contracts and, finally, transferring the deserved assets back to your BTC or Solana address. This process is referred to as “omnichain interoperability,” where you only need to publish a message on one chain to remotely call DApps on multiple chains. In this context, ZetaChain can be conceptualized as a “chain-of-chains settlement layer.” In all multi-chain interaction scenarios, such as initiating a call from Chain A to a DApp on Chain B, it is akin to Chain A settling with ZetaChain first. ZetaChain then synchronizes the preprocessed settlement results to the corresponding account on Chain B, completing subsequent steps. Throughout this process, there is no excessive interaction with mapping asset contracts or friction in transaction fees. Asset circulation is facilitated by ZetaChain’s public accounts across different chains, eliminating the need for frequent deployment of mapping asset contracts on various chains, as seen in traditional cross-chain applications.

Currently, it appears that omnichain applications based on ZetaChain can save a considerable amount of trouble, eliminating the need to painstakingly design mapping asset contracts on different chains. All details regarding asset inflow and outflow between source and target chains are handled by ZetaChain. In other words, you only need to deploy business logic related to cross-chain transactions on ZetaChain. This facilitates different full-chain applications to support non-EVM chains like Solana, Algorand, Bitcoin, and DogeCoin in the frontend without the need to extensively implement dedicated cross-chain application contracts on different chains. Additionally, ZetaChain itself supports the deployment of asset contracts or AA (Autonomous Asset) accounts. Users on different chains can send messages in a specific format to call these contracts, as if operating a unified account across chains. This design approach, also reflected in Particle Network’s Particle Chain, ultimately allows users to centralize data records of their assets on ZetaChain or Particle Chain. When necessary, users can asynchronously call their asset contracts on ZetaChain by sending invocation messages through the frontend of DApps on “external chains.” Subsequently, ZetaChain, via the public account on the external chain, transfers a certain amount of assets to the address specified by the user or interacts with the DeFi protocol specified by the user.

This series of operations requires specialized frontend DApps to implement. In other words, ZetaChain itself only provides services as the underlying infrastructure for the omnichain, and there needs to be a dedicated frontend entrance at the application end to generate messages in a specific format.

ZetaChain’s Security Model: A Large Notary Node Network Based on POS Staking

Ultimately, ZetaChain is essentially a network of validator nodes designed for cross-chain message processing. Built on the Cosmos SDK, it comprises numerous validator nodes and utilizes POS as an admission mechanism, thereby achieving resistance against Sybil attacks and ensuring underlying security.

Within the ZetaChain network, Validator nodes, serving as decentralized notaries, confirm which pending cross-chain requests have been triggered on other chains. Through consensus, they record these cross-chain behaviors and proceed with subsequent steps. Using TSS distributed key signatures, ZetaChain can generate transaction instructions on other chains. It can be said that what Validators do bears some resemblance to the notary mode of cross-chain bridges, but with POS staking, Validator nodes are more trustless, addressing the Sybil problem.

(The current list of Zetachain’s validator nodes includes many project parties or institutions) Zetachian’s Validator client includes two modules, ZetaCore and ZetaClient. The ZetaCore module participates in the generation of ZetaChain blocks and the consensus process, while the ZetaClient module observes events on external chains and signs outbound transactions. Here, “outbound” can be simply understood as recording the transaction log on ZetaChain and sending it to “external chains” (referring to chains outside ZetaChain). This triggers corresponding actions on the target chain, with the content primarily including the contract address, chain ID, and message content declared by the user in the message, similar to the Log section in Ethereum transactions.

Conversely, “inbound” can be understood as recording relevant messages/transactions on external chains outside ZetaChain, such as cross-chain requests, calling smart contracts on zEVM, etc., onto ZetaChain. It’s important to note that when running Validator nodes for ZetaChain, the client code includes three modules: Validator, Observer, and TSS Signer. These three modules have different functionalities but all belong to the ZetaChain client.

Observer and TSS Signer Modules

Firstly, all ZetaChain nodes have a “validator” module, with functionalities similar to Validator nodes in PoS public chains, participating in block generation and consensus processes. Additionally, nodes can vote on on-chain proposals based on the staked tokens (ZETA) ratio. ZetaChain’s blocks contain all processed cross-chain records and interactions with omnichain smart contracts, acting as a log.

The “observer” module in the ZetaChain client runs other public chain full nodes/light nodes, monitoring specific formats of cross-chain transactions/messages. The Observer module operates in two modes: active and passive. Different ZetaChain nodes can choose to switch the Observer module to one of these modes. The Observer module continuously monitors whether there are ZetaChain-related cross-chain messages/events on other chains. If so, the Observer module of the ZetaChain node reports the situation to the Validator module. These observed cross-chain messages are then submitted to ZetaChain’s block and confirmed collectively through consensus.

There are two modes of observation: active and passive mode. In active mode, nodes continuously scan transactions/events/states on other blockchains outside ZetaChain by running full nodes of those chains. In passive mode, nodes do not synchronize complete blocks from other blockchains; instead, they passively receive parsed cross-chain messages from other ZetaChain nodes. 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-chain messages/transaction data really exist on the external chain.

The advantage of active mode is that most ZetaChain nodes synchronize data from external chains, providing strong resistance to censorship. In this mode, any user interaction with ZetaChain can occur once a node detects a request initiated on an external chain. However, in active mode, running nodes comes with higher costs. Besides running the ZetaChain node client, nodes also need to run full nodes of external chains, synchronizing data and conducting scans continuously. On the other hand, passive mode offers significantly lower operating costs for regular observer nodes. Only specific nodes run the full node client of external chains, while other nodes run lightweight clients without synchronizing complete external chain blocks. This results in lower costs and easier scalability of the node count in passive mode, facilitating integration with multiple external chains. However, the drawback of passive mode is that the observation activity of data on external chains depends on a few nodes, leading to weaker resistance to censorship. To alleviate this situation, ZetaChain incentivizes nodes to run the active mode of the Observer module.

(In active mode, nodes need to run the full node client of external chains. In passive mode, only lightweight clients of external chains are run, receiving cross-chain messages and Merkle proofs from ZetaChain nodes in active mode to confirm the validity of the messages)

TSS signature

All cross-chain messages observed and verified by ZetaChain nodes will ultimately trigger a transaction on the target chain through ZetaChain’s public account address, leading to subsequent operations. In this process, generating a digital signature for this cross-chain transaction on the target chain is required. To ensure security and trustlessness, the signature generation is undertaken by all ZetaChain nodes, collectively storing key fragments for signature generation. These key fragments are distributed among multiple signers, and only when the majority of signers provide their signatures can the digital signature for the transaction be generated on the external chain. At any given time, a single entity or a small subset of nodes cannot represent ZetaChain in triggering transactions or signing messages on external chains.

In ZetaChain’s cross-chain model, it is only necessary to have a common account address on different chains without the need to deploy complex smart contracts. ZetaChain’s multi-signature algorithm employs TSS, the Threshold Signature Scheme. While externally visible transaction digital signatures correspond to a single private key, public key, and address, in reality, this private key is generated by many fragments distributed across all ZetaChain node devices, generated without the involvement of intermediaries. At any given time, a single entity or a few validators cannot represent the entire network to piece together private key fragments and sign messages. The key generation and signing process of TSS is accomplished through Multi-Party Computation (MPC), ensuring that no secrets of participating nodes are leaked. ZetaChain nodes can generate transaction signatures on different chains. In addition to being compatible with various EVM chains, ZetaChain adds the capability to remotely call smart contracts for Bitcoin or non-smart contract chains. The user experience is analogous to Bitcoin users directly calling certain DeFi functionalities.

This scenario is particularly suitable for hosting multi-chain DeFi applications within the BTC ecosystem. As BTC blockchain cannot implement overly complex business logic, it relies on external infrastructure for remotely calling certain DeFi contracts. The features of ZetaChain are well-suited for users within the BTC ecosystem to asynchronously call DeFi contracts.

zEVM: One-stop Cross-chain DAPP Contract Platform

Unlike traditional cross-chain solutions that require deploying mapping asset contracts on each chain, ZetaChain achieves cross-chain functionality by deploying a smart contract only once on its own chain. In ZetaChain, there is an EVM-compatible execution layer called zEVM, where cross-chain smart contracts can be directly deployed. zEVM supports the following features: 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 state on 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. Additionally, omnichain application DAPP does not need to deploy mapping asset contracts on different chains. It only needs to use the contract on the ZetaChain chain to centrally set up cross-chain message processing logic in one stop, without the need to frequently deploy cross-chain contracts into a multi-chain network. This can significantly save the development cost of full-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 gives it unified asset management (status recording) platform capabilities. Because we no longer need to work hard to own assets on multiple chains, this scenario of unified asset accounts across the chain can generate more potential in the future.

Conclusion

From what we have discussed in this article, we have gained a better understanding of ZetaChain’s “omnichain interoperability infrastructure.” Through the observer module in the validator client, ZetaChain monitors specific messages/transactions on external chains, reports them to the validator module, achieves consensus on messages within the ZetaChain network, parses the data contained in the messages, generates digital signatures using TSS, and triggers subsequent transaction processes on the corresponding target chains, thereby realizing cross-chain interactions across the entire network. Simultaneously, the omnichain smart contracts based on ZetaChain enable us to interact closely with different blockchains without the need to use mapping asset contracts on different chains. This eliminates the calling of redundant contract logic, saving transaction costs. Additionally, as ZetaChain is EVM-compatible, any DApp developer or even individual users can deploy customized cross-chain message processing logic. In theory, one can deploy the entire DApp contract in a one-stop manner. Cross-chain application developers do not need to frequently deploy/update mapping asset contract logic on different chains, eliminating the cost of redundant development.

Disclaimer：

1. This article is reprinted from [极客 Web3], All copyrights belong to the original author [Howe & Faust, 极客web3]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.