Blockchain Byte - Week 21 : Transaction Authorization

Recap

In Week 20, 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. IDENTIFY UTXO - Sender's wallet searches for Sender's UTXO(s) tied to that wallet for funds which can be "spent" or "extinguished"
3. GENERATE TXN INPUT - After identifying the relevant UTXO(s) for source of funds, a transaction input is generated which extinguishes or reduces the UTXO
4. SIGN TXN - The transaction is signed by the Sender's wallet
5. CHECK TXN - 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. PROPAGATE TXN - The transaction is propagated to all the nodes in the network.
7. MEMPOOL - The transaction forms part of the mempool (pool of unverified transactions)
8. VALIDATE TXN - Using digital signature, the nodes validate the transaction using the transaction details and the public key.

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

That is because 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.

Just like 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 funds have moved from Sender to Beneficiary.

Since nodes are the ones authorizing transactions, let us again revisit nodes.

Nodes Revisited

In a blockchain, the functions of validation & authorization are carried out by nodes using underlying system algorithms & cryptography.

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".

In a normal accounting system,

1. A 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 authorization

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

1. Nodes independently verify/validate 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 :

Transaction Verification

This was discussed in detail in Week 20, but for continuity sake, we revisit the below steps:

1. A transaction input, once it satisfies the conditions for a valid transaction is sent to the neighboring nodes so that it can be propagated to the entire network.
2. Before spreading the transaction further to the network, the nodes first validate 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

In a Blockchain, a node checks the 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).

Transaction Aggregation - 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 unless a customer raises an individual request for the same. For example, banks will have inward and outward batches of clearing cheques signifying funds transfers from and to bank accounts.

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.

There are two parts in a Block

1. Block Header
2. Block Body

More on blocks next week!!