ZetaChain: Multi-chain and cross-chain communication usher in a new competitive landscape

Original author: YBB Capital Researcher Ac-Core

ZetaChain (ZETA) is a first-layer blockchain designed to bridge the gap between various blockchain networks, leveraging the Cosmos SDK and Tendermint consensus mechanism to enable developers to custom build scalable interoperable applications. The platform enables decentralized applications (DApps) to use the functions of multiple blockchains to solve the problems existing in current cross-chain protocols and realize full-chain cross-chain functions. It uses Omnichain smart contracts and ZetaEVM engines to promote interoperability. , making ZetaChain an integration hub.

How ZetaChain works

Source: ZetaChain official website

ZetaChain uses the Cosmos SDK, based on the Tendermint consensus engine and the Proof of Stake (PoS) model, to demonstrate the unique ability of full-chain interoperability, and uses its own tokens as Gas fees, which has the advantage of expanding the full-chain EVM smart contract. According to Jed Barker, ZetaChain works as follows:

OmniChain smart contract: The core of ZetaChain is a smart contract that can be connected to multiple blockchains. These smart contracts are powered by the ZetaEVM engine that is compatible with the Ethereum Virtual Machine, enabling data interaction across different blockchains;
Seamless asset transfer: Simplify asset transfer between blockchains without complex bridging. This includes support for blockchains without native smart contract functionality, such as Bitcoin;
Cross-chain messaging: For simpler data exchanges (such as NFT transmission), ZetaChain provides cross-chain messaging functions to facilitate lightweight data transmission between different networks;
Manage external assets: ZetaChain extends its functionality to manage assets on other blockchains, applying smart contract logic to chains that typically lack this functionality.

ZetaChain Architecture:

Zeta, like other architectures, can provide many cross-chain messaging functions, but its unique advantage is that it supports full-chain EVM contracts, that is, "THORChain with smart contracts" or "Axelar with EVM". It uses the Cosmos SDK and CometBFT consensus to build a PoS blockchain. Like THORChain, Zeta uses the ZETA token as a routing token for cross-chain messaging.

The following is an explanation. ZetaCore is the client that generates blocks and runs Layer 1. Similar to other PoS blockchains, ZetaClient is responsible for cross-chain operations. Other nodes need to run ZetaCore and ZetaClient at the same time. Zeta nodes perform three key functions: verification, observation, and signing, with three distinct roles each node operation is responsible for. This architecture enables two key functions: Omnichain smart contracts and cross-chain messaging.

Image source: Delphi Creative

Validators: Standard CometBFT validators, they, like other PoS chains, inject capital into ZETA and vote for blocks;
Observers: Observers divide the complete nodes that need to run the external chain into sequencers and verifiers, sort and supervise events on the external chain and send them to the verifiers, who vote on the events and reach consensus. . The role of the sequencer is only to ensure validity, and any node can sequence transactions. This makes running a Zeta node more expensive than running a standard chain, similar to THORChain, which is one of the reasons why THORChain did not add Solana support;
Signers: ECDSA/EdDSA keys are shared between nodes, and only a super majority (2/3) can sign transactions on the external chain. Signers are Zeta's way of keeping assets and signing information on external chains. On smart contract platforms such as Ethereum, they can be used to interact with smart contracts and managed assets, and can also be used to host assets on non-smart contract chains such as Bitcoin and Dogecoin. The picture below is the signing diagram in the white paper.

Image source: Delphi Creative

Cross-chain information transfer

CCMP routes information between other chains by using ZetaChain in the middle. Other protocols such as LayerZero, Axelar, IBC, Chainlink CCIP, and THORChain to a certain extent are all competing in this direction. But for ZetaChain, their cross-chain message transfer protocol is implemented by using the native token ZETA, which is fundamentally different from their competitors, because except for THORChain, other competitors do not rely on their native tokens. Make a value transfer. An example in the white paper - cross-chain DEX - is a visual representation of ZETA's role in messaging. In this example, let's say the user wants to exchange 1.2 ETH on Polygon for USDC on Ethereum. The path is as follows:

