Check out this blog post in español, 中文, 日本語, हिंदी, 한국인, tiếng-việt, deutsch, and français

In our extensive analysis of the blockchain interoperability market, we acknowledge a few blockchain projects and proposals that aim to achieve generic programmability. The problem is that these projects are either centralized to varying degrees and/or utilize questionable trust models. This leaves a major gap in the crypto ecosystem for a public, permissionless, and decentralized approach to omnichain interoperability. ZetaChain is a pioneer of the first incentivized public blockchain and general-purpose-cross-chain smart contract platform. Such an audacious claim begs a number of big questions about the limitations of blockchain “bookkeeping” mechanisms to support cross-chain dApps and the challenge of asynchrony. We’ll address both topics in this piece by taking a look under the hood at ZetaChain’s hybrid transaction model design, powered by the Zeta Virtual Machine (ZVM).

Blockchain Transaction Models

In order to achieve generic omnichain smart contract support, you need to overcome a couple of key challenges. The first is that communication between heterogeneous chains is inherently asynchronous. Unlike smart contracts on a single chain such as Ethereum Virtual Machine (EVM), querying or changing the state of another chain is triggered by messages (observations) from external chains. This type of cross-chain smart contract transaction model is best considered a finite state machine.

The second challenge is that of the blockchain programming model, which impacts how smart contracts transfer messages, data, and value. Historically, there are two primary “bookkeeping” models for recording and changing state on a blockchain: UTXO (unspent transaction output), which is used by Bitcoin, Ergo, Cardano, and others, and account-based, which is used by the EVM. Here’s a simple overview of each:

• UTXO: The UTXO model represents a global blockchain state through all spent and unspent transaction outputs. You can think of it like the user’s balance of coins is the sum of all UTXOs that can be spent by the user. Every output can be tied to a transaction event as far back as its inception, and the blockchain functions as the accepted ledger of all of those transactions ever recorded by the network. Every node on the blockchain constantly maintains the UTXO set, which is a collection of all UTXOs at any given time. It can be visually represented as a directed acyclic graph (DAG) between addresses (figure 1).

• Account-based: The account model incorporates wallets (like bank accounts) at the protocol level. It operates such that the state of the system is updated based on the transactions of each previous block. The current set of accounts and their balances represent the global state. In Ethereum’s account-based system as an example, it includes External Owned Accounts (EOA), which are controlled by a private key, and smart contracts, which work according to their own logic.

Figure 1: UTXO vs. Account-based models: network state visualization

UTXO vs. Account-based Models

The key difference between these models lies in their expressive power. The computational nature of the account-based model makes its expressiveness higher than that of UTXO-based scripts, which can be thought of as more of a verification model. However, UTXO-based smart contracts are typically simpler, more robust, and efficient in storage and compute, and they have less attack surface due to UTXO’s limitations. For example, in practice, Bitcoin scripts very rarely have unintended security bugs while Ethereum smart contracts have a reputation for multi-million dollar exploits. Also, in the case of Bitcoin, UTXO’s implicit enforcement of key invariant eliminates the double spend problem: transaction total input amount = total output amount. So while the expressiveness of account-based programming allows for the easy creation of complex dApps (AMM, ICOs, etc.), it comes at the cost of lower security.

Hybrid Transaction Model Attempts

If you’re going to propose a decentralized, general-purpose-cross-chain smart contract platform, then you need to address the following challenge: How do you extend the UTXO model to be expressive enough to support popular dApps such as a Uniswap-style AMM DEX, while still remaining simple and safe?

A couple of progressive projects attempt to solve this dilemma. Ergo pioneered the extended UTXO (eUTXO) model followed by Cardano. In these eUTXO platforms, AMM DEXs can be implemented to a certain extent by keeping the state of the AMM pair in a UTXO, but it’s not without serious issue. Only one transaction can succeed a block because only one transaction can spend that UTXO and create a new one in a block. The result is UTXO congestion where completed transactions that try to spend the same UTXO will fail and must wait for one block and spend the new UTXO. It’s not very optimal.

