As the number of layer 1 and layer 2 blockchains increases, the demand for cross-chain capabilities for assets and decentralized applications (Dapps) also grows. While cross-chain bridges are a common solution, Omnichain technologies, exemplified by Zetachain, take a distinctly different approach. This article uses Zetachain as a case study to explain how Omnichain integrates cross-chain rules into smart contracts, enabling decentralized interoperability.

Cross-Chain Solutions

The core objective of cross-chain technology is to achieve interoperability between different blockchain systems. Interoperability allows diverse blockchain platforms to understand and utilize each other’s assets and data, or to enable applications running on different blockchain platforms to interact and collaborate. Achieving this goal significantly enhances the flexibility and scalability of the blockchain ecosystem, breaking down the silos between different platforms and fostering broader application and development.

The following are several technical solutions for cross-chain interoperability, distinguished by how they handle cross-chain messages and asset authorization:

1. Cross-Chain Bridges:

Cross-chain bridges facilitate asset transfers between blockchains. They work by locking assets on the source chain and issuing corresponding representative assets on the target chain. This method supports asset transfer and usage across chains but requires secure and reliable processes for asset locking and release. When two independent chains interact through bridging, one chain acts as a sidechain to the other’s main chain.

2. Notary Schemes:

Notary schemes rely on a trusted group of nodes (or entities) to validate the legitimacy of cross-chain transactions. These notary nodes monitor events on one chain and create corresponding transactions on another chain to verify and record these events. Although this method can achieve interoperability, its security and decentralization largely depend on the trustworthiness of the notary nodes.

3. Hash Timelock Contracts (HTLCs):

HTLCs are a smart contract technology based on time locks that allow two parties to securely perform cross-chain exchanges without a third party. This is achieved through a contract that requires a correct password to unlock funds. The funds are only released and transferred to the other party if both sides fulfill the contract requirements. This method supports decentralized asset exchanges but requires cooperation between the parties involved.