Change ETH to ZETA on Polygon AMM;
ZETA is sent to ZetaChain;
ZETA is routed from ZetaChain to Ethereum;
Exchange ZETA for USDC on Ethereum;
User receives Ethereum USDC.

Image source: Delphi Creative

Although the logic is feasible, this solution requires a lot of money. This has resulted in a loss of product competitiveness to a certain extent. For example, intention protocols such as Squid and UniswapX and Circle's CCTP have occupied a large market share as settlement rails. In addition to capital efficiency, cross-chain messaging is also a highly competitive area.

Full chain smart contract

There are many advantages for developers to deploy full-chain smart contracts on Zeta, rather than just using Zeta and zEVM to facilitate transactions. First, it allows interaction with assets such as BTC, DOGE, and LTC that do not natively support smart contracts. Secondly, because the application state is located on Zeta, it also reduces the attack surface of the vulnerability to a certain extent, and does not rely on the liquidity of ZETA tokens for value transfer. Except for Axelar, none of the above-mentioned competitors currently lacks such products. Axelar uses CosmWasm instead of EVM and has not received any adoption so far.

ZetaChain's full-chain smart contract is supported by the TSS protocol, and its validators run full nodes on the external chain and share signatures, so they can custody assets on behalf of ZetaChain and its users, and zEVM can manipulate these assets as they wish. It should be noted that in the process, for example, BTC is not actually transferred from Bitcoin to Zeta, but is transferred to the address hosted by the Zeta validator and then reflected on ZetaChain. For example, THORChain adds smart contracts to the BTC hosted by the protocol.

Image source: Delphi Creative

Under this architecture, Zeta can build many special protocols, just for example:

A full-chain CDP stablecoin backed by BTC;
Support currency markets for BTC, DOGE, LTC and other non-smart contract assets;
Full chain Perp DEX; *Full-chain Yield aggregator; *BTC AMMs.

Essentially, what sets ZetaChain's zEVM combined with ZetaClient apart is the custody and control of assets on a non-smart contract chain. Today's cross-chain platforms are mostly used as back-end infrastructure, but ZetaChain can create its own crypto economy on ZetaChain.

Practicality of ZETA Token

ZETA is the cornerstone of the ZetaChain ecosystem and plays a pivotal role in functional programmability and governance. ZetaChain stands out for its interoperability and support for full-chain dApps, and its key network activities rely on ZETA.

Overview of the main functions of the ZETA Token

Network Incentives: ZETA tokens provide incentives for validators through block rewards, transitioning from a fixed pool to variable inflation. This system aligns the interests of validators with the long-term security of the network;
Transaction fees: Transactions within ZetaChain require ZETA to pay Gas fees, which will be distributed to validators and network participants. This mechanism prevents spam and DDoS attacks;
Cross-chain information transfer and value transfer: For cross-chain transactions, ZETA is burned on the source chain and minted on the destination chain, without creating new packaging assets;
Core liquidity pool: ZetaChain's liquidity pool is composed of ZETA and other assets, providing convenience for user transactions and paying transaction fees and rewards to liquidity providers;
Management role: ZETA holders participate in network management, influence key decisions and policy changes, and ensure that the development of the network is community-led.

Overall, ZETA’s multifaceted utility supports ZetaChain’s security, efficiency, and decentralized governance, making it an essential part of the network’s functionality.

ZETA Token Economy and Issuance

The initial total supply of ZETA tokens is 2.1 billion, and the planned inflation rate after four years is approximately 2.5% per year. Token distribution (see reference link 1) will be strategically allocated to various parts of the ecosystem:

User growth pool (10%): The goal is to expand the user base through measures such as airdrops and community rewards;
Ecosystem Growth Fund (12%): Supports ecosystem development and helps partners and dApp developers;
Validator Rewards (10%): For block rewards, transition to inflation-based network security rewards after the initial period;
Liquidity Incentive (5.5%): Encourage liquidity in the core ZRC-20 capital pool, which is crucial for effective value transfer;
Protocol Library (24%): Provides funds for operations, development and ecosystem strengthening;
Core Contributors, Advisors and Buyers (22.5% and 16%): Reward for contributions to the development and growth of ZetaChain.

Full chain DEX

