A blockchain’s history can be viewed as its global state. Yet, to validate new transactions, a node only requires a portion of this history. With each block added, the blockchain expands, making it inefficient to validate new transactions within a continuously growing context. In this article, we will elucidate how a global state, utilized for validating new transactions and building new blocks, is formed from the blockchain’s history.
Blockchain Is Just A History Of Transactions
A blockchain can be viewed as a history of transactions. Each block in the chain contains a list of transactions, and with the addition of each new block, the history of the blockchain (and thus the global state) changes.
In the figure below you can see the correlation between newly appended blocks to the blockchain and the change in the global state. Each newly added block represents a state transition.
Network consensus is a crucial mechanism that ensures all nodes (the honest majority of nodes) in the network agree on the current state of the blockchain. The consensus allows the network to safely transition from one state to another. In other words, before a new block can be added to the blockchain, all nodes must agree on its validity.
For the blockchain to function correctly, the global state on all nodes of the distributed network must be the same. This consistency is necessary to ensure the integrity and security of the blockchain, and to facilitate further state changes.
The transition to a new state across all network nodes doesn’t happen instantaneously. It’s a progressive process due to network latency, albeit a brief one. In the Cardano network, the transition to a new state is initiated at the node that produces a new block and concludes when all network nodes have received this block. If the block is valid and thus accepted by all nodes, a state transition has taken place, accompanied by a change in the global state.
Indeed, the alteration in the global state doesn’t solely reflect a change in the blockchain’s history. The context for validating the subsequent block transforms as well. This context isn’t the complete history of the blockchain, encompassing all individual transactions. Instead, it’s a subset of this history, specifically the active set of UTxOs, or also the UTxO set.
In the picture, you can see how each block appended to the blockchain changes the active set of UTxOs (global state for validating a new block). The UTxO set went through 5 successive changes from the beginning (STATE 0), as 5 new blocks were added.
Every node in a distributed network operates independently, maintaining its unique version of the blockchain and an active set of UTxOs. Whenever a node receives a candidate for a new block that is proposed to be added to the blockchain’s end, it must undergo validation. The inputs for this validation process are the new block and the active UTxO set. Along with other parameters encapsulated in the block header, the node is required to validate all transactions within the block. The outcome of this validation is the node’s independent decision on whether to incorporate the block into its local version of the blockchain. This identical procedure is executed across all nodes within the network.
In the picture, you can see how the validation of the new BLOCK 6, which is supposed to be an append after BLOCK 5, takes place. The input for validation is a new block and an active set of UTxOs. The output of the validation is the decision of the validator whether the new block is valid (and will be appended to the local version of the blockchain) or invalid.
UTxO Set
Every time a node appends a new block to its local version of the blockchain, the local version of the UTxO set changes as well.
The UTxO set comprises all UTxOs that have been created as transaction outputs and have the potential to be spent in future transactions. Therefore, it represents only a fraction of all UTxOs present in the entire history of the Cardano blockchain.
Let’s briefly explain UTxO in the context of the global state.
UTxOs are independent and immutable objects that can be spent only once. When they are spent, they must be spent entirely. UTxOs are disposable objects.
Once a UTxO is created as an output of a transaction, it remains unchanged until it is spent in a new transaction. When it is spent, it is consumed entirely and a new UTxO is created as an output of the new transaction.
When a transaction is submitted, it refers to one or more UTxOs as inputs, which are intended to be spent.
When an input UTxO is consumed, it results in the creation of a new UTxO, or possibly multiple new UTxOs. The cumulative value of the input UTxOs in a transaction must be equal to the total value of all output UTxOs.
Regarding transactions, the validator’s job is to check that:
- All input UTxOs are indeed part of the current UTxO set, i.e., they are unspent and exist in the ledger.
- The total value of input UTxOs is greater than or equal to the total value of output UTxOs, ensuring the conservation of value.
- The transaction is correctly signed by the owners of the input UTxOs, ensuring only the rightful owners can spend the UTxOs.
The history of the blockchain can be seen as the graph of all UTxOs, both spent and unspent. This graph provides a complete, auditable history of all transactions that have ever occurred on the blockchain.
In the image below you can see how UTxOs are consumed by transactions. Output UTxOs (green) become input UTxOs (red) in new transactions. All UTxOs that have not been spent (blue) represent the subset of the global state that is needed for the validation of new transactions. All blue UTxOs can become transaction input, i.e. be spent. Green UTxOs have already been spent, so they cannot be spent again.
The present state of the blockchain, which is required for the validation of a new block (new transactions in the new block), can be depicted by the collection of all unspent UTxOs. These are incorporated into the UTxO set.
Therefore, to validate new transactions, it’s not necessary to be aware of the complete history of the blockchain (or to have it in active memory). Instead, only the active set of unspent UTxOs (all blue UTxOs) is needed. However, obtaining an active set of UTxOs typically involves processing the entire history of the blockchain, starting from the Genesis block.
It’s important to note that the active set of UTxOs also encompasses those UTxOs that were created in the past, meaning in previous states.
In each state in the figure, one block was produced. In the new state N+5, the UTxO set containing UTxOs from states N+2, N+3, and N+4 will be used for transaction validation. In the new block that was produced in state N+5, there are transaction 14 trying to spend UTxO from transaction 10, and transaction 15 trying to spend UTxO from transaction 11.
In state N+5, a new block has been appended to the blockchain. Thus also new UTxOs have been created and they have been inserted into the active set of UTxOs. Within the same state transition, all consumed UTxOs have been removed from the active UTxO set.
In the picture, you can see the UTxO set, which is made up of all unspent UTxOs regardless of transitions between states.
Users are constantly submitting new transactions, some of which may be submitted concurrently. The network’s objective is to process all transactions, meaning it aims to incorporate valid transactions into the blockchain. The addition of a new block to the blockchain signifies a shift in the global state.
New transactions reference UTxOs from the UTxO set. The UTxOs from the set serve as inputs for all transactions and represent a portion of the change that will occur when a new block is appended to the blockchain. All UTxOs that were inputs of transactions in the newly added block will be removed from the UTxO set.
Each transaction in the newly added block includes one or more new UTxOs that are incorporated into the UTxO set. It is another portion of the change.
When a new block is appended to the blockchain, the node concurrently removes spent UTxOs from the UTxO set and introduces newly created UTxOs into it.
The image depicts the transformation in the UTxO set. In STATE 0, you observe six transactions that will be incorporated into the subsequent block. The red UTxOs are those that serve as transaction inputs, meaning they are to be spent. The green UTxOs are those that are to be created. STATE 1 represents the state following the addition of a new block. The red UTxOs have been removed from the UTxO set, and the green UTxOs have been added. Consequently, all UTxOs in the UTxO set are spendable. Think of the newly added green UTxOs as blue.
The transactions in the picture refer to the block that was built and submitted to the network in STATE 0. In STATE 1, it was already added to the blockchain. A new block is already being created in STATE 1, which is not shown in the picture. You can imagine new transactions that reference UTxOs in the UTxO set.
Conclusion
Indeed, each UTxO can only be spent once, a fundamental rule that aids in thwarting double-spending attacks. Once a UTxO has been utilized, it cannot be reused as an input for another transaction. During block validation, it’s straightforward for the validator to confirm that all UTxO inputs are unique and exist within the UTxO set. The architecture of the UTxO model, coupled with the transaction validation process, simplifies the task for a block validator to identify and avert potential double-spend attacks. This is among the primary security features of blockchain technology.
The UTxO set, composed of single-use objects, offers an advantage as it facilitates a high level of parallelization within the network. The validation of transactions is independent of each other, mirroring the independent consumption of UTxOs. Another benefit is the ability to validate transactions locally before submission, ensuring they will also pass the network validation. Both local and network validations depend on the same input UTxOs. In the period between local validation and network validation, before the transaction is included in the block, the input UTxOs remain unchanged. Therefore, there should be no reason for the transaction to fail.