A constraint-based UTXO model (1/4)
Part 1. Vision. Architecture
Part 2. Ledger models. EasyUTXO
Part 3. Transaction validation. EasyFL
Part 4. Unlocking the inputs. Examples
Introduction
Once I carelessly promised to write some posts on UTXO programmability, Turing-completeness, UTXO smart contracts and other ledger-related topics. Hopefully, I will come to these and other topics later.
Meanwhile, here I aim to introduce my recent personal research and prototyping effort, the working constraint-based UTXO ledger model, a kind of informal report. The concept is implemented as a Go library with language compiler, runtime engine and a UTXO ledger prototype. It can be found in the EasyUTXO repository.
This blog post is informal, yet, inevitably, technical. It assumes a good understanding of how UTXO works in general and what it is useful for, so we skip general introductions and preliminaries. It also assume some familiarity with the Stardust ledger by IOTA Foundation. The intended audience is software engineers and anybody interested in technicalities and strategies in distributed ledger technologies. Everybody is welcome to play with these concepts and the code.
The vision
The initial motivation to the project was to provide a simple yet secure and powerful UTXO programmability model for the Stardust UTXO ledger, implemented in the iota.go library (currently the basis for the Shimmer network and IOTA Smart Contracts). In simple words, we need a replacement for hardcoded output types and feature blocks of the Stardust. We want to be able to modify Stardust ledger transaction model without upgrading all nodes in the network. Many well-known use cases ask for that.
It is tempting to go straight and implement a universal VM, such as Move or some WebAssembly engine as a main transaction validation engine, with gas budgeting and other powerful yet heavy runtime machinery. This approach would be the most generic, with all its virtues and tradeoffs. That would allow any UTXO transaction logic to be programmed in the transaction, in a similar (but not equivalent) way how they do it, for example, in Ethereum smart contracts.
Here, however, we take a more careful and less brute force approach. We aim to preserve a bounded nature of the UTXO model, its simplicity and minimalism. Runtime simplicity is the best known trait of the UTXO ledger. Each UTXO transaction is essentially a circuit, which makes the model very simple, secure, robust, performant and, yes, the Holy Grail, formally verifiable (in general). The whole UTXO ledger is an append-only circuit as well, due to the fact that each transaction only consumes (= is wired to) a local fragment of the global state.
It seems the simplicity was the main, if not the only, reason why Satoshi implemented UTXO in Bitcoin, because otherwise it makes little sense to use UTXO instead of global accounts on a totally ordered blockchain.
Meanwhile, UTXO in theory, allows parallel validation of transactions and parallel writes to the global ledger, provided the consensus protocol, such as the Tangle, supports that. This is our ultimate goal.
We want to preserve all this practical minimalism of programmable UTXO by implementing a constraint-based machine at the core. We envision extensions and layers plugged into the core constraint-based ledger to augment power of the computation model without limits.
(Note. When we talk about computation model, we assume scope of computations of one transaction)
The EasyUTXO model and implementation brings programable functional constraints, expressions in the functional language, as a replacement for hardcoded output types and feature blocks of Stardust. Constraints can be added right inline to the transaction or to the ledger via globally available libraries (“unconsumable UTXOs”). This enables programming the behavior of the outputs and transactions needed for many use-cases such as DeFi or zk-validity proofs.
The architecture
We envision an extendable, layered architecture of the UTXO ledger. The stack starts with core constraint layer and extends up to the UTXO smart contracts:
- the constraint layer (also UTXO transaction layer) is a core. It is based on bounded UTXO constrains, so this is a classical UTXO. Constraints are expressed in a functional programming style. It offers programmability, unlike hardcoded configurable logic of Stardust. Flexibility of programmable constraints covers most of UTXO use-cases, including those which are often attributed to smart contracts. User interaction with ledger’s other components happens through this layer, i.e. by submitting transactions to the ledger;
- the layer of stateless computations is an universal engine plugged into the constraint layer as functions of the constraint language. It implements a VM with “normal”, procedural programming. The VM program will be run by invoking its interpreter from functional constraints, as a function call, right from the transaction. A good candidate for such VM engine is Move environment, but otherwise the constraint layer completely abstracts the VM from the transaction layer, so it may also be Pluto, Haskell, WebAssembly, EVM etc.
The programs will be delivered to the transaction and the VM globally as “unspendable UTXOs”. These programs will be used to extend constraint predicates to the search space where you need loops (like “check if X exists”, or “for each X such as..”) or unbounded data structures, such as maps or arrays. The stateless computations layer will enable dynamical extension of the constraint-based ledger with complex stateless algorithms which are not possible in the bounded constraint layer, such as complex cryptography: new hash algorithms, signature schemes, ZK validity proof verification and so on; - the unbounded state layer is a layer of persistent unbounded data, as opposed to the bounded UTXO transaction layer. The unbounded state, will be atomically committed in the bounded UTXO transaction layer in a succinct way (a Merkle root or similar). The unbounded state layer will be accessed by the stateless computations layer under the same trust assumptions, i.e. the ledger will ensure data availability for the VM. The VM program will be able to maintain unbounded registries and sub-ledgers in the persistent state. This will enable the Turing-equivalent state machines for UTXO chains.
- UTXO smart contracts (UTXO chains), a Turing-equivalent state machines on the ledger, will be built by adding a sequencer on top of the UTXO ledger. The sequencer will provide serialized access to the smart contract state, committed in the chain-constrained UTXOs (see on chain constraints below).
The sequencer is a necessary component because the pure UTXO ledger by itself does not provide efficient sequencing of the access to the state. Bitcoin, Cardano, Fuel etc does that by ultimately putting concurrent UTXOs into the totally ordered blockchain, so there the L1 blockchain acts as a sequencer. The tradeoff, however, is rejecting all but one of concurrent attempts to consume the same state (independent requests can go in parallel). This severely limits throughput of the platform. The serialization of access to the atomic state of the smart contract is a prerequisite for any performant smart contract platform, but that pushes us to the side of execution-based transaction model (see next post).
It is not our intention to cover here this broad topic around architectures of the UTXO smart contracts/UTXO chains. The UTXO chains wrap L1 and L2 VMs with and without ZK/validity proofs in one modular architecture. We will hopefully come to these questions in later posts
The EasyUTXO is a first step to the vision above. It implements a UTXO constraint layer. This is a classical UTXO ledger (yet programmable). Below we will explain how constraint-based EasyUTXO ledger works.
(Note 1. All the reasoning here does not involve any concepts outside the strictly ledger realm. The UTXO ledger and its dwellers, such as assets, smart contracts, transactions are a well defined concept by itself, it does not require messing with other DLT concepts such as consensus, realities, finality, nodes or decentralization. To preserve our sanity, we better not mix the two realms in one pot)
(Note 2. These posts do not intend to create any kind of ‘narratives’ for the community to follow, such as ‘L1 smart contracts’ or similar, but rather concentrates on architecture design considerations, the why-s and why-not’s. So, it is a techie talk)
In the next posts we will discuss in detail the EasyUTXO model and reasoning behind it. With examples.