Unlike the current situation of cross-chain deployments, ZetaChain, as the base layer of the protocol, can achieve liquidity interoperability between all different deployments. For example, users on ZetaChain can deposit their margin into the hub contract and hold positions on GMX. This is the core assumption of Zeta's cross-chain application (position management will be located on Zeta), to the extent that users who want to take advantage of the full liquidity of GMX must use ZetaChain.

In addition to ensuring execution quality, there are two key advantages:

Similar to the MUX aggregator (see reference link 2), asset orders can be split between various liquidity sources;
Access more trading pairs without manually connecting all relevant chains.

Smart contracts on ZetaChain can directly deposit the required posting margin amount into the relevant chain, along with information on how to use these assets. Although this process is not technically possible without ZetaChain, it can improve the user experience:

Interaction between chains;
Can be managed holistically, not individually.

UniSwap, the leader in the DEX market, will move its base center from Ethereum to any other chain, but in theory by being deployed on ZetaChain and using the ZRC-20 standard, users can swap in and out of any asset (on any chain) ) and host said assets on any chain they wish.

Competitors of Zeta Chain

LayerZero

Image source: LayerZero official website

In the cross-chain transfer market, LayerZero is ZetaChain's biggest competitor. Although they do not participate in the competition in the field of full-chain smart contracts, their market position in cross-chain delivery is very solid. The main advantage comes from Strargate, followed by the push to adopt its OFT standard (which provides a new solution for cross-chain token transfers, making it easier and more efficient to transfer tokens between different chains).

LayerZero Architecture

First, a quick introduction, LayerZero is a protocol that allows "user applications" to send information between blockchains. The architecture consists of 4 main parts:

User application: a contract that interacts with the LayerZero endpoint and sends/receives information to it (such as Strargate);
LayerZero Endpoints: A series of smart contracts on different chains (currently supporting more than 40+, see reference link 3 for details). Endpoints allow user protocols to send information through the LayerZero backend, which consists of 4 modules: Communicator, Validator, Network and Library. The first three modules are standardized across all chains, while the library is customized according to different chain logic, allowing LayerZero to quickly add more chains;
Oracle: The party responsible for reading the header block from one chain and sending it to another chain. This role currently falls to Chainlink by default, but as of September 2023, a new partnership with Google Cloud has replaced Chainlink as the default role;
Relayer: Similar to the relayer, but obtains the proof instead of the header block. Although the application itself can also become a repeater, it is actually handled by LayerZero.

This design basically boils down to 2/2 multisig, where the main trust assumption is that Google Cloud and LayerZero are not colluding. The benefits of relying on these off-chain components (such as oracles and relayers) are that the architecture is lightweight, cheap and Easily scalable, the disadvantage is that it relies on two centralized entities and may be susceptible to censorship-related risks.

Shoulders

Source: Axelar official website

Compared with LayerZero, Axelar's structure is more similar to Zeta, but there are also obvious differences. Like ZetaChain, Axelar is also developed based on the Cosmos SDK. The difference is that it does not directly host the EVM, so it does not support the same full-chain smart contracts as Zeta. So Axelar's target market is cross-chain messaging, similar to LayerZero.

Axelar Architecture

Axelar is a PoS chain with its own validator set and pledge Token AXL. Its components and information flow are as follows:

