How a Blockchain Performs Transactions

Blockchain is a decentralized system which performs operations through orchestrating many peers across logical and geographical sites. During the orchestration, the peers would have both independent operations and synchronizations, which form various complicated operational scenarios in real time. One of the most important operations in a Blockchain system is processing transactions that are always delayed by end-users due to their low performance and instability. This blog post explains how Blockchain systems manage user transactions and highlight performance issues before recommending a strategy for end-users to have successful transactions.

Blocks and Chains

Overall, a block is designed to package transactions into the chain. A system block is created by combining user transactions, a previous block fingerprint, and a fingerprint of itself. The fingerprint validation ensures that the block content, the transactions, and the previous block fingerprint remain as an origin. In the other words, two blocks with miniscule differences in fingerprints will be not compatible with each other.

A chain is a list of one genesis block and many following blocks. The fingerprint of a block is placed with nearby block content recursively, so that the blocks form an ‘infeasibly’ broken chain—a Blockchain. If there is an attempt to alter one bit of a transaction (e.g. changing the amount or the recipient address) in a block of a Blockchain, the attack will cause the fingerprint validation to fail, creating an invalid block. If the attack successfully updates this fingerprint in the next block, it will, in consequence, display the next invalid block. Hence, changing one data bit in a block of a chain will make all following blocks invalid.

Transactions and Blocks

Transactions are packaged into blocks for a certain amount of time under some predefined constraints. Bitcoin’s constraints define the block-size limit and estimated transaction fee, while ones of Ethereum define transaction priority (based on variable transaction fee) and system rewards.

For example, in Bitcoin, blocks are limited to 2 megabytes in size, carrying approximately 3,000 transactions for every ten minutes, and the transaction fees at the time of writing are about $0.3 to $1.3, depending on user desire. In Ethereum, contradictorily, a new block is created in 10-20 seconds and the system records approximately 30k transactions per hour.

States of a transaction

A transaction shifts through four stages in its life cycle: new, verified, confirmed, and dropped. New transactions created by senders or exchanges are sent to one dedicated party of the Blockchain for verification. The party will broadcast the transaction to ‘nearby’ peer parties if it successfully validates the transaction (valid amount, valid owner signature, etc.). The propagation will stop if any party discovers a fraud in the transaction. As soon as all dedicated parties have proven the transaction legitimate and put it into a pending transaction pool, the status is ‘verified.’ The dedicated parties in a permissionless Blockchain are ‘miners,’ whilst permissioned Blockchains are referred to as ‘endorsers.’ Miners of a permissionless Blockchain are volunteers who can be employed by you and are dedicated for your transaction propagation. However, in a permissioned Blockchain, you have to place your orders to predefined endorsers, even though they are currently overloaded or down.

The verified transactions stay in the pools and prepare for packaging based on the transaction fee that the owners are willing to pay. The block packaging the transaction will then be broadcasted to all other parties. The transaction status will be ‘confirmed’ if several parties verify that they have accepted the block.

The last stage occurs when there are conflicts between miners/parties about the chain. For example, there could be 2 or more winners at the same time, which results in conflict when choosing an identical block. At a random synchronization time, all parties will vote for the final chain, which eliminates competition. In the worst case, the transaction packaged in a block will be ‘dropped’ if it does not exist in any block of the final chain.

Transaction Processing Bottleneck

In special occasions such as an initial coin offering or token public sales, the new transactions peak for a very short time span and the Blockchain system cannot handle all of these requests. As a result, tons of transactions are failed or not processed on time. The bottleneck causing that could result from 2 possibilities: (1) when the transaction is received or (2) during packaging. A dedicated party will become exhausted getting millions of transactions at a time to verify and broadcast, whilst the miners pick up the highest priority ones in the transaction pools for packaging.

Strategy of Submitting a Transaction

Acknowledging the processing bottleneck will let you wisely strategize for submitting your transactions. In the simplest case, if you don’t care about the events, meaningless transaction fees can be saved by staying free for a while and submitting the transactions after the event times. Otherwise, you need to seek for a smart strategy to compete with other users.

Obviously, to win the competition, you have to let your transaction be in the transaction pools with a ‘relatively’ high priority; in other words, you cannot win unless you are in the line and tall enough. To achieve that, choose an active recipient to send your transaction to and set the fee high enough in order to be picked up. Ordinarily, the fee is set to be maximal because of too many competitors, and most unwise users failed their transactions due to the exhaustion of their common transaction destinations.

Summary

One of the biggest issues of Blockchain systems is the scalability, in which a huge number of transactions requests exhaust the system and cause unpredicted behaviors. While the Blockchain technology of the future is still under development and enhancement, an increasing amount of people attempt to compete and win the races of ICOs or public sales. To ensure success, be calm and vigilant when exploring these opportunities.

Thong Nguyen
Thong Nguyen joined LogiGear in 2009 as a software developer and has been leading LogiGear’s researching as a senior technology manager. He was responsible for setting up the innovation of TestArchitect, a leading tool in test automation. Adapting to Blockchain technology since 2018, Thong started leading a MOWEDE development team to deliver Blockchain projects. Thong also teaches testing domain and cryptography at the University of Sciences and is actively involved in LogiGear's internal technical seminars.
Thong Nguyen
Thong Nguyen joined LogiGear in 2009 as a software developer and has been leading LogiGear’s researching as a senior technology manager. He was responsible for setting up the innovation of TestArchitect, a leading tool in test automation. Adapting to Blockchain technology since 2018, Thong started leading a MOWEDE development team to deliver Blockchain projects. Thong also teaches testing domain and cryptography at the University of Sciences and is actively involved in LogiGear's internal technical seminars.