UTXO Chains. Part 4

Generic architecture. L2-validated chains. Chains with validity proofs

11 min readDec 28, 2022

In the last two posts we will describe 3 main architectural variations of the UTXO Chains. All three are based on the same generic architecture, however they have different underlying trust assumptions. The three are:

L2-validated UTXO chains. It is the architecture of ISC
UTXO chains with validity proofs. State transitions are validated on L1 by checking provided validity proofs (zk-proofs). Similar to zk-rollups.
L1-validated UTXO chains. It also is known as L1 smart contracts, when state transitions are validated by running VM on every L1 node, like smart contracts on L1 blockchains.

All 3 options can co-exist side by side on the same UTXO Ledger: it is a choice of the chain, not of the UTXO ledger.

In this post first we will cover generic architecture of UTXO Chains and options 1 and 2.

Generic architecture

Main elements of the system:

UTXO chain itself. It is the construct on the UTXO ledger which was discussed in the previous post. The structure of the UTXO Chain is essentially the same for all 3 options. Its function is to provide objective and deterministic view on the chain/smart contract globally in otherwise non-deterministic UTXO ledger state by keeping the state or state commitment in the chain-constrained UTXO.
sequencer. It was discussed in the previous post. The sequencer is essentially the same for all 3 variations of UTXO Chains. The main functions of the sequencer are (a) to produce ordered batches of requests to the chain/smart contract, (b) to invoke execution (the VM), (c) to submit deterministic state transition transaction to the UTXO ledger. The sequencer may also be seen as an analogy to the block proposer in the blockchain
data availability (DA) layer. Depending on the approach, it may be either on the the DA subnet (on L2), or it may be on the unbounded state layer on the UTXO ledger (on L1). It can also be a combination of both. The function of the DA layer is to make the state of the chain/smart contract available for the execution of the state transition on the VM
execution layer or the VM. The exact functions and implementation of the execution layer depends on the particular variation of UTXO Chains. Its common function is to compute the next state from the deterministic inputs prepared by the sequencer. It produces the (a) the state mutation (the state ‘delta’), (b) commitment to the new state (the Merkle root) and optionally (c), the validity proof (aka zk-proof).
Execution layer may be on L2, then the VM may implement with validity proving (zk-proving, zkVM) or be plain execution without any proving. Alternatively, it may be on L1, then it runs in the context of the transaction validation, i.e. is invoked from the UTXO constraint layer.
The choice of the approach to the execution layer is a tradeoff between trust assumptions/security and performance. It may be individual for each UTXO chain

The generic architecture of UTXO Chains is somehow similar to the narrative of the modular blockchains.

Cross-chain transactions

Each UTXO chain is a separate parallel state, so the unbounded state, committed in the UTXO chain can itself contain a ledger, shared among many atomically composable smart contracts in it, i.e. a blockchain.

The VM of the chain runs the program P attached to the chain on the state(T) and produces transaction TX = P(state(T), R1, …. Rn), which will always contain chainID-constrained output as one of the produced outputs. Let’s imagine the R1, … Rn are the on-ledger requests (UTXOs) from the backlog of the chain, consumed by the transaction TX.

The program P is a smart contract program, attached to the chainID of the chain A. The programs constructs the transaction TX and it may also produce outputs R’1(c1), .. R’m(ck), UTXOs in it, which contain on-ledger requests to some other chains c1, ..ck. These R’1(c1), .. R’m(ck) will be cross-chain requests between chain A and respective chains ci.

This is the way how two parallel states (chains) interact/transact by sending assets between them: “sending” UTXOs with the attached assets as on-ledger requests. The sending chain produces the UTXO/request, the target chain consumes the UTXO/request.

Cross-chain interaction between UTXO chains. Trust areas overlap on L1

The characteristics of cross-chain transacting between UTXO Chains:

it is trustless. It means the asset attached to the request/UTXO R’(B) by chain A will reach the backlog of on-ledger requests of the chain B upon settlement of the chain transition transaction of A. The trust involved is a trust to the UTXO ledger in L1 and nothing more.
It is a trustless (guaranteed) delivery without possibility to steal assets in between. So, it is a bridgeless cross-chain transacting over the UTXO ledger.
it is an atomic transfer: the target chain B acquires control over the assets of R’(B) only when the state transition on A is confirmed
it an atomic mass-sending: either all R’1(c1), .. R’m(ck) will reach their target backlogs, or none of them
R’(B) it is non-deterministic and asynchronous requesting of the target chain B. The sequencer of the chain B will include R’(B) into the state transition of the chain B.

