State transitions defined

A distributed ledger can be defined as a global state machine, which executes state transitions through transactions. What is a state you might ask? In the particular case, a state is an abstract (or concrete) set of data containing any information relevant to the latest available iteration of the ledger. For example, a Bitcoin state includes the UTXO (Unspent Transaction Output) set, enabling users to “spend” the existing outputs and create new outputs within a transaction, enacting a state transition which results in state machine to removing the “spent” outputs from the UTXO set and adding the newly created outputs to the aforementioned set. Ethereum state, on the other hand, is stored in a tree-like cryptographic structure called Merkle-Patricia tree, where each leaf represents an account and contains the accompanying data, the contents of which can be updated via a transaction, enacting a transition of the Ethereum state. So the state transition can be defined as a transaction which instantiates a transformation of a global state. Dusk Network protocol combines two of the aforementioned state representations, meaning that a global state of Dusk Network is represented by both the UTXO set (and the accompanying nullifier set, which will be explained in more detail in our upcoming article on transaction models) and the Merkle-Patricia tree. State transitions can only be initiated through transactions, making the global state completely deterministic.

The halting problem

In his seminal paper published in 1936, Alan Turing had formalized a “halting problem”, which proves the impossibility of determining whether a Turing complete machine will ever return an output or not based on the deployed programme and the input value/s. A system which is capable of simulating a Turing machine is deemed to be Turing complete with the “halting problem” being innate to every Turing complete system. To be able to deploy a Turing complete Virtual Machine, Ethereum has introduced a notion of “gas limits” as a workaround which successfully prevents a programme from infinitely executing by limiting the number of computational cycles that a machine can perform before halting, effectively proposing a distributed quasi-Turing complete machine. Dusk Network protocol follows a similar paradigm to Ethereum, limiting the number of computation cycles that each transaction may consume.

Added complexities

The added requirement of anonymity puts an additional strain on the network in terms of the state transition complexities. In the case of Bulletproofs, our current zero-knowledge proof scheme of choice, verification time scales linearly with the circuit size. In other words, the verification time increases at the same rate as the proof complexity. While not an issue for simple DUSK transfers, where the transaction cost is trivially correlated to the number of inputs spent and outputs created, transactions involving contract calls may require vastly more complex circuits and as a result, drastically varying verification costs, making the process of metering the computation costs more difficult which may make the protocol vulnerable to some distributed denial of service (DDoS) attacks. As a preventative measure, Dusk Network protocol defines the cost of the verification of circuits based on the number of gates included in the aforementioned circuit (with a constant price set per gate) when the circuit is published on-chain along with the contract. Once Dusk Network protocol transitions to PLONK (to be discussed in an upcoming article), metering the verification complexity will no longer be an issue for the protocol as PLONK verification times are constant no matter the circuit size.

I/O access

Multiple research papers highlight that I/O access instructions are in amongst the most computationally costly operations available in the Ethereum Virtual Machine (EVM). I/O stands for “input/output” which in case of Ethereum refers to the access to the global state of the machine. Due to the fact that Dusk Network protocol only stores contracts and their corresponding data in the Merkle-Patricia tree, the cost of accessing the data stored in the aforementioned tree will be noticeably lower in comparison to EVM (as Ethereum Merkle-Patricia tree stores the external account data alongside the contract data).

So what is next?

In Part IV, the final part of the series, we will outline the ways in which the network participants are incentivized to retain the security of the protocol as well as the measures deployed to penalize malicious behaviour.

TLDR:

A digital currency protocol can be defined as a global state machine, which executes state transitions through transactions. It is vitally important for a protocol to be aware of the current state of the network, which basically means the latest representation of the related data (e.g. balancesheet featuring all accounts).

In the Dusk Network protocol a state is represented via a set of outputs and contract-related storage with the state being updated with every new transaction. The utilization of complex data structures and interactions is difficult to achieve without a Turing complete state machine.

Deploying a machine capable of performing arbitrary computation allows us to perform a wide range of functionalities. A heavier computation is associated to be more time and resource consuming. The computational complexity of state transitions is increased due to the deployment of zero-knowledge proofs. This especially apparent with Bulletproofs, as the verification times increase linearly as the proof complexity increases.

Within Dusk Network the computational complexity is drastically decreased by 1) imposing an artificial limit on the number of sub-operations (i.e. computation cycles) a transactions can require. 2) proof verification through PLONK, as its verification times are constant and 3) limiting the data stored in the Merkle-Patricia tree to the contract data (i.e. limiting the number of I/O operations).