4. Blockchain on Blockchain (e.g., Cosmos' IBC)：

This approach involves creating new blockchains (or layers) on existing ones to achieve cross-chain interoperability, such as the Inter-Blockchain Communication (IBC) protocol in the Cosmos network. IBC allows different blockchains to maintain independent governance structures while securely transferring assets and data. This method aims to establish a decentralized network of blockchains that can freely exchange information and value.

Each of these technical solutions has its advantages and limitations, suitable for different scenarios and needs. The choice and implementation of cross-chain technology should consider the characteristics of the target blockchain, security requirements, degree of decentralization, and complexity of implementation.

Cross-Chain Message Passing

Cross-Chain Message Passing (CCMP) is a pivotal technology for enabling interoperability between different blockchains, ensuring secure and efficient cross-chain interactions. The primary aim is to transfer and verify messages across blockchains, facilitating the interaction of assets and data. The main components of CCMP include:

1. Message Generation and Sending:

• Messages typically contain all necessary details about asset transfers, such as the amount of assets, source address, and destination address.

• Once generated, these messages are emitted by smart contracts on the source chain, which record transaction details and trigger asset locking.

2. Message Transmission:

• There are generally two modes of transmission: direct and relayed.

• Direct transmission, where there is a direct communication path between the source and destination chains, is rare as most blockchains operate independently.

• Relay transmission involves intermediaries (either centralized service providers or decentralized node networks) that monitor specific events on the source chain, capture relevant information, and pass it on to the destination chain.

3. Message Verification:

• On the destination chain, incoming messages must be validated to confirm their authenticity and integrity.

• The verification process often requires data proofs from the source chain, such as Merkle proofs, to ascertain that the message indeed originates from the source chain and remains unaltered.

• Upon successful verification, smart contracts on the destination chain execute actions based on the message content, such as minting tokens or updating states.

4. Processing and Response:

• After verification, the destination chain performs necessary operations, such as releasing assets or creating new token instances.

• Once this step is complete, the cross-chain interaction is essentially concluded, allowing users to utilize or manage their assets on the destination chain.

The distinctions in cross-chain technology solutions largely stem from their differing methods of message passing:

1. Cross-Chain Bridges:

Cross-chain bridges facilitate asset and information transfers between blockchains by creating an intermediary layer. 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 consisting of multiple independently operated nodes that verify and forward messages through a consensus mechanism.

In cross-chain bridges, asset locking on the source chain and the minting of equivalent assets on the destination chain are common. This process requires ensuring that messages are not tampered with before they are verified and executed.

2. Notaries:

Notary schemes typically rely on a pre-selected group of notaries (individuals, organizations, or automated nodes) that monitor events on one chain and verify and confirm these events on another. Notaries provide a centralized or semi-centralized verification mechanism, the security and trustworthiness of which heavily depend on the credibility of the notaries.

3. Hash Timelock Contracts (HTLC):

HTLCs are cryptographic contracts used for conditional asset exchanges between two chains. They utilize cryptographic hash functions and time locks to control the conditions under which assets are released:

• Cryptographic hash: Assets can only be released from the contract when the receiver provides the correct pre-image (corresponding to the hash's original data).

• Time lock: If the correct pre-image is not provided within a specified time, assets revert to the original owner.

This method does not rely on centralized verification and ensures secure asset exchange through the contract itself.

4. BoB (Blockchain on Blockchain):

This technology creates new chains or sub-chains based on a cross-chain communication protocol. For example, Cosmos achieves direct communication between different blockchains through its IBC protocol, allowing each chain to maintain its autonomy while securely exchanging messages and assets. The essence of IBC and similar protocols is cross-chain communication.

CCMP also faces several challenges:

• Security: Relay nodes or networks must be trustworthy, as there is a risk of message tampering. Additionally, smart contracts on both the source and destination chains need to be securely designed to prevent potential vulnerabilities.

• Efficiency and Latency: Cross-chain operations often involve multiple block confirmations, which can cause significant delays.

• Decentralization and Trust Issues: Relying on relay nodes or third-party services may contradict the decentralized ethos of blockchains, making the design of secure, decentralized CCMP mechanisms a technical challenge.

Due to these technological and security challenges, the implementation and optimization of CCMP remain active areas of research and development in cross-chain technology, with various solutions striving to balance decentralization, security, and efficiency.

Signature and Authorization of Cross-Chain Assets

Cross-chain technology and interoperability not only rely on Cross-Chain Message Passing (CCMP) but also involve effective signing and authorization mechanisms on both the source and destination chains to ensure secure asset handling and the legality of transactions. Different cross-chain technology solutions employ various mechanisms for signing and authorization, central to validating transaction legitimacy and ensuring safe asset transfers. Here's an overview of how these mechanisms are implemented in some common cross-chain technology frameworks:

1. Cross-Chain Bridges:

Cross-chain bridges might use multisignature (multisig) or proxy signature methods for signing and authorization. In these systems, the operation of transferring assets requires the approval of a certain number of validator nodes or specific proxy services that are responsible for authenticating and signing transaction requests. This method enhances security but also introduces trust issues since it depends on authorized centralized or semi-centralized entities.

2. Notaries:

In notary systems, notaries or a consortium of notary nodes typically monitor and verify cross-chain transaction requests and execute corresponding operations on the destination chain. Notaries are required to sign and authorize operations on the destination chain, certifying that the transactions on the source chain are permitted. This method depends on the trustworthiness and security of the notaries.

3. Hash Timelock Contracts (HTLCs):

In HTLCs, signing and authorization do not rely on external validators or intermediaries. Instead, the legitimacy and execution of transactions depend on the contract logic and direct interaction between participants. Parties provide the correct pre-image (i.e., key) as a means to unlock the contract, which itself serves as authorization. Additionally, the contract incorporates a time-lock mechanism, ensuring transactions can only be completed within a specific time window if the correct pre-image is provided.

4. Blockchain on Blockchain (BoB):

For example, in Cosmos' IBC protocol, the signing and authorization process is managed through inter-chain protocols and local contract execution. Each chain independently manages its security and authorization mechanisms while the protocol ensures the security and validity of cross-chain messages. This approach emphasizes decentralization and autonomy, reducing reliance on single entities.

In summary, the choice and design of signing and authorization mechanisms in different cross-chain technology solutions vary according to their structure and security needs. These mechanisms aim to balance security, trust, decentralization, and efficiency. When implementing cross-chain technology, ensuring the legitimacy and security of all participating chains is essential. This focus helps maintain a robust and reliable framework for cross-chain interactions, fostering broader adoption and trust in these technologies.

The Architecture of Zetachain

If DeFi embeds financial rules into smart contracts, and onchain gaming incorporates game rules, then Omnichain essentially writes cross-chain rules into smart contracts. This includes the rules for cross-chain message passing and the authorization of asset signatures. Let's delve into the details to see how Zetachain accomplishes this.

Zetachain is a PoS blockchain built on the Cosmos SDK and Tendermint PBFT consensus engine. Utilizing the Tendermint PBFT consensus engine enables Zetachain to generate blocks rapidly—approximately every 5 seconds—with instant finality (no need for block confirmations and no allowance for reorganizations). Under ideal network conditions, its transaction throughput can reach over 4000 transactions per second, although cross-chain transaction throughput may vary due to delays in external chains and other factors, such as the speed of external node RPCs.

The architecture of Zetachain includes a distributed network of nodes, typically referred to as validators. Each validator in Zetachain incorporates both ZetaCore and ZetaClient. ZetaCore is responsible for generating the blockchain and maintaining a replicated state machine, while ZetaClient handles observing events on external chains and signing outgoing transactions. Both ZetaCore and ZetaClient are packaged together and operated by node operators. Anyone who stakes a sufficient amount of ZETA tokens can become a node operator and participate in the validation process.

Hence, if a Zetachain validator only runs the ZetaCore component, it acts as a sequencer. If it only runs the ZetaClient component and merely observes external chain events, it becomes an observer. And if it runs ZetaClient solely for signing outgoing transactions, it is termed a signer.

Zetachain collectively holds standard ECDSA/EdDSA keys for authenticated interactions with external chains. These keys are distributed among multiple signers, and only a supermajority of these signers can sign on behalf of Zetachain. Zetachain employs bonded staking and positive/negative incentive mechanisms to ensure economic security.

Two Cross-Chain Interoperability Mechanisms of Zetachain

Zetachain supports two types of cross-chain interoperability mechanisms: the traditional cross-chain bridge mechanism and the Omnichain smart contract mechanism.

Cross-Chain Bridge Mechanism

Let's first examine the workflow of the cross-chain bridge mechanism, which mainly involves the following steps:

1. User Interaction with Contract: Users operate on contract C1 on chain A, leaving an event or transaction memo that includes the specified [chainID, contractAddress, message]. This message is application data encoded in binary format.

2. Event Capture by Observers: Observers within ZetaChain (in ZetaClient) capture this event or memo and report it to ZetaCore, which is responsible for verifying inbound transactions.

3. Outbound Transaction Construction: ZetaCore modifies the CCTX (cross-chain transaction) state variables and OutboundTxParams, guiding the TSS signers (in ZetaClient) to build, sign, and broadcast the outbound transaction.

4. Signing and Broadcasting: TSS signers in ZetaClient construct the outbound transaction based on the OutboundTxParams from CCTX, conduct a TSS key signing ceremony, and then broadcast the signed transaction to the external blockchain.

5. State Update and Tracking: The CCTX structure also tracks various stages/states of the cross-chain transaction.

6. Transaction Confirmation: Once the broadcast transaction is included (i.e., "mined" or "confirmed") on a blockchain, ZetaClient reports this confirmation to ZetaCore, which then updates the CCTX state.

7. Handling Success and Failure:

• If the external transaction succeeds, the CCTX state becomes OutboundMined, and the CCTX processing is completed, entering a terminal state.

• If the external transaction fails (e.g., is reverted on the Ethereum chain), the CCTX state updates to PendingRevert (if possible) or Aborted (if reversion is not possible). If it enters the Aborted state, then CCTX processing is completed.

8. Handling Reversions:

• If the new state is “PendingRevert,” the CCTX should already contain a second OutboundTxParams, guiding ZetaClients to create a “Revert” outbound transaction back to the inbound chain and contract, allowing the inbound contract to implement application-level reversion functionalities to clean up the contract state.

• ZetaClients build the reversion transaction, conduct a TSS key signing ceremony, and broadcast the transaction back to the inbound blockchain (chain A in this example).

9. Reversion Confirmation:

• Once the reversion transaction is “confirmed” on chain A, ZetaClients report the transaction status back to ZetaCore.

• If the reversion transaction succeeds, the CCTX state becomes Reverted, and processing is completed.

• If the reversion transaction fails, the CCTX state becomes Aborted, and processing is completed.

Through these steps, we see that the transmission of cross-chain messages is mainly accomplished through internal communication between ZetaCore and ZetaClient, using a somewhat centralized approach. It does not utilize Zetachain's own smart contracts, but instead relies on the smart contracts of the target chain. In this setup, only chains like Ethereum, which are smart contract platforms, can achieve interoperability, and each chain must deploy at least one contract to achieve cross-chain interoperability. Chains like Bitcoin, which are not smart contract platforms, cannot use this mechanism. Additionally, application states and logic are dispersed across all these application contracts in a distributed manner. Synchronizing states and communication between different chains becomes costly, slow, and complicates rollback processes. To address these issues, Zetachain introduced the Omnichain smart contract mechanism.

Omnichain Smart Contract Mechanism

The Omnichain smart contract, proposed by ZetaChain, is a streamlined method to handle cross-chain interoperability. It primarily processes cross-chain messages and facilitates interoperability through the following steps:

1. Asset Reception: Users send their local assets (e.g., ERC20 tokens) to a TSS address on Chain A, along with a message specifying [zEVMContractAddress, message]. This TSS address may be a contract specifically designed to custody ERC20 tokens.

2. Observation and Reporting: ZetaChain observers (zetaclients) detect this impending cross-chain invocation and report it to zetacore.

3. Invocation and Execution: Zetacore invokes the SystemContract’s depositAndCall() function, which in turn calls the onCrossChainCall() function at the specified zEVMContractAddress. During this invocation:

• The zrc20 parameter will be populated with the ZRC20 contract address managing the foreign tokens sent in the first step.

• The amount parameter will represent the quantity of tokens sent.

• The message parameter will contain the message sent in the transaction memo.

4. Contract Logic Execution: The omnichain smart contract is invoked via zContract(zEVMContractAddress).onCrossChainCall(zrc20, amount, message). Application contracts should implement their business logic within the onCrossChainCall() function.

5. Handling Contract Execution Results:

• If the contract executes successfully with no external asset output, the omnichain smart contract interaction is complete.

• If the zEVM contract execution fails (triggering a rollback), 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 outputs (e.g., it triggers some ZRC20 withdrawal operations), another CCTX is created to guide and track the transfer of foreign assets to an address specified by the user on an external chain. These withdrawals are typically straightforward token transfers.

Distinctive Features of Omnichain Smart Contracts:

• They are solely deployed on zEVM, centralizing all logic and states in one location, simplifying application development and maintenance.

• They do not require deployment of application smart contracts on external chains, thereby supporting non-smart contract chains like Bitcoin.

• All reversal operations are managed by the ZetaChain protocol, freeing application contracts from handling reversal logic.

In essence, aside from minimal essential information exchanged internally between ZetaCore and ZetaClient, all rules for processing cross-chain information are encoded within Zetachain’s smart contracts. A user simply needs to send a transaction with an additional message to the target chain's specified address to trigger cross-chain operations in Zetachain’s smart contracts.

More complex decentralized applications (dApps) might prefer Omnichain smart contracts due to the centralized logic and states, unlike traditional message-passing that requires broadcasting messages and synchronizing states across different chains, potentially exposing more attack surfaces and incurring higher gas costs (each message incurs additional gas, and more messages are required to maintain complete state synchronization). In other words, for developers, Omnichain smart contracts behave as if all assets were on a single chain.

Signature and Authorization of ZetaChain

ZetaChain relies on an advanced Threshold Signature Scheme (TSS), which effectively addresses the issue of single points of failure and enhances the overall security of the system.

1. Threshold Signature Scheme (TSS): ZetaChain utilizes a TSS based on Multi-Party Computation (MPC). This scheme allows multiple validators to collaboratively manage a single ECDSA/EdDSA private key without any single entity or a minority of validators gaining full control. This method offers the convenience of hot wallets with the security level of cold wallets.

2. Key Generation and Distribution: Within ZetaChain, private keys are generated without the need for a trusted intermediary and are distributed among all validators. This ensures that no single validator or external actor has access to the complete private key at any time, thereby securing the system.

3. Signature Process: The TSS used by ZetaChain is leaderless, meaning it operates through a distributed method for key generation and signing that ensures no private information is leaked during these processes. To enhance efficiency, ZetaChain also employs batch and parallel signing techniques, improving the throughput of signers.

4. Smart Contract and Asset Management: With TSS keys and addresses, ZetaChain can manage native vaults/pools of funds on connected chains, including non-smart contract chains like Bitcoin. This effectively adds smart contract capabilities to networks such as Bitcoin, allowing users to pool assets that smart contracts can manage according to preset rules, such as automated market makers (AMM) pools 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 platforms where multi-signature operations are costly.

Through this signature authorization mechanism, ZetaChain not only provides robust cross-chain functionality but also ensures the security of transactions and the decentralization of verification, making it a powerful platform for managing and operating a wide range of digital assets.