CaptainZ

As the number of public chains and layer 2 chains increases, the demand for cross-chain assets and DApps also begins to rise. Cross-chain bridges naturally become a common solution, but Omnichain, represented by Zetachain, has taken a completely different path. This article will use Zetachain as an example to explain how Omnichain writes cross-chain rules into smart contracts to achieve decentralized cross-chain interoperability.

Several Cross-Chain Technical Solutions#

The core goal of cross-chain (Cross-Chain) technology is to achieve interoperability (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 applications running on different blockchain platforms can interact and collaborate with each other. Achieving this goal can greatly enhance the flexibility and scalability of the blockchain ecosystem, breaking the island effect between different blockchain platforms, thus promoting broader applications and development.

Based on the different ways of processing cross-chain messages and the corresponding asset signature authorization methods, the following technical solutions can be categorized:

1. Cross-Chain Bridges:

   Cross-chain bridges are technologies that enable assets to be transferred from one blockchain to another. This is achieved by locking assets on the source chain and issuing corresponding representative assets (or equivalent assets) on the target chain. This method supports cross-chain transfer and use of assets but requires ensuring that the locking and releasing processes of assets are secure and reliable. When two independent chains achieve interoperability through bridging, we say that one chain is a sidechain of the other main chain.

2. Notary:

The notary solution relies on a group of trusted nodes (or institutions) to verify the validity of cross-chain transactions. These notary nodes listen for events occurring on one chain and create corresponding transactions on another chain to verify and record these events. Although this method can achieve cross-chain interoperability, its security and degree of decentralization largely depend on the trustworthiness of the notary nodes.

3. Hash Timelock Contracts (HTLCs):

HTLCs are a time-locked smart contract technology that allows two parties to securely conduct cross-chain exchanges without a third party. This is achieved by creating a contract that requires the correct password to unlock the funds. The funds will only be unlocked and delivered to the other party when both parties fulfill the contract requirements. This method supports decentralized asset exchanges but requires a certain level of cooperation from the participants.

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

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

These technical solutions each have their advantages and disadvantages and are suitable for different scenarios and needs. The choice and implementation of cross-chain technology must consider 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 conducted securely and effectively. Its basic purpose is to transmit and verify messages between different blockchains, thereby achieving cross-chain interaction of assets and data. Its working principle mainly includes the following key steps:

1. Message Generation and Sending:

• Messages typically contain all necessary information regarding asset transfers, such as asset quantity, source address, destination address, etc.

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

2. Message Transmission:

• There are usually two methods of transmission: direct transmission and relay transmission.

• Direct transmission means there is a direct communication path between the source chain and the target chain, but this is rare in practice since most blockchains operate independently.

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

3. Message Verification:

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

• The verification process typically requires data proofs from the source chain (such as Merkle proofs), which can confirm that the message indeed comes from the source chain and has not been tampered with.

• Once verified, the smart contract on the target chain will execute corresponding operations based on the message content, such as minting tokens or updating states.

4. Processing and Response:

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

• Once this step is completed, the cross-chain interaction is essentially finished, and users can use or manage their assets on the target chain.

Thus, essentially, the aforementioned cross-chain technical solutions arise from the different message transmission methods they employ.

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, responsible for listening to events on one chain and replicating those events on another chain.
• A decentralized network composed of multiple independently operated nodes that validate and forward messages through a consensus mechanism.
  In cross-chain bridges, asset locking on the source chain and minting equivalent assets on the target chain are typically involved. This process needs to ensure that messages are not tampered with before being verified and executed.

2. Notary

The notary solution typically relies on a group of pre-selected notaries (which can be individuals, organizations, or automated nodes) responsible for listening to events on one chain and verifying and confirming these events on another chain. Notaries provide a centralized or semi-centralized verification mechanism, whose security and trust level highly depend on the trustworthiness of the notaries.

3. Hash Timelock Contracts (HTLC)

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

• Cryptographic Hash: Assets 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 assets will return to the original holder.
  This method does not rely on centralized verification but ensures 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 achieves direct communication between different blockchains through the IBC protocol, allowing each chain to maintain its autonomy while securely exchanging messages and assets. The essence of IBC and XCMP is actually a cross-chain communication protocol.

At the same time, CCMP technology also faces several major challenges:

Security: Relay nodes or networks must be trustworthy; otherwise, there is a risk of message tampering. Additionally, the smart contracts on both the source and target chains must be designed to be secure enough to prevent potential vulnerabilities.

Efficiency and Latency: Cross-chain operations typically involve multiple block confirmations, which can lead to significant time delays.

Decentralization and Trust Issues: Relying on relay nodes or third-party services may contradict the decentralized spirit of blockchain, so designing a decentralized yet 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 research and development in cross-chain technology. Various solutions attempt to find the best balance between decentralization, security, and efficiency.

Cross-Chain Asset Signature and Authorization#

Cross-chain technology and cross-chain interoperability not only rely on Cross-Chain Message Passing (CCMP) but also involve how to effectively perform signature and authorization on the source and target chains to ensure the secure handling of assets and the legality of transactions. Different cross-chain technical solutions adopt different signature and authorization mechanisms, which are fundamentally about how to verify and execute the legality of transactions and ensure the secure transfer of assets. Here are some common implementations of signature authorization in various cross-chain technical solutions:

1. Cross-Chain Bridges

Cross-chain bridges may use multi-signature (Multisignature) or proxy signature (Proxy Signature) methods to handle signatures and authorization. In this scheme, the operation of transferring assets requires authorization from a certain number of validating nodes or specific proxy services, which are responsible for verifying transaction requests and signing the transactions. This method can increase security but also introduces trust issues, as it relies on authorized centralized or semi-centralized entities.

2. Notary

In the notary system, notaries or a collection of notary nodes are typically responsible for listening to and verifying cross-chain transaction requests and executing corresponding operations on the target chain. Notaries need to sign and authorize operations on the target chain to prove that the transaction on the source chain is permitted. This method relies on the trustworthiness and security of the notaries.

3. Hash Timelock Contracts (HTLC)

In HTLC, signature authorization does not rely on external verifiers or intermediaries. Instead, the legality and execution of the transaction depend on the contract logic and direct interaction between participants. Participants provide the correct pre-image (i.e., key) as a means to unlock the contract, which itself is a form of authorization. Additionally, the contract itself has a time-lock mechanism, ensuring that only the correct pre-image provided within a specific time window can complete the transaction.

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 security and authorization mechanisms while ensuring the security and effectiveness of cross-chain messages through the protocol. This solution emphasizes decentralization and autonomy, reducing reliance on a single entity.

In summary, the signature authorization mechanisms in different cross-chain technical solutions vary based on their structure and security requirements. The choice and design of these mechanisms are crucial in balancing security, trust, decentralization, and efficiency. Ensuring the legality and security of all participating chains is essential when implementing cross-chain technology.

Zetachain's 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 essentially about writing cross-chain rules into smart contracts, which includes cross-chain message transmission rules and asset signature authorization rules. Let's delve into the details to see how Zetachain achieves this.

ZetaChain is a PoS blockchain built on the Cosmos SDK and Tendermint PBFT consensus engine. Due to the use of the Tendermint PBFT consensus engine, ZetaChain can achieve a fast block generation time of about 5 seconds and instant finality (no block confirmations, no reorganization allowed). Under ideal network conditions, its transaction throughput can reach over 4000 transactions per second, but the throughput of cross-chain transactions may not reach this level due to delays from external chains and various other factors (such as the speed of external node RPCs).

The architecture of ZetaChain consists of a distributed network of nodes, which are typically referred to as validators. Each validator in ZetaChain contains ZetaCore and ZetaClient. ZetaCore is responsible for producing the blockchain and maintaining the replicated state machine, 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 can become a node operator and participate in validation work by staking enough ZETA tokens.

Thus, if ZetaChain's validators only run the ZetaCore component, they become sequencers; if they only run the ZetaClient component and are responsible for observing events on external chains, they become observers; if they also run the ZetaClient component and are only responsible for signing outgoing transactions, they become signers.

ZetaChain also collectively holds standard ECDSA/EdDSA keys for authenticated interactions with external chains. These keys are distributed among multiple signers, and only a supermajority of signers can represent ZetaChain for signing externally. ZetaChain uses bonded 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, which mainly involves the following steps:

1. User Interaction with Contract: The user operates on contract C1 on chain A, leaving an event or transaction memo that contains the user-specified [chainID, contractAddress, message]. This message is encoded in binary format as application data.

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

3. Construct Outbound Transaction: Zetacore modifies the CCTX (cross-chain transaction) state variable and OutboundTxParams, guiding the TSS signers (in zetaclient) to construct, sign, and broadcast the outbound transaction.

4. Signing and Broadcasting: The TSS signers in zetaclient construct the outbound transaction based on OutboundTxParams in CCTX, perform the TSS key signing ceremony, and then broadcast the signed transaction to the external blockchain.

5. Update and Track Status: The CCTX structure also tracks the various stages/statuses of the cross-chain transaction.

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

7. Handling Success and Failure:

• If the external transaction is successful, the CCTX status changes to OutboundMined, and the CCTX processing is completed, entering a terminal state.

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

8. Handling Reversion:

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

• Zetaclients construct the reversion transaction, perform the TSS key signing ceremony, and broadcast the transaction back to the inbound blockchain (in this case, chain A).

9. Reversion Confirmation:

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

• If the reversion transaction is successful, the CCTX status changes to Reverted, and processing is completed.

• If the reversion transaction fails, the CCTX status changes to Aborted, and 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 semi-centralized approach. It does not use the smart contracts of Zetachain itself but only utilizes the smart contracts of the target chain. In this case, only target chains that are smart contract platforms like Ethereum can achieve this, and each chain must deploy at least one contract to achieve cross-chain interoperability. If it is a non-smart contract platform like Bitcoin, it cannot be used. Additionally, application states and logic are distributed across all these application contracts in a decentralized manner. Synchronizing states and communication between different chains becomes expensive, slow, and complicates rollback handling. To address these issues, Zetachain introduces the Omnichain smart contract mechanism.

Omnichain Smart Contract Mechanism#

Omnichain smart contracts are a simplified method proposed by ZetaChain for handling cross-chain interoperability. It mainly processes cross-chain messages and achieves cross-chain interoperability through the following steps:

1. Asset Reception: Users send local assets (such as ERC20 tokens) to the TSS address on chain A, along with a message specifying [zEVMContractAddress, message]. The TSS address may be a contract specifically set up to host ERC20 tokens.

2. Observation and Reporting: The observer of ZetaChain (zetaclients) monitors this upcoming cross-chain call and reports it to zetacore.

3. Invocation and Execution: Zetacore calls the depositAndCall() function of the SystemContract, which then calls the onCrossChainCall() function of the specified zEVMContractAddress. During this invocation:

• The zrc20 parameter will be filled with the ZRC20 contract address managing the foreign tokens sent by the user in step one.

• The amount parameter will be filled with the quantity 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 invoked via 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 are no external asset outputs, this omnichain smart contract interaction is complete.

• If the zEVM contract execution fails (a rollback occurs), a CCTX will be created to revert the inbound transaction, returning the same amount of foreign tokens to the user (minus any possible fees).

• If onCrossChainCall() has outputs (for example, it triggers some ZRC20 withdrawal operations), another CCTX will be 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 significant features of omnichain smart contracts are:

• They are only deployed on the zEVM, concentrating all logic and state in one place, making application development and maintenance simpler.

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

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

In summary, apart from a small amount of necessary information being the internal communication between ZetaCore and ZetaClient, the processing rules for other cross-chain information are all written into the smart contracts of Zetachain itself. As long as users send a transfer with an attached message to the specified address on the target chain, it can trigger the cross-chain operations in Zetachain's smart contracts.

More complex dApps may prefer omnichain smart contracts because the logic and state are in one place, while in traditional message passing, messages and state synchronization must be broadcast across different chains, which may lead to more attack surfaces and higher Gas fees (each message requires additional Gas, and the number of messages that need to be sent increases to maintain complete state synchronization). In other words, for developers, the behavior of omnichain smart contracts is as if all assets are on one chain (see the diagram below).

Zetachain's Signature Authorization Mechanism#

ZetaChain's signature authorization mechanism relies on an advanced threshold signature scheme (Threshold Signature Scheme, TSS), which effectively addresses single points of failure and enhances the overall security of the system.

1. Threshold Signature Scheme: ZetaChain uses a TSS based on multi-party computation (Multi-Party Computation, MPC), which allows multiple validators to jointly manage a single ECDSA/EdDSA private key without any single entity or a small number of validators fully controlling the private key. This method can provide the convenience of hot wallets with the security level of cold wallets.

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

3. Signing Process: The TSS adopted by ZetaChain is leaderless, meaning it generates keys and signs in a distributed manner, ensuring that no private information is leaked during the key generation or signing process. To improve efficiency, ZetaChain also employs batch signing and parallel signing techniques to enhance the throughput of signers.

4. Smart Contracts and Asset Management: With TSS keys and addresses, ZetaChain can manage local vaults/funds on connected chains, including non-smart contract chains like Bitcoin. This effectively adds smart contract functionality to networks like Bitcoin, allowing users to pool assets together and have smart contracts manage these assets according to preset rules, such as automated market maker (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 validate multi-signatures that are costly on smart contract platforms.

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 robust platform for supporting a wide range of digital asset management and operations.