The Trust Machine — Part3: Quadruple entry accounting
By: Hans Moog
Tags: Dlt, Trust, Iota, Cryptocurrency, Revolution

In the last two parts of this series of blog posts, we discussed fundamental facts about DLTs and introduced the idea to use real world trust as a sybil-protection mechanism.

In this part we are going to get a little bit more technical and discuss one of the key innovations of IOTA — the quadruple entry accounting (formerly known as the parallel reality based ledger state) — which forms the basis for IOTAs unique ledger.

The history of accounting

To understand the design decisions behind this form of accounting, we are going to discuss the different forms of accounting used throughout human history in chronological order.

Single entry accounting

The history of accounting starts tens of thousands of years ago in early Mesopotamia. Advances in reading, writing and mathematics gave rise to the first accounting system — the single entry accounting.

It is a very simple form of ledger that most people are familiar with and it usually consists out of a list of entries with 3 columns. Increases of the balance are usually shown in black and decreases are shown in red (with parenthesis):

This ledger is very easy to understand and we are still using this form of accounting today (e.g. for small businesses or keeping track of the expenses of a household).

It’s biggest problem is that it is very hard to audit or generate reports. Imagine trying to answer the Question of: “How much money was spent on rent?”.

The only way to answer this question would be to go through every single entry in the ledger and sum up the corresponding values if they fit a certain category (which is a very inefficient and tiresome process — especially for large ledgers).

Double entry accounting

As societies became more complex, the economic activities performed by humans also got more complex and the need for a different and more efficient accounting system arose.

In 1494 an Italian monk named Luca Pacioli released a manuscript in which he describes a new form of accounting — the double entry accounting.

It works very similar to the single entry accounting but instead of maintaining just a single account that represents e.g. an entities cash holdings, it maintains several different accounts that are separated according to their topic and/or belonging to a certain identity.

Note: The collection of accounts related to an economic entity is called a book and the act of maintaining these accounts is called book keeping.

Whenever we create an entry in our cash account, we also create a corresponding but inverted entry in another account. After all, every increase in our cash account corresponds to a decrease in somebody else’s cash account (and vice versa).

Looking at the different accounts, it becomes very easy to answer all kinds of questions regarding the operational status of an organization, but it also becomes easier to audit the validity of i.e. reported tax numbers (since the books of different organizations need to have matching numbers).

This massively boosted transparency and reduced fraud and corruption which allowed for even bigger economic actors to arise.

Triple entry accounting

While the double entry accounting improved the auditability of economic actors, everybody was still maintaining their own separate books and auditing them was a manual and tiresome process that was often prone to errors and mistakes.

Distributed ledger technology now introduces a third entry — the transaction (which was shown as a dashed line in the previous image) — and persist it on a public and tamper proof ledger. It contains the instructions how to modify the ledger state. Nodes taking part in a decentralized ledger agree to a starting state (the genesis) and then simply apply the same transactions to arrive at the same result.

For the first time in human history we were able to have a completely open and secure way of collectively maintaining a shared ledger, giving rise to electronic cash and programmable money.

While the ideas of the tripple entry accounting are inspired by the double entry accounting where every transaction modifies the balances on two sides (sender and receiver), it uses a slightly different terminology which aims at generalizing the concepts discussed before.

Instead of tracking balances associated to different accounts (which were only necessary to make the ledger easier to read for humans), the ledger tracks balances individually. Whenever a balance gets spent by a transaction, it is marked as spent and new balances are created that are the result of the corresponding transaction.

Balances can only be spent in total and every transaction has to create new balances according to a certain smart contract (e.g. create exactly the same amount of funds as were consumed). Transactions can accordingly be seen as small programs that use existing balances as inputs to create new balances as outputs.

One way to model this, is as a DAG where the transactions are the edges that connect all outputs that have ever existed.

the flow of funds forms a DAG that causally connects all outputs (balances)

The ability to spend an output is usually tied to some condition (i.e. proving access to the private key of a cryptographic address) and the set of unspent outputs at the tip of this DAG is considered to be the current ledger state.

the green (unspent) outputs represent the current ledger state

This model is called the UTXO (unspent transaction output) model and it represents one of the key innovations of Satoshi Nakamoto.

Total order in the UTXO model

A fascinating aspect of this form of ledger state is that it does not rely on a total order of events to validate transactions and applying the same transactions will lead to exactly the same ledger state, no matter in which order the transactions arrive.

applying independent transactions in a different order leads to the same ledger state

Even nodes that see dependent transactions completely out of order will still be able to arrive at the same ledger state if they simply wait with the execution until all inputs of each transaction have become known.

transaction 5 arrives before its dependent transaction 3

We call transactions whose inputs are known solid and the process of waiting for missing information solidification.

People might ask themselves, why blockchains rely on a total order if their underlying ledger is not dependent on it and the reason is very simple:

