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 that 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, thereby 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 a technology that enables 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 process of assets is 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 scheme 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, e.g., 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 securely transferring 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, 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 ways to transmit: 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 because 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 legitimacy 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 actions based on the message content, such as minting tokens or updating states.

4. Processing and Response:

• After verification is completed, 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 for 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 scheme typically relies on a pre-selected group of notaries (which can be individuals, organizations, or automated nodes) responsible for listening for 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 secure asset exchange 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 the source and target chains must be designed to be secure enough to prevent potential vulnerabilities.

Efficiency and Latency: Cross-chain operations often 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 legitimacy of transactions. Different cross-chain technical solutions adopt different signature and authorization mechanisms, which focus on how to verify and execute the legitimacy of transactions and ensure the secure transfer of assets. Below are some common implementations of signature authorization in 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 authorizations. In this scheme, the operation of transferring assets requires authorization from a certain number of validating nodes or specific proxy services, which bear the responsibility of 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, the notaries or groups 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 transactions on the source chain are 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 legitimacy and execution of transactions depend on the contract logic and direct interaction between participants. Participants provide the correct pre-image (i.e., key) as a way 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 scheme 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 legitimacy and security of all participating chains is essential when implementing cross-chain technology.

Zetachain's Architecture#

If DeFi writes financial rules into smart contracts and on-chain games write game rules into smart contracts, then Omnichain essentially writes cross-chain rules into smart contracts, including 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. By using the Tendermint PBFT consensus engine, ZetaChain can achieve a rapid 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, commonly 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 operated by node operators. Anyone who stakes enough ZETA tokens can become a node operator and participate in validation work.

Thus, if a ZetaChain validator only runs the ZetaCore component, it becomes a sequencer; if it only runs the ZetaClient component and is responsible for observing events on external chains, it becomes an observer; if it also only runs the ZetaClient component and is responsible for signing outgoing transactions, it becomes a signer.

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 external signatures. ZetaChain uses bonded staking and positive/negative incentive mechanisms to ensure economic security.

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.

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 performs operations 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 the 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, the CCTX processing is completed, and it enters a terminal state.

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

8. Handling Revocation:

• 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 revocation functionality to clean up contract states.

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

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 processing is completed.

• If the revocation 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 internal communication between ZetaCore and ZetaClient, which is a semi-centralized approach and does not use Zetachain's own smart contracts; it 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 method proposed by ZetaChain to simplify the handling of 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 the first step.

• 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 called 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 executes successfully 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 revoke the inbound transaction, returning the same quantity 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 typically simple token transfers.

The notable 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 deploying application smart contracts on external chains, thus supporting non-smart contract chains like Bitcoin.

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

In summary, apart from a small amount of necessary information being internal communication between ZetaCore and ZetaClient, all other processing rules for cross-chain information are written into Zetachain's own smart contracts. 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, whereas 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 incurs additional Gas costs, 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 a single chain (see the diagram below).

Zetachain's Signature Authorization Mechanism#

ZetaChain's signature authorization mechanism relies on an advanced 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 (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 approach provides 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 key generation or signing. 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 predefined 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 on costly 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.