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 capabilities to facilitate lightweight data transmission between different networks;
Manage external assets: ZetaChain extends its capabilities 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 its support for 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 Layer1. 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, like other PoS chains, they inject capital into ZETA and vote for blocks;
● Observers: Observers divide the complete nodes that need to run the external chain into sequencers and validators, sort and supervise the events on the external chain and send them to the verifiers, who vote on the events and reach a 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. One example in the white paper - cross-chain DEX - is a visual representation of ZETA's role in messaging. In this example, say the user wants to exchange 1.2 ETH on Polygon for USDC on Ethereum. The path is as follows:
Swap ETH for 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, with intent protocols such as Squid and UniswapX and Circle’s CCTP occupying 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 deploying 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. None of the above competitors have such a product except Axelar, which uses CosmWasm instead of EVM and has not seen any adoption so far.
ZetaChain’s full-chain smart contracts are supported by the TSS protocol, and its validators run full nodes on external chains and share signatures, so they can safeguard assets on behalf of ZetaChain and its users, which zEVM can manipulate as they see fit. 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;
Currency markets supporting 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, with key network activities relying 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, which facilitates user transactions and pays 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 Economics and Issuance
The initial total supply of ZETA tokens is 2.1 billion, with a planned inflation rate of approximately 2.5% per year after four years. 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%): Encourages liquidity in the core ZRC-20 pool, which is critical for efficient value transfer;
Protocol Base (24%): Provides funding for operations, development, and ecosystem enhancement;
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 a core assumption of Zeta's cross-chain application (position management will be located in 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 having to manually connect 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:
Inter-chain interaction;
Can be managed holistically rather than 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
Source: LayerZero official website
In the cross-chain delivery 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 (providing 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 and sends/receives information to LayerZero endpoints (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 based on 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 a repeater, but obtains proofs instead of header blocks. While the application itself can also become a repeater, the reality is 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
Axelar's structure is more similar to Zeta's than to LayerZero's, but there are significant 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 requests: 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 relay: The relay listens for events (gateway information) and submits them to the Axelar network for processing. While anyone can run a relay, there is no incentive 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. Axelar validators in turn 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 for 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 (sending it to the desired application ). 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
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 adds another entity: the Risk Management Network.
CCIP is divided into two parts: on-chain and off-chain.
upper part of 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;
Commit Storage: Commit DON stores 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 root of a submitted DON. 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, CCIP will freeze;
Enforcement DON: Similar to commitments, but polices information like a risk management network. Once the RMN issues "verified", the executing DON calls 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 LayerZero, Axelar, Chainlink CCIP and other technologies.
Reference article:
1. Future opportunities for full-chain applications https://members.delphidigital.io/reports/zetachain-part-2-the-opportunity-ahead-for-omnichain-applications#consumer-aggregation-apps--improving-the-on -chain-derivatives-experience-56d5
2. What is ZetaChain?
https://www.datawallet.com/crypto/what-is-zetachain
3. Competitive landscape of blockchain bridges https://members.delphidigital.io/reports/zetachain-part-1-a-competitive-landscape-of-blockchain-bridges#architecture-ed17
Extension link:
(1)Zera Token Distribution
https://www.zetachain.com/docs/about/token-utility/distribution/
(2) MUX Aggregator White Paper
https://docs.mux.network/protocol/overview/leveraged-trading-aggregator
(3) LayerZero support contract https://layerzero.gitbook.io/docs/technical-reference/mainnet/supported-chain-ids