Transactions

A transaction is used to move tokens from one address to another. For example, let's say you want to send 1 HTR to your friend who owns the address HCAQb2H5EUqv9AoThwHQcibZe5nvppscMh. To do this, you will create a transaction that moves tokens from your address to your friend's address. After the transaction is created, you will propagate it into Hathor's network, and the transaction will soon be confirmed by the network.

A transaction has the following main parts (others are omitted for clarity):

1. Unique Identifier (tx-id)
2. List of Inputs.
3. List of Outputs.

Technically speaking, a transaction moves tokens from its inputs to its outputs. Each input points to the output of another transaction, and we say that this input is spending that output. So, simply put, a transaction spends its inputs and transfers them to its outputs. Outputs may be spent only once, so we say that an output is either spent or unspent. When an output is unspent, it is called UTXO, i.e. unspent transaction output.

In the image above, we say that Transaction 3 is spending outputs from Transaction 1 and Transaction 2. More specifically, we say that Input 1 of Transaction 3 is spending the first output of Transaction 1, while Input 2 of Transaction 3 is spending the second output of Transaction 2.

Each output is associated with one address, and one address may be associated with many outputs. The balance of an address is calculated as the sum of all its unspent outputs.

Here is an example of a transaction with one input and one output in JSON format. Notice that it has some fields we haven't discussed yet. In fact, they are not necessary to understand how transactions move tokens from one address to another. The address of the output is encoded in the script field.

{
  "tx_id": "00001bc7043d0aa910e28aff4b2aad8b4de76c709da4d16a48bf713067245029",
  "nonce": 33440807,
  "timestamp": 1579656120,
  "version": 1,
  "weight": 16.827294220302488,
  "parents": [
    "000036e846dee9f58a724543cf5ee14cf745286e414d8acd9563963643f8dc34",
    "000000fe2da5f4cc462e8ccaac8703a38cd6e4266e227198f003dd5c68092d29"
  ],
  "inputs": [
    {
      "tx_id": "000000fe2da5f4cc462e8ccaac8703a38cd6e4266e227198f003dd5c68092d29",
      "index": 0,
      "data": "RzBFAiEAyKKbtzdH7FjvjUopHFIXBf+vBcH+2CKirp0mEnLjjvMCIA9iSuW4B/UJMQld+c4Ch5lIwAcTbzisNUaCs+JpK8yDIQI2CLavb5spKwIEskxaVu0B2Tp52BXas3yjdX1XeMSGyw=="
    }
  ],
  "outputs": [
    {
      "value": 1,
      "token_data": 0,
      "script": "dqkUtK1DlS8IDGxtJBtRwBlzFWihbIiIrA=="
    }
  ],
  "tokens": []
}

UTXO vs Account Model

Every blockchain, no matter which transaction model it uses, qualifies as a stateful system. Stateful systems are those that can be returned to again and again, like online banking or email. They’re performed with the context of previous transactions and the current transaction may be affected by what happened during previous transactions.

This is the exact way a blockchain works: its entire purpose is to record past events and user interactions. With each new block, the system undergoes a state transition that happens according to the state transition logic defined in its protocol.

In fact, the user interactions, mostly transactions, are broadcast to the network, and with each new block, a set of them is permanently recorded. The balances of the transacting parties are updated when the system transitions to the new state. The difference between the UTXO and the account model lies in the way the bookkeeping is handled. With bookkeeping, we mean recording the state and transitioning from one state to another. The Hathor blockchain implements the UTXO model.

The first significant difference between the UTXO and Account balance models is how the state of the system is recorded. In the UTXO model, the movement of assets is recorded as a directed acyclic graph (DAG) between addresses, whereas the account model maintains a database of network states.

Recording the State of the System.

The graphic above shows a directed acyclic graph of the UTXO model on the left. Each state represents a block in the blockchain. Each transaction output comprises a node in the DAG, and each transaction is represented by one or more edges originating from a transaction output. Hence, an unspent transaction output does not have an edge originating from it. In the example above, the transaction outputs 3, 5, 6, and 7 are unspent.

On the right, the graphic shows a representation of the different states in the account model. With each new block, the state of the system is updated according to the transactions contained in the block. The number of accounts remains constant and independent of the number of transactions conducted, as long as the number of users remains constant.

In the UTXO model, the entire graph of transaction outputs, spent and unspent, represents the global state. In the account model, only the current set of accounts and their balances represents the global state. In the example above, this is the set of accounts A, B, and C and their respective balances.

The conceptual difference is that the account model updates user balances globally. The UTXO model only records transaction receipts. In the UTXO model, account balances are calculated on the client-side by adding up the available unspent transaction outputs (UTXOs).