The UTXO model has no meaningful way to handle double spends. If a double spend would ever be added to the ledger then the total supply would be increased giving rise to things like unwanted inflation.

The only known way to deal with this problem is to create a shared perception of time which allows the validators to agree, which transactions should be added to the ledger state.

Bitcoins longest chain wins consensus is essentially a voting mechanism on the perception of time — a decentralized clock — which many experts often claim to be the biggest achievement of DLTs.

Quadruple entry accounting

We know from our previous discussions in the 2nd part of this series of blog posts, that the only way to establish a total order is to either make the network synchronous (by artificially slowing it down) or by limiting the amount of validators to a small group.

Considering that virtually all trade-offs in contemporary DLTs boil down to this very fundamental problem, we want to try to approach the double spend problem in a completely different way.

A new form of ledger

Instead of trying to prevent double spends from entering the ledger we want to design a new type of ledger that understands double spends and that is able to track all conflicting ledger state versions at the same time.

For this, we are going to extend the UTXO model by another dimension (quadrupel entry accounting) where every transaction and every output are associated to a container that represents a specific version of the ledger state. We call this container a branch.

In the absence of conflicts, all transactions and outputs are part of the same ledger state version which we call the master branch. Whenever transactions are found to be conflicting, they spawn a new branch that contains the conflicting transaction itself and all of the outputs that it directly or indirectly creates.

The same example as before but with transactions / outputs grouped into the corresponding branches

Branches that are formed by transactions spending the same output are part of a conflict set. Since transactions can spend multiple outputs, they can be part of multiple conflict sets.

Outputs inside a branch could be double spent another time, causing branches to recursively form sub-branches. Every branch stores a reference to the parent branch that it split off from, forming the Branch DAG with the master branch at its root. Each branch recursively inherits the ledger state of its ancestors.

Branch DAG with branches in blue / conflict sets in red / aggregated branches in orange

Branches are conflicting if they themselves or any of their ancestors are part of the same conflict set.

When booking non-conflicting transactions, we inherit their associated Branch from the outputs that are being used as inputs. If transactions spend outputs from multiple non-conflicting branches then their outputs are booked into an aggregated branch that acts as a placeholder for the list of underlying conflicts.

On top of this data structure we now define some rules that transactions have to fulfill to be considered valid:

Transactions need to create exactly the same amount of funds as they consume. Transactions may never spend outputs from conflicting branches. Transactions may never spend an output that has already been spent by another transaction in their own past (see example).

Transaction 2 is invalid according to rule 3 — it double spends its own grandfather (Output A)

With these 3 rules we can ensure that all ledger state versions will always stay consistent, maintaining a correct total supply.

After having made a decision on a conflict through our higher level consensus mechanism, we can merge the winning branch back into the master branch and prune the conflicting branches that were rejected by the consensus.

after having reached consensus we clean up the Branch DAG and merge the winning ouputs back to the master branch

This might all sound really complex at first but it is just an efficient way of storing all the different ledger state versions without having to store redundant information. Each output is stored just a single time and storing 1000 conflicting transactions will cost us nearly exactly the same amount of resources as storing 1000 honest transactions (apart from some constant sized overhead for the additional entry in the Branch DAG).

To summarize the new concepts in a few words:

Branches allow us to tell outputs of different versions of the ledger state apart. Conflict sets model the conflict relationships between the branches. The Branch DAG allows us to track the causal dependencies between the different branches (to inherit the ledger state and to check for conflicts).

Implications

Instead of having to agree on the fate of each conflict at the time of arrival, we can move the conflict resolution to a higher level, turning the ledger into a data structure that simply tracks all of the state transitions that were proposed by its users (even the conflicting ones).

This allows us to build a DLT where we no longer have to have special entities that protect the ledger against malicious writes (like miners in a blockchain). Anybody can just directly write to the ledger for free just by sharing his transaction with the rest of the network and everybody can update their ledger state completely independent of each other.

All nodes that see the same information are able to construct exactly the same ledger state versions which turns the ledger into a conflict free replicated datatype, that can be updated completely in parallel and without any kind of coordination or artificial slowdowns.

Conclusion

We have designed a new form of ledger that allows us to decouple the processing of transactions and the act of reaching consensus on the existing conflicts.

This results not just in a much more open and democratic ledger design that no longer needs middlemen that protect the act of writing to the ledger but it also removes the need for overly strict coordination between the validating nodes which will later allow us to use Satoshis principles without having to slow down the statements of the validators, causing the act of reaching consensus to become a collaborative process instead of a competitive one.

A large part of the work of the last years went into designing and conceptualizing this form of ledger. The design that now sounds very simple and elegant, was not always that simple as we had no idea how the best design would look like. After a few iterations we are now however confident, that it will not be possible to further simplify these principles any longer.

What this form of ledger proves is that it is not necessary to establish a total order of events to deal with conflicts.