Establishing an order of transactions in blockchain

In the previous article, we took a look at how we verify transactions in detail. In this article, we will look at why the order of transactions matters and how we can establish an order.

As we saw earlier, every party in a blockchain system can have its own ledger. This helps us create a decentralized monetary system. So, once I sign my transaction and publish it, every party in the blockchain network can verify my transaction. Then, they can add it to their ledger.

The need for an order

However, it is not that simple. There could be many thousands of transactions every second. And every party in the network will have to verify all these transactions and add them to their ledger. When there are many thousands of transactions, each party could add transactions to their ledger in different orders.

For instance, let’s consider the bookshop example we used in the previous articles. Assume I initiate another transaction to a restaurant soon after sending money to the bookshop using the same bitcoins I sent to the bookshop. Now, there are two unverified transactions of mine in the network. If the bookshop verifies the transaction to itself and adds it to the ledger first, then it will reject the transaction to the restaurant since the bitcoins I input into the latter transaction are the same as the ones I input into the former. But this is not a problem for us. What matters to us is that the bookshop has accepted our transaction to them.

If the restaurant also verifies the transaction to the bookshop and adds it to its ledger first, then it will reject the transaction to the restaurant. So, we will not get what we ordered from the restaurant. However, if the restaurant verifies the transaction to the restaurant first and rejects the transaction to the bookshop, then we are in for some great luck! We will have bought two items using the same money—in other words, we will have double spent.

This shows the order in which we add transactions to the ledger matters. Therefore, we should get all the ledgers to agree on the order of transactions. To use a more technical term, we should establish a consensus among all the ledgers.

Numbering transactions to establish order

We can number every transaction to create a certain order. Let’s assume that there are already 70 transactions. So, we will number my transactions to both the bookshop and the restaurant 71 since you continue numbering from the last transaction in the ledger.

Now, when the nodes in the blockchain network receive the two transactions, they would know that these two transactions follow the last verified transaction. Hence, instead of rejecting the transaction that comes second, the nodes will know that there has been confusion and will wait for the resolution of the confusion. We shall see how we can resolve this confusion later.

When we reject neither of the transactions, we end up with two branches. Let’s assume the previous 70 transactions didn’t face any problems. Hence, there is a chain of transactions in the order of their assigned numbers. Now, when two transactions with the number 71 arrive, we attach them to the 70^th transaction, creating a branch.

Why numbering is not a good idea

However, what if there is another pair of transactions at the same time? The transacting nodes will know that the last transaction number is 71 and they will number the following transactions 72. But there are two transactions with the number 71. So, to which transaction should we attach these new transactions? Or in other words, which branch should the next transactions choose?

As we saw earlier, inputs to a transaction are outputs from previous transactions. Let’s say one of the transactions numbered 72 was initiated by the restaurant and it uses the output of my transaction to it as the input. My transaction to the restaurant has the number 71. So, transaction numbered 72 actually follows transaction numbered 71 to the restaurant.

In actuality, this may never happen, and let’s look at the reason a little later. So, when the transaction numbered 72 is broadcast, it should be attached to the transaction numbered 71 from me to the restaurant. But there are two transactions with the number 71. So, numbering cannot help us uniquely identify my transaction to the restaurant.

Nonetheless, we can identify the right transaction to which the latest one should be attached by looking at the content of the transaction. By checking the latest transaction’s input section, nodes can identify that it should be attached to the transaction from me to the restaurant.

Ordering using hashes

However, we can make it simpler. What if the transactions actually carry information about the transaction they are following from? What if the restaurant’s transaction numbered 72 says that it is following from my transaction to it? Then, nodes don’t need to waste time reading the inputs of the new transactions and the outputs of the previous transactions. But how do we uniquely identify a transaction?

Remember hashes? What if we hash our transaction and use the hash as an ID? Every transaction is unique, and the hash generated becomes completely different even if there is a minor change to the input data. Hence, we can safely use hashes to refer to transactions. Now, we can add the hash of the previous transaction to the new transaction and create a hash of the new transaction. This way we can make sure the order of transactions is maintained.

Let’s go back to our example and see how this will work. When the restaurant wants to initiate a transaction using the output of my transaction to the restaurant, it will simply include the hash of my transaction. So, nodes receiving the transaction will know that this transaction should be attached to my transaction to the restaurant.

Now, we have a way to create a chain of transactions ensuring that all the nodes add the broadcast transactions in the same order. In the next article, let’s see how we can resolve the confusion.