Thus UTXO Chains is a multi-chain architecture. The UTXO ledger becomes a trustless and bridgeless transacting medium between UTXO chains independently on the architecture variations of each of them. One can also see UTXO Chains a sharded distributed ledger architecture: each chain is a parallel shard of a scalable system.

In a blockchain, the atomic (synchronous) composability of smart contracts on one atomic state means that two smart contract can call each other without any additional trust between them. This is the kind of composability on Ethereum and other one-blockchain ecosystems.

Meanwhile, many UTXO chains anchored on the same UTXO layer (and the smart contracts in each of them) makes them asynchronously composable. The difference from common synchronous (atomic) composability, is that smart contracts on two chains can transact in a trustless way, just like on one blockchain, however they cannot just synchronously call each other as functions in a programmming language. Only asynchronous transacting between different chains is possible (for fundamentally the same reasons like impossibility of cross-shard synchronous calls among smart contracts in NEAR).

1. Architecture of the L2-validated chain

Let’s introduce the first variation of the generic architecture of UTXO Chains which is also known as committee-validated L2 chain.

This architectural variation is implemented by the IOTA smart contract chains (ISC), including ShimmerEVM. In detail it is described in the ISC whitepaper and is implemented in the Wasp 3 node.

The main points and workflow:

The sequencer, execution (VM) and data availability functions are performed by one monolithic entity on L2: the committee of validators, run by Wasp nodes. Each of the committee node performs all 3 functions in the committee. The committee then reaches a consensus on the result using leaderless BFT protocol
the committee collectively produces the chain-constrained UTXO transaction and signs it with the threshold signature. Each committee node uses own private key to produce the signature. It is required 2f+1 private keys to out of 3f+1 to produce a valid signature. So, the signature is a witness or proof of consensus. The committee submits the transaction to the UTXO ledger (the L1, for example Shimmer). This way the super majority of the committee controls the state/state transitions. The committee it is the only entity which can produce the state transition on the UTXO ledger
the interaction between L2 (the sequencer and the VM) and the L1 (the UTXO ledger) is deterministic, it does not involve additional trust so it is a bridgeless and therefore trustless interaction between L1 and L2 (see above in Generic architecture of UTXO Chains).
the state data (the data availability layer) is kept on L2 in the committee nodes. It is sometimes called a distributed DA committee. In addition, the state is kept in the permissionless network of access nodes. Each access node keeps own copy of the state, always valid because committed on the UTXO chain on L1
the committee used for the sequencer, data availability and the execution is a distributed permissioned configuration working under the BFT consensus. The BFT consensus assumes knowledge of each other between nodes in the committee, therefore any validator can participate in the committee only if other nodes agree: hence permissioned (this, however, does not necessarily means centralization).
the system assumes trust to the committee of 3f+1 validators under BFT assumptions: f+1 malicious nodes can stall the system, 2f+1 colluding malicious nodes can produce wrong state transition (aka fund stealing).
To prevent data availability to the valid state, a collusion among all 3f+1 nodes will be required, because even 1 valid copy of the state is enough.

The essential property of the committee-validated UTXO chain is that the security of the chain depends on the social consensus and the social trust: who are the real-world entities behind validator nodes, how the committee is formed and how validating entities will be punished for misbehavior or collusion.

Another important trait is that the L2-validated UTXO chains puts no limits on how powerful VM, the execution layer, can be. For example, the StardustVM in the implementation of ISC on Wasp is a general purpose engine which brings powerful user account abstractions for the L1 assets as well as sandbox abstractions of the VM plugins, such as EVM and WasmVM. As we will see later, other two architectural options of UTXO Chains are much more limited when it comes to the capabilities and performance of the execution layer.

The L2-validated chains is the the most performant architecture of UTXO chains of all 3, also with lowest cost per transaction. It is capable even for 1000 TPS per chain, it is perfect for large consortium-based distributed systems based on trust hierarchies.

2. UTXO chains with validity proofs

The next option of the UTXO Chains architecture removes trust assumption from the execution layer. This makes the system trustless. In simple words, the malicious majority will not be able to steal funds. This is the most significant difference from the previous option of L2-validated UTXO Chains.

The following are the main point and the workflow of UTXO chains with validity proofs:

