A Byte of Blockchain - Week 21 : Transaction Authorization - Mining

Photo by RODNAE Productions from Pexels

Recap

Last week, we explained how transactions are initiated in a blockchain through a wallet. We ended with the below sequence of events :

1. Sender wants to send 10 BTC to Beneficiary
2. Sender's wallet searches for Sender's UTXO(s) tied to that wallet for funds which can be "spent" or "extinguished"
3. After identifying the relevant UTXO(s) for source of funds, a transaction input is generated which extinguishes or reduces the UTXO
4. The transaction is signed by the Sender's wallet
5. The transaction input contains a locking & unlocking script which are run to ensure that all the conditions regarding amount, beneficiary address etc are satisfied before transfer of value
6. The transaction is propagated to all the nodes in the network.
7. Using digital signature, the nodes validate the transaction using the transaction details and the public key.
8. The transaction forms part of the mempool (pool of unverified transactions)

After validation, the transaction needs to be authorized. Why?

Till a transaction is authorized, it is not part of the ledger and hence cannot be considered as a legal transaction. Authorization ensures that the transaction is permanently part of the ledger and cannot be altered. When a funds transfer is authorized in a core banking system, the entry is "sealed" in the system where sender's account is debited and beneficiary's account is credited thereby proving that the sender has actually paid the beneficiary.

Nodes (again!!)

In a blockchain, the above functions of validation & authorization are carried out by nodes using underlying system algorithms & cryptography. Let us again go back to nodes which we introduced in week 11 with the image below:

There are different types of nodes depending on the roles they are assigned within the blockchain network. The different roles played by nodes in a blockchain network are defined by the requirements of the network. Depending on their roles, all the nodes validate transactions while some of them add these transactions to the blockchain "ledger".

The important point to note is that each node maintains a local copy of the blockchain meaning the data is stored in their local computers or laptops. Thus, all the nodes "see" the same transactions forming part of the blockchain which they can trust as the authoritative record.

(Recap from Week 11)

Depending on the type of local copy maintained, nodes are classified as

1. Full Nodes &
2. Light Nodes

Full Nodes

Full Nodes maintain a complete and up-to date copy of the blockchain. Since they maintain all the debits and credits from the initial or genesis transaction till the latest transaction, they do not need to refer to anyone else when checking or verifying a transaction. Full nodes can autonomously and authoritatively verify any transaction without external reference. Since Full nodes are nodes that maintain a full blockchain with all transactions, each full node can be considered as equivalent to a server in a centralized application.

Light Nodes

Some nodes maintain only a subset of the blockchain and verify transactions using a method called Simplified Payment Verification (SPV). These nodes are known as SPV Nodes or Light Nodes.

Many light nodes are designed to run on space & power constrained devices such as smartphones, tablets or embedded systems. For such devices, this method (SPV) allows them to operate without storing the full blockchain. SPV nodes download only the block headers (which we will discuss later!!) and DO NOT download the full transactions included in each block.

Let us revisit a simple journal entry and its impact on the ledger accounts & visualize it using an example :

Assume Sender wants to send 50 USD to Beneficiary, the journal entry will be as follows & the ledger accounts of Sender & Beneficiary are impacted as below:

So,

1. Journal entry gets passed in the books of account which is verified & validated
2. The entry gets authorized
3. The ledger accounts get impacted due to the journal entry

In a blockchain, the transactions are added to the public ledger by the nodes in the below order:

1. Nodes independently verify each transaction
2. Nodes independently aggregate or group transactions into new blocks (what is a block??)
3. Nodes independently verify the new blocks
4. Nodes independently add these blocks to a "chain" (what is a chain??)

The above steps are visualized as below :

Let us deep dive into each of the above steps :

Independent Verification of Transactions

1. A transaction input, once it satisfies the conditions for a valid transaction is sent to the neighboring nodes in the blockchain network so that it can be propagated to the entire network.

2. Before spreading the transaction further to the network, the nodes first verify the transaction.

A traditional journal entry in a funds transfer is validated by checking the correctness of :

a. Account numbers of both sender & beneficiary

b. Signatures &

c. Amount

Similarly a node checks a transaction against a checklist of criteria like valid data structure, syntax, size of the transaction inputs & outputs, locking & unlocking scripts etc. The logic & conditions behind the validation are all part of the blockchain system.

As mentioned last week, the transactions get collected in a pool of validated but not authorized transactions called MEMPOOL (short for memory pool).

Independent Aggregation of Transactions into Blocks

Before we get into aggregation of transactions into blocks, let us first understand what a block is.

In a bank - normally entries for funds transfer are passed in batches and not one by one. For example, banks will have inward and outward batches of clearing cheques signifying funds transfers from and into bank accounts respectively. Each batch will have hundreds or thousands of clearing cheques. Multiple batches of such clearing transactions are passed in the system on a daily basis.

Similarly, several transactions in a mempool are batched together and ready to be included in a block which is similar to a transaction batch as described above. This inclusion of transactions into a block is called MINING. Not all nodes can mine transactions. The mining of transactions can be done only by Miner nodes. A miner node will aggregate transactions into a block called CANDIDATE BLOCK.

A block is a data structure (like an excel sheet with fields for data) where transactions are included & aggregated. It contains various fields for adding transactions as well as identifying the block.

More on blocks next week!!