Taking Zetachain as an example, how Ominchain implements chain abstraction

Original author: CaptainZ, former Injective researcher

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

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.

A. Several cross-chain technology 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.

According to 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 is 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 interoperable using a bridge, 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 another 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-locked 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 approach 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 in which individual 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 needs to consider factors such as the characteristics of the target blockchain, security requirements, degree of decentralization, and complexity of implementation.

B. 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 effectively. Its basic purpose is to transmit 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:

- Messages usually contain all necessary information about asset transfers, such as asset quantity, 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. Verification of messages:

- 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 bridges

Cross-chain bridges facilitate 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 chain.

- 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 usually rely on a set of pre-selected notaries (which can be individuals, organizations, or automated nodes) who listen to events on one chain and verify and confirm them on another chain. Notaries provide a centralized or semi-centralized verification mechanism, the security and trust of which is 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 conditions for the release of assets:

- Cryptographic 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 new chains or sub-chains 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 cause 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.

C. 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. Hashed Time-Locked 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 the contract logic and the 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-locking 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' IBC protocol, the signature authorization process is executed through inter-chain protocols and local contracts. Each chain independently manages its own security and authorization mechanism, while ensuring the security and validity of cross-chain messages through the protocol. This scheme emphasizes decentralization and autonomy, and reduces dependence on a single entity.

In summary, the signature authorization mechanism varies in different cross-chain technology schemes 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.

D. Zetachain Architecture

If DeFi is about writing financial rules into smart contracts, and on-chain games are about writing game rules into smart contracts, then Omnichain is actually about writing cross-chain rules into smart contracts, including cross-chain message transmission rules and asset signature authorization rules. Let's take a closer look at how Zetachain does it.

ZetaChain is a PoS blockchain built on Cosmos SDK and Tendermint PBFT consensus engine. Due to the use of Tendermint PBFT consensus engine, ZetaChain is able to achieve fast block generation time of about 5 seconds and instant finality (no block confirmation, 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 of 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 of ZetaChain contains ZetaCore and ZetaClient. ZetaCore is responsible for generating blockchains and maintaining replicated state machines, while ZetaClient is responsible for observing events on external chains 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 verification 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. If it also 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.

E. Two cross-chain interoperability mechanisms of Zetachain

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

E.1 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 TSS signer of zetaclient 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 on a blockchain (i.e. "mined" or "confirmed"), zetaclient will report this confirmation to zetacore and then update the CCTX status.

7. Processing success and failure:

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

- If the external transaction fails (e.g. it 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. Reversal Confirmation:

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

- If the reversal transaction succeeds, the CCTX status changes to Reverted and the processing is completed.

- If the reversal 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 of ZetaCore and ZetaClient, which is a decentralized method. 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 different chains becomes expensive and slow, and complicates the rollback process. In order to solve the above problems, Zetachain introduced the Omnichain smart contract mechanism.

E.2 Omnichain Smart Contract Mechanism

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

1. Receiving assets: The user sends local assets (such as ERC20 tokens) 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) observe the impending cross-chain call and report it to zetacore.

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

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

- The `amount` parameter will be populated 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 by `zContract(zEVMContractAddress).onCrossChainCall(zrc20, amount, message)`. The application contract should implement its business logic in the `onCrossChainCall()` function.

5. Handling contract execution results:

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

- 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 (for example, it triggers a withdrawal operation of some ZRC20), another CCTX is created to guide and track the transfer of foreign assets to the user-specified address on the external chain. These withdrawals are usually simple token transfers.

The salient features of Omnichain smart contracts are:

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

- It does not require the deployment of application smart contracts on external chains, so it can support non-smart contract chains such as Bitcoin.

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

In a nutshell, except for a small amount of necessary information that is internal communication between ZetaCore and ZetaClient, the processing rules for other cross-chain information are written into the smart contract of Zetachain itself. As long as the user sends a transfer with an additional 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).

F. Zetachain's Signature Authorization Mechanism

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

1. Threshold Signature Scheme: ZetaChain uses TSS based on Multi-Party Computation (MPC), which 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 way that does not require a trustworthy intermediary and are distributed among all validators. This means that no single validator or external actor can access the complete private key at any time, thereby ensuring the security of the system.

3. Signature Process: The TSS used by ZetaChain is leaderless, that is, it generates and signs keys in a distributed manner, which ensures that no private information is leaked during the key generation or signing process. To improve efficiency, ZetaChain also uses batch signature and parallel signature technology to increase the throughput of signers.

4. Smart Contract and Asset Management: With TSS keys and addresses, ZetaChain is able to manage local vaults/funding pools on connected chains, including non-smart contract chains such as Bitcoin. This actually adds smart contract functionality to the Bitcoin network, 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 with high costs for verifying multiple signatures. Through this signature authorization mechanism, ZetaChain can not only provide powerful cross-chain functions, but also ensure 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.

Original link

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群： https://t.me/theblockbeats

Telegram 交流群： https://t.me/BlockBeats_App

Twitter 官方账号： https://twitter.com/BlockBeatsAsia