Native Custom Tokens in the Extended UTXO Model

Abstract

User-defined tokens—both fungible ERC-20 and non-fungible ERC-721 tokens—are central to the majority of contracts deployed on Ethereum. User-defined tokens are non-native on Ethereum; i.e., they are not directly supported by the ledger, but require custom code. This makes them unnecessarily inefficient, expensive, and complex.

The Extended UTXO Model (EUTXO)  [5] has been introduced as a generalisation of Bitcoin-style UTXO ledgers, allowing support of more expressive smart contracts, approaching the functionality available to contracts on Ethereum. Specifically, a bisimulation argument established a formal relationship between the EUTXO ledger and a general form of state machines. Nevertheless, transaction outputs in the EUTXO model lock integral quantities of a single native cryptocurrency only, just like Bitcoin.

In this paper, we study a generalisation of the EUTXO ledger model with native user-defined tokens. Following the approach proposed in a companion paper  [4] for the simpler case of plain Bitcoin-style UTXO ledgers, we generalise transaction outputs to lock not merely coins of a single cryptocurrency, but entire token bundles, including custom tokens whose forging is controlled by forging policy scripts. We show that this leads to a rich ledger model that supports a broad range of interesting use cases.

Our main technical contribution is a formalisation of the multi-asset EUTXO ledger in Agda, which we use to establish that the ledger with custom tokens is strictly more expressive than the original EUTXO ledger. In particular, we state and prove a transfer result for inductive and temporal properties from state machines to the multi-asset EUTXO ledger, which was out of scope for the single-currency EUTXO ledger. In practical terms, the resulting system is the basis for the smart contract system of the Cardano blockchain.

A Complete formal definition of EUTXO\(_{\text {ma}}\)

1.1 A.1 Finitely-Supported Functions

If K is any type and M is a monoid with identity element 0, then a function $f: K \rightarrow M$ is finitely supported if $f(k) \ne 0$ for only finitely many $k \in K$. More precisely, for $f: K \rightarrow M$ we define the support of f to be $\mathsf {supp}(f) = \{k \in K : f(k) \ne 0\}$ and $\textsf {FinSup}[K,M] = \{f : K \rightarrow M : \left| \mathsf {supp}(f)\right| < \infty \}$.

If $(M,+,0)$ is a monoid then $\textsf {FinSup}[K,M]$ also becomes a monoid if we define addition pointwise ($(f+g)(k) = f(k) + g(k)$), with the identity element being the zero map. Furthermore, if M is an abelian group then $\textsf {FinSup}[K,M]$ is also an abelian group under this construction, with $(-f)(k) = -f(k)$. Similarly, if M is partially ordered, then so is $\textsf {FinSup}[K,M]$ with comparison defined pointwise: $f \le g$ if and only if $f(k) \le g(k)$ for all $k \in K$.

It follows that if M is a (partially ordered) monoid or abelian group then so is $\textsf {FinSup}[K,\textsf {FinSup}[L,M]]$ for any two sets of keys K and L. We will make use of this fact in the validation rules presented later (see Fig. 5).

Finitely-supported functions are easily implemented as finite maps, with a failed map lookup corresponding to returning 0.

1.2 A.2 Ledger Types

The formal definition of the EUTXO$_{\text {ma}}$ model integrates token bundles and forge fields from the plain UTXO$_{\text {ma}}$ model  [4] into the single currency EUTXO model definition, while adapting forging policy scripts to enjoy the full expressiveness of validators in EUTXO (rather than the limited domain-specific language of UTXO$_{\text {ma}}$). Figures 2 and 3 define the ledger types for EUTXO$_{\text {ma}}$.

Fig. 2.

Primitives and basic types for the EUTXO$_{\text {ma}}$ model

Fig. 3.

The $\textsf {Context}$ types for the EUTXO$_{\text {ma}}$ model

1.3 A.3 Transaction Validity

Fig. 4.

Auxiliary functions for EUTXO$_{\text {ma}}$ validation

Fig. 5.

Validity of a transaction t in the EUTXO$_{\text {ma}}$ model

Finally, we provide the transaction validity rules, which among other things state how forging policy scripts affect transaction validity. To this end, we replace the notion of an integral $\textsf {Quantity}$ for values by the token bundles discussed in Sect. 2.2 and represented by values of the type $\textsf {Quantities}$.

As indicated in Sect. 2.1, validator scripts get a context argument, which includes the validated transaction as well as the outputs that it consumed, in EUTXO. For EUTXO$_{\text {ma}}$, we need two different such context types. We have $\textsf {ValidatorContext}$ for validators and $\textsf {PolicyContext}$ for forging policies. The difference is that in $\textsf {ValidatorContext}$ we indicate the input of the validated transaction that consumes the output locked by the executed validator, whereas for forging policies, we provide the policy script hash. The latter makes it easy for the policy script to look up the component of the transaction’s forging field that it is controlling.

The validity rules in Fig. 5 define what it means for a transaction t to be valid for a valid ledger l during the tick $\mathsf {currentTick}$. (They make use of the auxiliary functions in Fig. 4.) Of these rules, Rules 1, 2, 3, 4, and 5 are common to the two systems (EUTXO and UTXO$_{\text {ma}}$) that we are combing here; Rules 6 and 7 are similar in both systems, but we go with the more expressive ones from EUTXO. The crucial changes are to the construction and passing of the context types mentioned above, which appear in Rules 6 and 10. The later is the main point as it is responsible for execution of forging policy scripts.

A ledger l is valid if either l is empty or l is of the form $t::l^{\prime }$ with $l^{\prime }$ valid and t valid for $l^{\prime }$.