just like in all variations of UTXO Chains, the sequencer produces a chain-constrained state transition transaction by taking the ordered batch of requests and feeding them as an input into the execution layer.
However, here the sequencer and the execution layer are separate modules, unlike monolitic option of L2-validated chains. The execution layer may be centralized or redundant, it has no effect in the validity of the computations
the execution layer (the VM) on the L2, is responsible for computing the state transition and for the producing a proof of validity of those computations, i.e. validity of the state transition. Normally the proof is some kind of succinct zero-knowledge proof, a bounded value, which can be validated by only trusting the mathematical axioms without re-running the computations on L1. This kind of VM is also called zkVM. (the details are beyond the scope of this write-up). The validity proof is provided as a part of the additional validity constraint on the chain-constrained UTXO of the transaction.
the computation by the zkVM are many orders of magnitude heavier than on usual VM. That puts practical limits on how complicated those VM computations could be. For example, it is unlikely the StardustVM run could be run on a zkVM due to its functional power and open architecture.
The sequencer takes the produced transaction and the state mutation from the zkVM. The sequencer validates state transition and signs the transaction with the threshold signature of the committee. The signing is a collaborative action among the sequencer’s nodes, i.e. it implies consensus on the state transition. This guarantees data availability on BFT majority of the committee nodes as well as the validity of the state transition before submitting it to the L1.
the chain transition transaction is constrained with (a) the sequencer’s credentials (signature), just like in other options of UTXO Chains, and with (b) the validity proof constraint.
An incorrect validity proof will cause the transaction rejected by the UTXO ledger. In other words, chain transition can only be settled if the provided zk-proof is valid. The UTXO ledger on L1 guarantees validity of the state transition.
This way the ledger makes the UTXO chain trustless, i.e. it is proven (based on mathematical assumptions-axioms) that the chain contains only valid state commitments. No party can steal funds.
This is the main difference from the L2-validated UTXO chains.
the verification of the validity proofs on the UTXO constraint layer is a cryptographic algorithm. For the performance reasons, it makes sense to hardcode the zk-validity constraint on the constraint layer of the UTXO (for example as an EasyFL function). In the UTXO on the transaction it would looks like EasyFL constraint validZKProof(<zkProof>, <state root>) or similar.
Alternatively, more flexible (but less performant) way is to implement those algorithms in the stateless computations layer of the UTXO ledger. The stateless computations layer is an universal engine, an interpreter of the code, which can run program binaries supplied right into the deterministic transaction context. Good candidate for such interpreter is Move. In that case the validity constraint on the UTXO will be a deterministic invocation of the interpreter, something like runMove(<Move program ID>, <zkProof>, <state root)).
in the simplest case, the unbounded state of the chain/smart contract itself will be kept on the sequencer (remember, it cannot be faked). This is DA option known as data availability committee. In this case, the DA-related trust will still be on the sequencer, because, in theory, the colluding majority of the sequencer’s committee could prevent 3rd parties from accessing the state data
To minimize trust assumptions even further, the state data can be distributed in a permissionless and trustless way in the DA subnet, to an unlimited number of copies. Each copy of the state will be valid, because state is committed on the UTXO ledger.
This, however, does not completely remove the need to trust the sequencer’s DA, because you will always need at least one honest node in the committee.
To remove the DA-related trust assumptions completely, the UTXO ledger can provide L1 data availability with unbounded state layer and the possibility to bypass the sequencer for state transitions.

Summary of trust assumptions of the UTXO chains with validity proofs

The validity proofs guarantee validity of state transitions. It means the chain, as a custodian of funds, can’t steel them.

Data availability is on the committee and on the DA subnet (in case we keep the state data on L2), just like in L2-validated chains.

Another availability-related trust assumption is on the execution layer, the zkVM. The zkVM cannot steal funds, however it can abuse the power and stall the chain by refusing to produce state transitions. This scenario is well known in zk-rollups.

To mitigate those risks and to make the chain truly trustless, UTXO chain would do the following:

implement the L1 data availability on the unbounded state layer in the UTXO ledger. This means (copy of) the state data will always be available permissionlessly on the UTXO ledger. Any party will be able to access it under the usual trust assumptions of the L1 (of course, scalability of L1 DA is limited and costly)
in the UTXO constraint layer we implement a possibility to bypass the sequencer if certain conditions are met. For example, after N hours of inactivity anybody can submit a state transition transaction with the valid validity proof. The L1 DA (see above) will guarantee such a possibility for any 3rd party, because the zkVM itself is a public value.

These measures will make it possible scenarios like for example mass exit. It will make the UTXO chain with validity proofs completely trustless, i.e. they will share the same trust with L1, the UTXO ledger.