Chain abstraction Omnichain is to write cross-chain rules into smart contracts

Author: CaptainZ; Source: xlog

With the increasing number of public chains and layer2 chains, the cross-chain demand for assets and Dapps has also begun to increase. Cross-chain bridges are naturally a common solution, but Omnichain, represented by Zetachain, has taken a completely different path. This article will take Zetachain as an example to explain how Omnichain writes cross-chain rules into smart contracts to achieve decentralization of cross-chain interoperability.

Several cross-chain technical solutions

The core goal of cross-chain technology is to achieve interoperability between different blockchains. Interoperability means that different blockchain systems can understand and use each other's assets (such as tokens, cryptocurrencies, etc.) and data, or that applications running on different blockchain platforms can interact and collaborate with each other. The realization of this goal can greatly enhance the flexibility and scalability of the blockchain ecosystem, break the island effect between different blockchain platforms, and promote more extensive applications and development.

Depending on the processing method of cross-chain messages and the signature authorization method of the corresponding assets, it can be divided into the following technical solutions:

1. Cross-Chain Bridges:

   Cross-chain bridges are a technology that enables assets to be transferred from one blockchain to another. It achieves this process by locking assets on the source chain and issuing corresponding representative assets (or equivalent assets) on the target chain. This method supports the cross-chain transfer and use of assets, but it is necessary to ensure that the locking and release process of assets is safe and reliable. When two independent chains are bridged to generate interoperability, we say that one of the chains is a side chain of the other main chain.

2. Notary:

   The notary scheme relies on a group of trusted nodes (or institutions) to verify the validity of cross-chain transactions. These notary nodes listen to events that occur on one chain and create corresponding transactions on the other chain to verify and record these events. Although this approach can achieve cross-chain interoperability, its security and degree of decentralization largely depend on the credibility of the notary nodes.

3. Hash Timelock Contracts (HTLCs):

   HTLCs is a time-lock-based smart contract technology that allows two parties to securely exchange across chains without a third party. This is achieved by creating a contract that requires the correct password to unlock the funds. Only when both parties fulfill the contract requirements will the funds be unlocked and delivered to the other party. This method supports decentralized asset exchange, but has certain requirements for the cooperation of the participants.