ZetaChain’s Hybrid UTXO-account Design

ZetaChain introduces a hybrid UTXO and account-based approach that combines the strengths of each. Essentially, it uses UTXO to represent and track external blockchain transactions (treated as a synthetic UTXO), and uses account-based smart contracts for logic and managing shared global states. A UTXO includes the amount of ZETA coin (burned), amount of another coin (for example, BTC on the Bitcoin network where it’s impossible to issue ZETA coin), and a script msg (roughly equivalent to a message or function call on Ethereum). The synthetic UTXO model enables ZetaChain to experience benefits of accountability, simplicity, and scalability while avoiding the key limitation of UTXO which is the expressiveness of its scripting, and awkwardness in certain important applications (i.e. one transaction per block in an AMM).

Let’s examine ZetaChain’s hybrid UTXO-account flow (figure 2):

1. The smart contract on ZetaChain runs the msg and generates an Event that tries to spend the UTXO on ZetaChain.

2. The Event is then picked up by ZetaClient signers, and they will sign a transaction to an external chain.

3. The ZVM and ZetaClient will validate certain invariants, one of which is that the output ZETA must be equal to the input ZETA in the UTXO.

4. Upon confirmation and observation of the outbound transaction, the UTXO is marked as spent and deleted from the state machine. If the outbound transaction fails (insufficient gas, etc.), the UTXO is marked as revert and refunds of ZETA and/or associated coins are refunded on the source chain. When the refund is confirmed, the UTXO is deleted from the state machine.

Figure 2: Hybrid UTXO-account flow

Moving Towards Transaction Atomicity in the Zeta Virtual Machine (ZVM)

The UTXO and account-based transaction model support transaction atomicity and safety differently. In the UTXO model, the application must ensure atomic transactions because the UTXO transaction cannot modify the global state and there is no issue of partial execution. In the account-based model, the virtual machine should ensure the atomicity of transactions. In a cross-blockchain context, effecting state changes on external blockchains is asynchronous, and it’s difficult to revert a partially executed transaction if it commits to an external blockchain. This makes it challenging to support a pure account-based smart contract platform such as EVM cross blockchain.

In order to support cross-blockchain transaction atomicity and ensure safety, the ZetaChain smart contract virtual machine is constrained in the following ways:

1. Each UTXO can only generate one output

   Event. Essentially only one external chain can update its state in response to an UTXO. Because outbound transactions on external chains are generally not revertible (sent tokens cannot be taken back for example), multiple output Events would make it infeasible to revert the whole transaction.

2. All value transfers cross-blockchain must be in ZETA, because only the ZETA coin is within control of the ZetaChain system and can be reverted (refunded) if the cross-blockchain transaction fails.

Note, certain more complicated smart contracts that require multiple output transactions (for example, must send to multiple chains) will be best written as multiple-stage transactions where the application itself handles atomicity of the multi-stage transaction.

Unlocking Omnichain Interoperability

Many features go into creating a truly omnichain interoperability solution that can stand the test of time. At its core, the solution must be chain-agnostic, have a sustainable security/trust model, and function well while operating affordably. ZetaChain brings an immense level of innovation to blockchain technology and distributed computing to fulfill each of these prerequisites. Specifically, the focus of this piece is on the ZVM, and its novel approach to blockchain transaction “bookkeeping”. This is one of many breakthrough components that enable smart contracts to interact with states on external chains directly. For the first time in crypto, ZetaChain makes available a public, decentralized blockchain with built-in omnichain interoperability.

About ZetaChain

ZetaChain is the foundational layer to a multichain future. The novel blockchain enables multichain functionality without using bridges or wrapped tokens and the easy deployment of omnichain-dApps, or odApps. These applications can manage and connect data and value across all smart contract platforms as well as non-smart contract platforms like Bitcoin and Dogecoin.

Categories