Cross-chain GMP request: API that allows applications to send arbitrary data across chains. These message requests are sent to the Axelar gateway (an online platform or digital system that uses blockchain technology to enable the transfer of digital currency from one address to another);
Gateway: The place where cross-chain messages initiated by users/applications first pass through in order to be routed from the source link to the destination chain. For the EVM chain, these are smart contracts, and for Cosmos, these are application logic. The gateway is secured by Axelar validators using MPC, with shares weighed by AXL token delegation;
Message processing and repeater: The repeater listens for events (gateway information) and submits them to the Axelar network for processing. While anyone can run a relay, there are no incentives and the relay is operated by Axelar;
Message validation: Validators vote on messages received from relayers. Each Axelar validator runs a full node for each source chain and is therefore able to verify the validity of messages. In turn, Axelar validators require more resources than a typical Cosmos PoS blockchain, where validators rely on light clients and IBC to deliver messages. In a sense, this model is less scalable than LayerZero, but more decentralized. Axelar incentivizes validators by issuing them with more stakes, the more chains they support, the bigger the rewards. In the long term, supported chains will need to generate sufficient fees from cross-chain activity as token rewards for supporting validators running more than 50 full nodes will be exhausted. It may not be feasible to support every chain, instead they will be clustered around the main flow chain;
Submit information to the destination: The relay listens to the authorization information sent by the Axelar validator and pushes it to the target chain gateway. When a target link receives approved information, its payload is marked as approved by the Axelar validator. Now anyone can execute the payload;
Gas and executor services: In the final step, Axelar deploys a contract named "Gas Receiver" on the EVM chain to pay the Gas fee of the destination chain and execute the cross-chain payload (send it to the required application program). Users can pay with the source chain's Gas tokens, and Axelar extracts the Gas of the target chain.

Overall, its structure is similar to ZetaChain, except for supporting EVM on its own chain. In terms of security, Delphi Research believes that it is more secure than LayerZero's 2/2 model. Although there are still some shortcomings, the chance of collusion between Google and LayerZero is extremely low (applications can run their own repeaters).

Chainlink CCIP

Image source: Chainlink official

CCIP is not much different from other cross-chain information platforms. Users send information on a chain, the information is forwarded to CCIP, and then CCIP forwards the information to the destination chain. What makes CCIP different is how it uses Oracle Networks and incorporates another entity: the Risk Management Network.

CCIP is divided into two parts: on-chain and off-chain:

The upper part of the chain

Router: Start cross-chain transactions. Route the transaction to the destination-specific OnRamp contract, receive information from OffRamp on the destination chain, and route to the end user/contract;
Submit storage: Submit DON to store the Merkle root on the source chain to the target chain. Merkel must be "certified" by the risk management network;
OnRamp: One contract per chain (blockchain to blockchain). Verify information and track things like token transfers/information, manage billing, etc. Publishing is monitored by Committing DON;
OffRamp: Similar to OnRamp, one contract per chain. Ensure the authenticity of the information by verifying the execution of DON and the submitted and "verified" Merkle Root, and transmit the information to the router;
Token Pool: Tokens can be "locked and minted" or "burned and minted" depending on the token. For example, local Gas tokens must be locked and minted, because CCIP does not have minting rights. If CCTP is integrated, USDC can be "fired and minted";
Risk Management Network Contract: Contains a list of risk management network nodes that can "pass" (approval) or "fail" (disapprove) transactions.

Off-chain part

Submit DON: As above, you need to submit DON to monitor the events of the OnRamp contract, then wait for the source chain result and create the Merkle Root (signed by the legal submission DON oracle node), and finally write it to the CommitStore contract on the target chain;
Risk Management Network: A network of nodes that essentially double-checks the Merkle roots of submitted DONs. They monitor the OnRamp contract and what the commit DON publishes in the commit store. If the RMN does not "verify" (i.e. verify/confirm) the Merkle Root, the CCIP will be frozen;
Execution DON: Similar to a commitment, but regulates information like a risk management network. Once the RMN issues a "verification pass", the execution DON will call the OffRamp contract to complete the CCIP TX for the destination.

Summary

In reality, in order to break the island effect between chains, the problems of "multi-chain communication" and "cross-chain communication" are the first to be solved. Compared with other solutions, the core advantage of the ZetaChain project lies in its cross-chain interoperability performance. Interoperability between different blockchains becomes possible, solving the current problems of blockchain fragmentation and insufficient interoperability. Designed to enable full-chain dApps to natively interact directly with different blockchains without wrapping or bridging any assets. Its external links also have security risks that may be attacked when ZetaChain connects external links, which may lead to double spends, censorship, regression, hard forks, chain splits, etc.

For now, LayerZero and Axelar are leading the way in applications in the field of cross-chain information. However, it is still early and no one can really lead. While looking forward to ZetaChain's new solutions, we also look forward to the continued iteration and innovation of technologies such as LayerZero, Axelar, and Chainlink CCIP.

Reference article: