UTXO Chains. Part 5

L1-validated UTXO chains (L1 smart contracts). Conclusions

(Previous: Generic architecture. L2-validated chains. Chains with validity proofs)

3. L1-validated UTXO chains

This variation of the architecture of UTXO Chains is also known as L1 smart contracts or UTXO Smart contracts. All state transition are validated on the L1 by a permissionless network of nodes, just like on Ethereum-like blockchains. This architecture does not require any L2 components for validation of transaction via global consensus or data availability, so it makes the chain trustless (here trustless means same trust as the base layer).

The main difference of L1-validated option from other architecture options of UTXO chains is that the execution layer, the VM, is implemented and is run by every L1 node as a part of transaction validation on the layer of stateless computations of the UTXO ledger. This approach makes each state transition of the chain as secure as the UTXO ledger itself. The architecture does not require any zero-knowledge cryptography nor L2 data availability, because it keeps the state on the unbounded state layer in the UTXO ledger itself, i.e. on every L1 node.

Stateless computations and unbounded state on UTXO ledger

The UTXO transactions are bounded data structures by their nature. For many use cases it is a limitation.

Stateless computations is a plugin to the constraint layer of the UTXO ledger (see the vision in Constraint-based UTXO model). We can also call it a virtual machine (VM), because it usually is an interpretation engine (a processor) with own instruction set/language and runtime memory.

The stateless computations, is invoked during evaluation of the validation constraints of the transaction. For example, the VM engine can be embedded as EasyFL function runMove(<gas budget>) which invokes Move interpreter in the deterministic context of the transaction during validation of it. Of course, the interpreter can also be any other deterministic engine, like Wasm or EVM. Several of them can coexist, if necessary, in the same library of constraint functions. This way, the constraint layer also serves as a layer of abstraction between the UTXO ledger and the VM engine.

The runMove function takes the Move executable program code and other inputs from the data deterministically supplied in the inputs to the transaction (here we skip technical details). The function call runs the attached program capped by the <gas budget>. The function call returns a a byte array as a return value.

This way we can implement any program in the Move language and attach it to the UTXO transaction. The program can implement any algorithm, for example a new complicated cryptography or smart contract algorithm.

In general, the interpreter behind the runMove function is stateless, i.e. it is agnostic about any persistent side effects. This is the way how, for example, any cryptographic algorithms can be implemented.
However, when the runMove is invoked in the validation context of a chain-constrained output with the chainID, the interpreter is provided with sandbox-ed access to the chainID-attached atomic mutable state in the unbounded state layer of the ledger.

The chainID-attached unbounded state is a key/value store without assumptions about size limits. In other words, the Move interpreter in the chain context can read and write any key/value pairs from/to the unbounded state identified by the chainID.

UTXO ledger modules: constraint layer, stateless computations and unbounded state

The unbounded state will store the Move program binary itself as well as any other persistent data attached to the chainID, just like any chain or smart contract. The result of the runMove invocation will be twofold: the side effect, a mutation of the chainID-attached persistent state of the chain/smart contract, and the root commitment to the mutated (resulting) state (usually a Merkle root). The latter is returned as a value of the function invocation runMove(<gas budget>). The root commitment to the state is used in the deterministic UTXO transaction (see below). If the execution exceeds <gas budget>, the transaction will be invalidated. In the deterministic environment that would mean user has had supplied the transaction a wrong value of the <gas budget>.

The storage cost of the unbounded state (which may be significant) attached to the chain-constrained output (usually small), must be covered with the storage deposit in the UTXO transaction. It implies a significant cost of the unbounded L1 data availability, as expected.

We keep the two layers separate for architectural reasons: they have different functions and different characteristics.

The two layers can also be implemented and used independently. There are many use cases when we need one and we do not need another. For example one-user on-ledger wallet or DID may choose to keep the whole state in the transaction itself, so it is bounded and does not need unbounded key/value store. The pure cryptographical algorithms, such as zk-validity proof validation or new hash function, are stateless too.
From the other side, a L2 dApp may want to deliver the raw mutation of the unbounded state right in the UTXO transaction. So, the unbounded state will be used for L1 data availability reasons only. In this case we do not need any programmability on the stateless computations layer: the UTXO constraints layer would do all the heavy lifting.

However, smart contract use cases like name service registry will need both layers: to keep (a) unbounded registry of names itself and (b) a program which adds/deletes names to/from the registry and ensures consistency of the registry.

L1-validated UTXO chain

Main elements and the workflow on the L1-validated UTXO chain is the following:

L1-valdated UTXO chain

• the sequencer takes the ordered batch of requests and calculates the next state with own instance of the VM (the VM is a public value).
  The sequencer with the VM produces the state mutation and the UTXO transaction. It also calculates <root>commitment of the next state and actual <gas budget>. (It must be emphasized that due to the determinism of the environment, the run of the VM on L2 by the sequencer and the run of it on the UTXO ledger must be exactly equivalent and will render the same result and side effects)
• The sequencer produces the UTXO transaction of the state transition. It includes, among other things, the (a) <root>, (b) credentials of the sequencer (signature), just like in the architecture options 1 and 2.
  The sequencer also puts the mandatory constraint of equality between the supplied and calculated <root> with the <gas budget>. In the EasyFL the mandatory constraint code will look like equal(<root>, runMove(<gas budget>)) , which means that the run of the program while validating the transaction must return exactly the same value as the pre-calculated constant <root>, otherwise transaction will be invalidated.
  Note that here <root>and <gas budget>are values, already calculated by the sequencer on its VM run, so these are static values in the transaction. Thus the sequencer is equivalent to the block proposer in the blockchain.
• The transaction produced by the sequencer is submitted to the UTXO ledger. Upon transaction validation, the constraint invokes the VM program (runMove(<gas budget>)) and checks if the result is equal to the provided Merkle root hash, as prescribed by the constraint. This way, transaction will only be valid on the node if the node’s Move interpreter, when run with same inputs, gives the same state root within the same gas consumption. This way we preserve UTXO determinism while using unbounded computations.
• If the run of the Move interpreter on the node will result in a different outcome than was proposed by the sequencer, the transaction will be invalidated.
• Obviously, result of the transaction validation, including the side effect on the unbounded state, must be exactly the same on all nodes in order to reach global consensus.
  The unbounded state is incrementally computed by an arbitrary deterministically known program. The whole state will never be transferred over the wire between nodes.
  This is the L1 smart contract semantics as it is known in other L1 blockchains like Ethereum.
• the mutation of the unbounded state of the chain, attached to the chain-constrained output, must be atomic with the transaction, the finality of the transaction must be the same as the finality of the the unbounded state mutation. In other words, either both the UTXO transaction and the computed unbounded mutation are committed to the ledger, or none of them.
• Running the VM on each node ensures the trust to the state transition is same as trust to the UTXO ledger as a whole, i.e. trustless. No need for validity proofs.

(Note 1. The check of the gas budget is a part of the deterministic transaction validation condition, i.e. when submitting the UTXO transaction the gas cost is already known, user statically puts it into the transaction itself. This may seem strange, but it is a direct implication of the UTXO determinism, which ultimately enables parallel ledger updates and scalability. It is all connected!)

(Note 2. The deterministic gas consumption cap must be combined with the burn of some valuable resource, to make the user pay for calculations on L1. We do not need it on the constraints-layer of the UTXO, because the computations and related costs statically bounded by the transaction bounds. However, VM plugin computations on the stateless computations and unbounded state layers are not bounded by intention. The discussion on approaches to gas costs/fees are beyond the scope of the current writeup)

So, the VM is run on each L1 node. This make each transition on the UTXO chain a trustless state transition of the chain/smart contract on L1.

Advantages and tradeoffs side-by-side

The following table presents a rough comparison of all 3 options/architectures of UTXO Chains. It is clear that advantages come with tradeoffs. This indicates different target use cases for each option.

Conclusions

• the pure UTXO ledger makes it possible entire range of smart contract platform architectures
• The mandatory pre-requisite for the UTXO Chains is a DAG-based consensus protocol, which offers fast probabilistic finality and defers total ordering of transactions as long as possible, i.e. until the deterministic finality
• The UTXO Chains offers a multi-chain system architecture with parallel smart contracts, unprecedented scalability, throughput and trustless and bridgeless cross-chain composability
• The UTXO Chains covers entire spectrum of trust assumptions with respect to the validation of chains and smart contracts: from committee-validated chains with social/behavioral trust assumptions on L2, to fully trustless options with the same security as the UTXO ledger on L1 itself

We proposed 3 different options of architectures for the UTXO chains:

• the fastest and with lowest transaction cost is L2 validated chains.
  The main tradeoff is in trust assumptions: the validity of state transitions and therefore the security of the chain totally depends on honesty of at least 2f+1 of chain validators. Another tradeoff is L2-related complexity of the setup
• the simplest (UX-wise) yet slowest and the most costly is L1 validated UTXO chains also known as L1 smart contracts. It is a trustless setup.
  The main tradeoffs are (a) costly execution and storage of the chain’s state on each L1 node and therefore limited throughput and (b) limited functional power of the VM
• the UTXO Chain with validity proofs also is a trustless setup. It offers high scalability and throughput.
  The main tradeoff is relatively high execution latency and cost: execution layer must not just compute next state transition but also must compute the validity proof (zk-proof) of it. Also, the notorious complexity of the zk-tech.

Each of those configurations of the UTXO Chains have different target classes of use-cases and different adoption strategies.

The L2-validated UTXO chains should be aimed at big setups, which are based on the real-world identities and the social trust. It normally is a permissioned or semi-permissioned setup. It is ideal for big (inter-)corporate and public sector distributed ledgers, for example large size market infrastructures, logistical networks of national, EU and global scale with the requirements of many thousands of TPS.

The UTXO chains with validity proofs, could be aimed at the same target use cases as the L2 validated UTXO chains, with similar scalability potential. Due to it being trustless, this is also a very promising direction for the DeFi dApps and networks. At the moment (the end of 2022), the main problem is the complexity and overhead of the execution layer, it is still too early to estimate its real practical overheads. This variation could be seen as equivalent of the Ethereum zk-rollups

The L1-validated UTXO chains (L1 smart contracts) is the simplest from the point of view of the end-user and the developer. It is a completely trustless, parallel, asynchronously composable and permissionless smart contract platform, which does not require any complexities of zk-cryptography. Same time, it is the least performant and most costly (per transaction) setup. The main target use cases for this option could be multi-user L1 network infrastructure, like Name Service, Reputation and similar trustless registries and unbounded data set, for example multi-user digital twins. It also has a significant DeFi potential where limited throughput and limited liquidity is enough, such as specialized DeX-es and other DeFi dApps.

Another promising class of use cases for L1 smart contracts is anchoring of optimistic rollups to the UTXO ledger on L1.

Note, that many classical crypto use cases, such as native tokens, swaps, NFTs and similar can be implemented using constraint-based UTXO ledger itself. It may need stateless computations layer, but it not always needs the costly unbounded state layer.

A single-owner dApps, like DID or other digital twins do not require non-deterministic requesting nor distributed sequencing. It can be performed by centralized applications/wallets, i.e. directly submitting state transitions to the UTXO ledger with stateless computations and unbounded state layer.

And finally:

All 3 options share a significant part of the codebase, specifically leaderless distributed sequencer and L2 data availability layer, the most complicated ones. Those parts are already implemented in the the Wasp node.

The L2-validated UTXO chain (option 1), is implemented in its entirety as the IOTA Smart Contracts in the Wasp node.

All 3 options of the UTXO Chains can survive on the same UTXO ledger.

THE END
— — — — — — — — —

All posts of the UTXO Chains series

1. Introduction
2. State and determinism
3. Chain constrains and sequencing
4. Generic architecture. L2-validated UTXO chains. UTXO chains with validity proofs
5. L1-validated UTXO chains (L1 smart contracts). Conclusions (this post)