4. BoB (Blockchain on Blockchain, such as Cosmos's IBC):

   This technical solution achieves cross-chain interoperability by creating a new blockchain (or layer) on an existing blockchain, such as the IBC (Inter-Blockchain Communication) protocol in the Cosmos network. IBC allows different blockchains to maintain independent governance structures while achieving secure transmission of assets and data. This approach aims to build a decentralized blockchain internet where chains can freely exchange information and value.

These technical solutions have their own advantages and disadvantages and are suitable for different scenarios and needs. The selection and implementation of cross-chain technology should take into account factors such as 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 the core technology for achieving cross-chain interoperability, ensuring that the process of cross-chain interaction can be carried out safely and efficiently. Its basic purpose is to pass and verify messages between different blockchains, thereby realizing cross-chain interaction of assets and data. Its working principle mainly includes the following key links:

1. Generation and sending of messages:

   - The message usually contains all the necessary information about the asset transfer, such as the amount of assets, source address, destination address, etc.

   - After the message is generated, it is sent through the smart contract of the source chain, which records the transaction details and triggers the locking of assets.

2. Message delivery:

   - There are usually two ways of delivery: direct delivery and relay delivery.

   - Direct delivery means that there is a direct communication path between the source chain and the target chain, but this is rare in practice because most blockchains operate independently.

   - Relay delivery involves relayers (which can be centralized service providers or decentralized node networks) that listen to specific events on the source chain, capture relevant information, and pass this information to the target chain.

3. Message verification:

   - On the target chain, the received message needs to be verified to confirm its legitimacy and integrity.

   - The verification process usually requires data proofs from the source chain (such as Merkle proofs), which can prove that the message is indeed from the source chain and has not been tampered with.

   - Once the verification is passed, the smart contract on the target chain will perform corresponding operations based on the content of the message, such as minting tokens or updating status.

4. Processing and response:

   - After the verification is completed, the target chain will perform necessary operations, such as releasing assets or creating new token instances.

   - After this step is completed, the cross-chain interaction is basically completed, and users can use or manage their assets on the target chain.

So in essence, the several cross-chain technical solutions mentioned above are caused by their use of different message transmission methods.

1. Cross-chain bridge

The cross-chain bridge facilitates the transfer of assets and information between different blockchains by creating an intermediary layer. This intermediary layer can be:

• A centralized server controlled by a trusted entity that listens to events on one chain and replicates them on another.

• A decentralized network consisting of multiple independently operated nodes that verify and forward messages through a consensus mechanism.
  In a cross-chain bridge, it usually involves the locking of assets on the source chain and the minting of equivalent assets on the target chain. This process requires ensuring that the message is not tampered with before it is verified and executed.

2. Notaries

Notarization schemes typically rely on a set of pre-selected notaries (which can be individuals, organizations, or automated nodes) that listen to events on one chain and verify and confirm them on another chain. Notaries provide a centralized or semi-centralized verification mechanism whose security and trust are highly dependent on the credibility of the notaries.

3. Hash Time Lock Contract (HTLC)

HTLC is a contract that relies on cryptography and is used for conditional asset exchange between two chains. It uses cryptographic hash functions and time locks to control the release conditions of assets:

• Crypto hash: The asset can only be released from the contract when the recipient provides the correct pre-image (corresponding to the original data of the hash).

• Time lock: If the correct pre-image is not provided within the specified time, the asset will be returned to the original holder.
  This method does not rely on centralized verification, but guarantees the secure exchange of assets through the contract itself.

4. BoB

This technology creates a new chain or sub-chain based on a cross-chain communication protocol. For example, Cosmos realizes direct communication between different blockchains through the IBC protocol, and each chain can exchange messages and assets securely while maintaining its autonomy. The essence of IBC and XCMP is actually a cross-chain communication protocol.

CCMP technology also faces several major challenges:

** Security:** The relay node or network must be trusted, otherwise there is a risk of message tampering. In addition, the smart contracts of the source and target chains must also be designed to be secure enough to prevent potential vulnerabilities.

Efficiency and delay: Cross-chain operations usually involve multiple block confirmations, which may result in significant time delays.

** Decentralization and trust issues:** Relying on relay nodes or third-party services may be contrary to the decentralized spirit of blockchain, so designing a decentralized and secure CCMP mechanism is a technical challenge.

Due to these technical and security challenges, the implementation and optimization of CCMP is an active area of ​​cross-chain technology research and development. Various solutions attempt to find the best balance between decentralization, security, and efficiency.

Signature and authorization of cross-chain assets

Cross-chain technology and cross-chain interoperability not only rely on cross-chain messaging (CCMP), but also involve how to effectively sign and authorize on the source and target chains to ensure the secure processing of assets and the legitimacy of transactions. Different cross-chain technology solutions use different signature and authorization mechanisms. The core of these mechanisms is how to verify and execute the legitimacy of transactions and ensure the secure transfer of assets. The following are some common implementations of signature authorization in cross-chain technology solutions:

1. Cross-chain bridge

Cross-chain bridges may use multi-signature or proxy signature methods to handle signatures and authorizations. In this solution, the operation of transferring assets needs to be authorized by a certain number of verification nodes or specific proxy services, which are responsible for verifying transaction requests and signing transactions. This approach can increase security, but it also introduces trust issues because it relies on authorized centralized or semi-centralized entities.

2. Notary

In a notary system, a notary or a collection of notary nodes is usually responsible for listening to and verifying cross-chain transaction requests and performing corresponding operations on the target chain. The notary needs to sign and authorize the operation on the target chain to prove that the transaction on the source chain is allowed. This approach relies on the trust and security of the notary.

3. Hash Time Lock Contract (HTLC)

In HTLC, signature authorization does not rely on external verifiers or intermediaries. Instead, the legitimacy and execution of transactions rely on direct interaction between contract logic and participants. The parties provide the correct pre-image (i.e., key) as a way to unlock the contract, which is itself an authorization. In addition, the contract itself has a time lock mechanism to ensure that the transaction can only be completed if the correct pre-image is provided within a specific time window.

4. BoB

For example, in Cosmos's IBC protocol, the signature authorization process is executed through inter-chain protocols and local contracts. Each chain independently manages its own security and authorization mechanisms, while ensuring the security and validity of cross-chain messages through the protocol. This solution emphasizes decentralization and autonomy, reducing dependence on a single entity.

In short, the signature authorization mechanism varies in different cross-chain technology solutions according to their structure and security requirements. The key to the selection and design of these mechanisms lies in how to balance security, trust, decentralization and efficiency. When implementing cross-chain technology, it is essential to ensure the legitimacy and security of all participating chains.

Zetachain's Architecture

If DeFi is to write financial rules into smart contracts, and on-chain games are to write game rules into smart contracts, then Omnichain is actually to write cross-chain rules into smart contracts, which includes cross-chain message transmission rules and asset signature authorization rules. Let's go into detail to see how Zetachain does it.

ZetaChain is a blockchain based on Cosmos SDK and Tendermint. A PoS blockchain built on the PBFT consensus engine. Thanks to the use of the Tendermint PBFT consensus engine, ZetaChain is able to achieve fast block generation times of approximately 5 seconds and instant finality (no block confirmations, no reorganization allowed). Under ideal network conditions, its transaction throughput can reach 4000+ transactions per second, but the throughput of cross-chain transactions may not reach this level due to latency in external chains and various other factors (such as external node RPC speed, etc.).

ZetaChain's architecture consists of a distributed network of nodes, which are often called validators. Each validator in ZetaChain contains ZetaCore and ZetaClient. ZetaCore is responsible for generating the blockchain and maintaining the replicated state machine, while ZetaClient is responsible for observing events on the external chain and signing outgoing transactions. ZetaCore and ZetaClient are packaged together and run by node operators. Anyone who stakes enough ZETA tokens can become a node operator and participate in the validation work.

So, if a ZetaChain validator only runs the ZetaCore component, it becomes a sequencer, if it only runs the ZetaClinet component and is only responsible for observing external chain events, it becomes an observer, and if it only runs the ZetaClinet component and is only responsible for signing outgoing transactions, it is a signer.

ZetaChain also collectively holds standard ECDSA/EdDSA keys for authenticated interactions with external chains. These keys are dispersed among multiple signers, and only a super majority of signers can sign on behalf of ZetaChain. ZetaChain uses bound staking and positive/negative incentive mechanisms to ensure economic security.

Zetachain's Two Cross-Chain Interoperability Mechanisms

Zetachain supports two cross-chain interoperability mechanisms, one is the traditional cross-chain bridge mechanism, and the other is the Omnichain smart contract mechanism.

Cross-chain bridge mechanism

Let’s first look at the workflow of the cross-chain bridge mechanism. The whole process mainly involves the following steps:

**1. User-contract interaction:** The user operates on contract C1 of chain A and leaves an event or transaction memo containing the user-specified [chainID, contractAddress, message]. This message is application data encoded in binary format.

**2. Observer captures the event:** The ZetaChain observer (in zetaclient) captures this event or memo and reports it to zetacore, which is responsible for verifying the inbound transaction.

**3. Construct outbound transactions:** zetacore modifies the CCTX (cross-chain transaction) state variable and OutboundTxParams, instructing the TSS signer (in zetaclient) to construct, sign, and broadcast the external transaction.

**4. Signing and Broadcasting:** The zetaclient’s TSS signer constructs an outbound transaction based on the OutboundTxParams in CCTX, performs a TSS key signing ceremony, and then broadcasts the signed transaction to the external blockchain.

**5. Updating and Tracking Status:** The CCTX structure also tracks the various stages/statuses of cross-chain transactions.

**6. Transaction Confirmation:** Once the broadcasted transaction is included (i.e., “mined” or “confirmed”) on a blockchain, zetaclient reports this confirmation to zetacore and then updates the CCTX status.

7. Processing Success and Failure:

   - If the external transaction is successful, the CCTX status changes to OutboundMined, and CCTX processing is completed and enters the terminal state.

   - If the external transaction fails (e.g., is revoked on the Ethereum chain), the CCTX state is updated to PendingRevert (if possible) or Aborted (if reversal is not possible). If it enters the Aborted state, the CCTX processing is complete.

8. Processing Reversal:

   - If the new state is "PendingRevert", the CCTX should already contain a second OutboundTxParams, instructing the zetaclients to create a "Revert" outbound transaction back to the inbound chain and contract, allowing the inbound contract to implement application-level reversal functionality to clean up the contract state.

   - zetaclients construct the reversal transaction, perform the TSS key signing ceremony, and broadcast the transaction back to the inbound blockchain (chain A in this example).

9. Revocation Confirmation:

   - Once the revocation transaction is "confirmed" on chain A, zetaclients report the transaction status to zetacore.

   - If the revocation transaction is successful, the CCTX status changes to Reverted and the processing is completed.

   - If the revocation transaction fails, the CCTX status changes to Aborted and the processing is completed.

Through the above steps, we can see that the transmission of cross-chain messages is mainly completed through the internal communication between ZetaCore and ZetaClient, which is a decentralized way. It does not use the smart contract of Zetachain itself, but only uses the smart contract of the target chain. In this case, it can only be realized if the target chain is a smart contract platform like Ethereum, and each chain must deploy at least one contract to achieve cross-chain interoperability. If it is a non-smart contract platform such as Bitcoin, it cannot be used. Another, the application state and logic are scattered in all these application contracts in a distributed manner. Synchronizing state and communication between chains becomes expensive, slow, and complicates rollbacks. To address the above issues, Zetachain introduces the Omnichain smart contract mechanism.

Omnichain Smart Contract Mechanism

Omnichain smart contracts are a method proposed by ZetaChain to simplify cross-chain interoperability processing. It mainly processes cross-chain messages and implements cross-chain interoperability through the following steps:

**1. Receiving assets:** The user sends a local asset (such as an ERC20 token) to the TSS address of chain A, and attaches a message specifying [zEVMContractAddress, message]. The TSS address here may be a contract specifically set up to host ERC20 tokens.

**2. Observe and report:** ZetaChain observers (zetaclients) detect this upcoming cross-chain call and report it to zetacore.

**3. Call and Execute:**zetacore calls the  depositAndCall() function of SystemContract, which in turn calls the  onCrossChainCall() function of the specified zEVMContractAddress. During this call:

   - The zrc20 parameter will be filled with the address of the ZRC20 contract that manages the foreign tokens sent by the user in the first step.

   - The amount parameter will be filled with the amount of tokens sent by the user.

   - The message parameter will be the message sent by the user in the transaction memo.

**4. Execution of contract logic:** The omnichain smart contract is called through  zContract(zEVMContractAddress).onCrossChainCall(zrc20, amount, message) . The application contract should implement its business logic in the  onCrossChainCall() function.

5. Processing contract execution results:

   - If the contract execution is successful and there is no external asset output, the omnichain smart contract interaction is completed.

   - If the zEVM contract execution fails (rollback occurs), a CCTX is created to reverse the inbound transaction, that is, the same amount of foreign tokens is returned to the user (minus possible fees).

   - If onCrossChainCall() has an output (e.g. it triggers some ZRC20 withdrawals), another CCTX is created to direct and track the transfer of foreign assets to a user-specified address on the external chain. These withdrawals are typically simple token transfers.

The salient features of Omnichain smart contracts are:

• It is only deployed on zEVM, with all logic and state in one place, making application development and maintenance much simpler.

• It does not require application smart contracts to be deployed on external chains, so it can support non-smart contract chains such as Bitcoin.

• Since all revocations are handled by the ZetaChain protocol, application contracts do not need to handle revocation logic.

To put it in a nutshell, except for a small amount of necessary information that is internal communication between ZetaCore and ZetaClient, the rules for handling other cross-chain information are written into the smart contract of Zetachain itself. As long as the user sends a transfer with an attached message to the specified address of the target chain, the cross-chain operation in the smart contract of Zetachain itself can be triggered.

More complex dApps may prefer Omnichain smart contracts because the logic and state are in one place, while in traditional messaging, messages and state synchronization must be broadcast on different chains, which may lead to more attack surfaces and more gas fees (each message requires additional gas to be paid, and the number of messages that need to be sent increases to maintain full state synchronization). In other words, for developers, Omnichain smart contracts behave as if all assets are on one chain (see the figure below).

Zetachain's signature authorization mechanism

ZetaChain The signature authorization mechanism relies on an advanced multi-party threshold signature scheme (TSS), which can effectively solve the single point failure problem and enhance the security of the entire system.

**1. Threshold Signature Scheme: **ZetaChain Using TSS based on Multi-Party Computation (MPC), this scheme allows multiple validators to jointly manage a single ECDSA/EdDSA private key, but does not allow any single entity or a small number of validators to fully control the private key. This approach can provide the convenience of a hot wallet and the security of a cold wallet.

**2. Key Generation and Distribution:** In ZetaChain, private keys are generated in a trustless manner and distributed among all validators. This means that no single validator or external actor can access the full private key at any time, ensuring the security of the system.

**3. Signing Process:** The TSS adopted by ZetaChain is leaderless, that is, it performs key generation and signing in a distributed manner, which ensures that no private information is leaked during the key generation or signing process. In order to improve efficiency, ZetaChain also uses batch signing and parallel signing technology to increase the throughput of signers.

**4. Smart Contracts and Asset Management:** Because it has TSS keys and addresses, ZetaChain is able to manage local vaults/fund pools on connected chains, including non-smart contract chains such as Bitcoin. This actually adds smart contract functionality to the Bitcoin network, etc., allowing users to pool assets together and have smart contracts manage these assets 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 such as Bitcoin and Dogecoin, as well as smart contract platforms where it is expensive to verify multiple signatures.

Through this signature authorization mechanism, ZetaChain not only provides powerful cross-chain capabilities, but also ensures the security of transactions and the decentralization of verification, making it a powerful platform that supports a wide range of digital asset management and operations.