Taking Zetachain as an example, understand how Omnichain achieves chain abstraction
TechFlow Selected TechFlow Selected
Taking Zetachain as an example, understand how Omnichain achieves chain abstraction
A cross-chain bridge is a relatively common solution, but Omnichain has taken a completely different path.
Navigating Web3 tides with focused insightsAuthor: CaptainZ, former Injective researcher
Omnichain abstracts cross-chain rules into smart contracts.
As the number of public chains and Layer2 networks increases, demand for cross-chain asset and dApp interoperability grows. Cross-chain bridges are a common solution, but Omnichain platforms like Zetachain take a completely different approach.
This article uses Zetachain as an example to explain how Omnichain embeds cross-chain rules into smart contracts to achieve decentralized cross-chain interoperability.
A. Several Cross-Chain Technical Approaches
The core goal of cross-chain technology is to enable interoperability between different blockchains. Interoperability means that distinct blockchain systems can understand and use each other's assets (such as tokens, cryptocurrencies) and data, or that applications running on different blockchain platforms can interact and collaborate. Achieving this goal greatly enhances the flexibility and scalability of the blockchain ecosystem, breaking down silos between different platforms and promoting broader application development.
Based on how cross-chain messages are processed and how asset signatures and authorizations are handled, several technical solutions can be distinguished:
1. Cross-Chain Bridges:
A cross-chain bridge enables assets to move from one blockchain to another by locking assets on the source chain and minting corresponding representative (or equivalent) assets on the target chain. This method supports cross-chain asset transfers and usage but requires secure and reliable mechanisms for locking and releasing assets. When two independent chains achieve interoperability via bridging, one chain is considered a sidechain relative to the mainchain.
2. Notary-Based Systems:
Notary schemes rely on a set of trusted nodes (or entities) to validate the validity of cross-chain transactions. These notaries monitor events on one chain and create corresponding transactions on another chain to verify and record those events. While this achieves cross-chain interoperability, its security and decentralization heavily depend on the trustworthiness of the notary nodes.
3. Hash Time-Lock Contracts (HTLCs):
HTLCs are smart contract-based protocols enabling secure peer-to-peer cross-chain exchanges without third parties. They work by creating a contract where funds can only be unlocked upon providing the correct preimage (secret). Funds are released only when both parties fulfill their obligations. This supports decentralized asset swaps but requires cooperation between participants.
4. BoB (Blockchain-on-Blockchain, e.g., Cosmos IBC):
This approach creates new blockchains (or layers) atop existing ones to enable cross-chain interoperability—such as Cosmos’s Inter-Blockchain Communication (IBC) protocol. IBC allows different blockchains to maintain independent governance while securely transferring assets and data. It aims to build a decentralized internet of blockchains capable of freely exchanging information and value.
Each of these approaches has advantages and limitations, making them suitable for different scenarios. Choosing and implementing a cross-chain solution must consider characteristics of the target blockchains, security requirements, degree of decentralization, and implementation complexity.
B. Cross-Chain Message Passing
Cross-Chain Message Passing (CCMP) is the core technology enabling cross-chain interoperability, ensuring that cross-chain interactions proceed securely and efficiently. Its primary purpose is to transmit and verify messages across different blockchains to enable cross-chain exchange of assets and data. The process involves several key steps:
1. Message Generation and Sending:
- Messages typically contain all necessary details about an asset transfer, such as amount, source address, destination address, etc.
- After generation, the message is sent via a smart contract on the source chain, which records transaction details and triggers asset locking.
2. Message Transmission:
- There are generally two transmission methods: direct and relayed.
- Direct transmission implies a direct communication path between source and target chains, but this is rare in practice due to the independent operation of most blockchains.
- Relayed transmission involves relayers—either centralized services or decentralized node networks—that monitor specific events on the source chain, capture relevant data, and forward it to the target chain.
3. Message Verification:
- On the target chain, received messages must be verified for legitimacy and integrity.
- Verification usually requires cryptographic proofs from the source chain (e.g., Merkle proofs), confirming the message originated from the source chain and hasn't been tampered with.
- Once validated, the target chain’s smart contract executes actions based on the message content, such as minting tokens or updating state.
4. Processing and Response:
- After verification, the target chain performs required operations—such as releasing assets or creating new token instances.
- Upon completion, the cross-chain interaction is essentially finished, allowing users to manage or use their assets on the target chain. Thus, the previously mentioned cross-chain solutions differ fundamentally in their message-passing approaches.
1. Cross-Chain Bridges
Cross-chain bridges create an intermediary layer to facilitate the transfer of assets and information between different blockchains. This layer can be: - A centralized server controlled by a trusted entity, responsible for monitoring events on one chain and replicating them on another.
- A decentralized network composed of independently operated nodes that validate and forward messages through consensus mechanisms.
In cross-chain bridges, assets are typically locked on the source chain and mirrored assets are minted on the target chain. This process must ensure messages cannot be altered before validation and execution.
2. Notaries
Notary schemes typically rely on a predefined group of notaries (individuals, organizations, or automated nodes) responsible for monitoring events on one chain and verifying and confirming them on another. Notaries provide a centralized or semi-centralized validation mechanism whose security and trust level depend heavily on the credibility of the notaries themselves.
3. Hash Time-Lock Contracts (HTLC)
HTLC is a cryptographic contract enabling conditional asset swaps between two chains. It uses hash functions and time locks to control release conditions:
- Hash lock: Assets can only be released if the recipient provides the correct preimage (original data corresponding to the hash).
- Time lock: If the correct preimage isn’t provided within a specified time, assets are returned to the original holder.
This method does not rely on centralized validators; instead, the contract itself ensures secure asset exchange.
4. BoB
This approach builds new chains or sub-chains using a cross-chain communication protocol. For example, Cosmos uses the IBC protocol to enable direct communication between blockchains. Each chain maintains autonomy while securely exchanging messages and assets. IBC and XCMP are essentially cross-chain communication protocols.
However, CCMP faces several major challenges:
Security: Relayer nodes or networks must be trustworthy; otherwise, there's a risk of message tampering. Additionally, smart contracts on both source and target chains must be designed securely to prevent vulnerabilities.
Efficiency and Latency: Cross-chain operations often require multiple block confirmations, leading to significant delays.
Decentralization and Trust Issues: Relying on relayer nodes or third-party services may contradict blockchain’s decentralized ethos. Designing a decentralized yet secure CCMP mechanism remains a technical challenge.
Due to these technical and security challenges, CCMP implementation and optimization remain active areas of research and development. Various solutions aim to strike the optimal balance between decentralization, security, and efficiency.
C. Cross-Chain Asset Signature and Authorization
Cross-chain technology and interoperability depend not only on cross-chain message passing (CCMP) but also on effective signature and authorization mechanisms on both source and target chains to ensure secure asset handling and transaction legitimacy. Different cross-chain solutions adopt varying signature and authorization models—each centered on verifying transaction validity and securing asset transfers. Below are common implementations across various approaches:
1. Cross-Chain Bridges
Cross-chain bridges may use multi-signature (multisig) or proxy signature methods for signing and authorization. In this model, asset transfer operations require authorization from a certain number of validator nodes or specific proxy services, which verify transaction requests and sign accordingly. This improves security but introduces trust issues due to reliance on centralized or semi-centralized entities.
2. Notaries
In notary systems, notaries or groups of notary nodes monitor and validate cross-chain transaction requests and execute corresponding operations on the target chain. Notaries must sign and authorize actions on the target chain to prove that transactions on the source chain were permitted. This approach relies heavily on the trustworthiness and security of the notaries.
3. Hash Time-Lock Contracts (HTLC)
In HTLCs, signature authorization does not rely on external validators or intermediaries. Instead, transaction validity and execution depend on contract logic and direct interaction between participants. Parties unlock the contract by providing the correct preimage (i.e., secret), which serves as authorization. Additionally, the contract includes a time-lock mechanism, ensuring the transaction completes only within a defined time window upon presenting the correct preimage.
4. BoB
For instance, in Cosmos’s IBC protocol, signature authorization occurs through inter-chain protocols and local contract execution. Each chain independently manages its own security and authorization mechanisms while relying on the protocol to ensure cross-chain message validity and security. This model emphasizes decentralization and autonomy, reducing dependence on single entities.
In summary, signature and authorization mechanisms vary across cross-chain solutions depending on architecture and security needs. The choice and design of these mechanisms hinge on balancing security, trust, decentralization, and efficiency. Ensuring legality and security across all participating chains is essential when implementing cross-chain technologies.
D. Zetachain Architecture
If DeFi encodes financial rules into smart contracts and on-chain games encode game rules into smart contracts, then Omnichain encodes cross-chain rules—including cross-chain message transmission and asset signature authorization—into smart contracts. Let’s dive deeper into how Zetachain accomplishes this.
ZetaChain is a PoS blockchain built using the Cosmos SDK and the Tendermint PBFT consensus engine. Thanks to Tendermint PBFT, ZetaChain achieves fast block times (~5 seconds) and instant finality (no need for block confirmations, no reorgs allowed). Under ideal network conditions, it can handle over 4,000 transactions per second, though cross-chain transaction throughput may fall short due to external chain latency and other factors (e.g., RPC speed of external nodes).
ZetaChain’s architecture consists of a distributed network of nodes known as validators. Each ZetaChain validator runs two components: ZetaCore and ZetaClient. ZetaCore generates the blockchain and maintains replicated state machines, while ZetaClient monitors events on external chains and signs outgoing transactions. Both components are bundled together and run by node operators. Anyone who stakes sufficient ZETA tokens can become a node operator and participate in validation.
Thus, if a ZetaChain validator runs only the ZetaCore component, it becomes a sequencer. If it runs only the ZetaClient component and solely observes events on external chains, it becomes an observer. If it runs only the ZetaClient component and focuses exclusively on signing outgoing transactions, it acts as a signer.
ZetaChain collectively holds standard ECDSA/EdDSA keys for authenticating interactions with external chains. These keys are distributed among multiple signers, and only a supermajority of signers can represent ZetaChain externally. ZetaChain employs bonded staking and positive/negative incentive mechanisms to ensure economic security.
E. Two Cross-Chain Interoperability Mechanisms in Zetachain
ZetaChain supports two cross-chain interoperability mechanisms: traditional cross-chain bridges and Omnichain smart contracts.
E.1 Cross-Chain Bridge Mechanism
Let’s examine the workflow of the cross-chain bridge mechanism, involving the following steps:
1. User interacts with contract: The user performs an action on contract C1 on Chain A, leaving behind an event or transaction memo containing [chainID, contractAddress, message]. This message contains binary-encoded application data.
2. Observer captures event: ZetaChain observers (in zetaclient) detect this event/memo and report it to zetacore, which validates the inbound transaction.
3. Construct outbound transaction: zetacore updates CCTX (cross-chain transaction) state variables and OutboundTxParams, instructing TSS signers (in zetaclient) to construct, sign, and broadcast external transactions.
4. Sign and broadcast: TSS signers in zetaclient build the outbound transaction based on OutboundTxParams in the CCTX, perform a TSS key signing ceremony, and broadcast the signed transaction to the external blockchain.
5. Update and track status: The CCTX structure tracks the various stages/states of the cross-chain transaction.
6. Transaction confirmation: Once the broadcast transaction is included (i.e., “mined” or “confirmed”) on the target blockchain, zetaclient reports this confirmation back to zetacore, which updates the CCTX state.
7. Handling success and failure:
- If the external transaction succeeds, the CCTX state changes to OutboundMined, marking completion and entering a terminal state.
- If the external transaction fails (e.g., reverted on Ethereum), the CCTX state updates to PendingRevert (if possible) or Aborted (if revert is impossible). If Aborted, processing ends.
8. Revert handling:
- If the new state is “PendingRevert,” the CCTX should already include a second OutboundTxParams, instructing zetaclients to create a “Revert” outbound transaction back to the inbound chain and contract, allowing the inbound contract to implement application-level cleanup logic.
- zetaclients build the revert transaction, conduct a TSS signing ceremony, and broadcast it back to the inbound blockchain (Chain A in this case).
9. Revert confirmation:
- Once the revert transaction is “confirmed” on Chain A, zetaclients report its status to zetacore.
- If successful, the CCTX state becomes Reverted, completing processing.
- If the revert transaction fails, the CCTX state becomes Aborted, ending processing.
From the above steps, we see that cross-chain message passing primarily occurs through internal communication between ZetaCore and ZetaClient—a relatively centralized approach. It doesn’t use Zetachain’s own smart contracts but relies on target-chain smart contracts. Therefore, this method only works if the target chain is a smart contract platform like Ethereum, requiring at least one contract deployment per chain for interoperability. Non-smart-contract platforms like Bitcoin cannot be supported. Moreover, application state and logic are distributed across these contracts. Synchronizing state and communication across chains becomes expensive, slow, and complicates rollback handling. To address these issues, Zetachain introduces the Omnichain smart contract mechanism.
E.2 Omnichain Smart Contract Mechanism
Omnichain smart contracts are ZetaChain’s approach to simplifying cross-chain interoperability. The process works as follows:
1. Asset receipt: The user sends native assets (e.g., ERC20 tokens) to the TSS address on Chain A, along with a message specifying [zEVMContractAddress, message]. The TSS address might be a dedicated contract for holding ERC20 tokens.
2. Observation and reporting: ZetaChain observers (zetaclients) detect this pending cross-chain call and report it to zetacore.
3. Invocation and execution: zetacore calls the `depositAndCall()` function in the SystemContract, which in turn invokes the `onCrossChainCall()` function at the specified zEVMContractAddress. During this call:
- The `zrc20` parameter is populated with the ZRC20 contract address managing the foreign token sent by the user in step 1.
- The `amount` parameter reflects the quantity of tokens sent.
- The `message` parameter contains the user’s memo from the transaction.
4. Execution of contract logic: The omnichain smart contract is invoked via `zContract(zEVMContractAddress).onCrossChainCall(zrc20, amount, message)`. The application contract should implement its business logic within the `onCrossChainCall()` function.
5. Handling execution outcomes:
- If execution succeeds with no external asset output, the omnichain smart contract interaction is complete.
- If the zEVM contract execution fails (reverts), a CCTX is created to revert the inbound transaction—returning the same amount of foreign tokens to the user (minus potential fees).
- If `onCrossChainCall()` produces output (e.g., triggers a ZRC20 withdrawal), another CCTX is created to guide and track the transfer of foreign assets to the user-specified address on the external chain. Such withdrawals are typically simple token transfers.
Key features of Omnichain smart contracts:
- Deployed only on zEVM, with all logic and state centralized, simplifying app development and maintenance.
- No need to deploy application smart contracts on external chains, enabling support for non-smart-contract chains like Bitcoin.
- Since all reversions are handled by the ZetaChain protocol, application contracts don’t need to implement revert logic.
In short, apart from minimal internal communication between ZetaCore and ZetaClient, all cross-chain processing rules are encoded directly into Zetachain’s own smart contracts. Simply sending a transfer with an attached message to a designated address on the target chain triggers cross-chain operations within Zetachain’s smart contracts.
More complex dApps may prefer Omnichain smart contracts because logic and state reside in one place. In contrast, traditional message passing requires broadcasting messages and synchronizing state across chains, increasing attack surface and gas costs (each message incurs additional gas, and more messages are needed for full state sync). In other words, for developers, Omnichain smart contracts behave as if all assets were on a single chain (see diagram below).
F. Zetachain’s Signature and Authorization Mechanism
ZetaChain’s signature and authorization mechanism relies on advanced Threshold Signature Schemes (TSS), effectively mitigating single points of failure and enhancing overall system security.
1. Threshold Signatures: ZetaChain uses Multi-Party Computation (MPC)-based TSS, allowing multiple validators to jointly manage a single ECDSA/EdDSA private key without any individual or small group ever possessing the full key. This combines the convenience of hot wallets with the security of cold wallets.
2. Key Generation and Distribution: Private keys are generated trustlessly and distributed among all validators. At no point can any single validator or external actor access the complete private key, ensuring system security.
3. Signing Process: ZetaChain’s TSS is leaderless—key generation and signing occur in a fully distributed manner, preventing leakage of sensitive information. For efficiency, ZetaChain also employs batch and parallel signing techniques to increase signer throughput.
4. Smart Contracts and Asset Management: With TSS keys and addresses, ZetaChain can manage native treasuries/pools on connected chains—including non-smart-contract chains like Bitcoin. This effectively adds smart contract capabilities to networks like Bitcoin, enabling pooled assets to be managed by smart contracts according to predefined rules—such as automated market makers (AMMs) or lending pools.
5. Support for Non-Smart-Contract Chains: TSS enables ZetaChain to support non-smart-contract chains like Bitcoin and Dogecoin, as well as smart contract platforms where multisig validation is costly. Through this signature and authorization mechanism, ZetaChain delivers powerful cross-chain functionality while ensuring transaction security and decentralized validation, making it a robust platform for managing diverse digital assets.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@hiCaptainZ
