Performance pitfalls in Blockchain applications
Anywhere you can read or hear the buzzword blockchain. And more and more software solutions decorate themselves with it. Even though when the software solution they sell in fact is not a blockchain. Blockchain is a special case of the distributed ledger technology and was first used in Bitcoin to bundle transactions. Some of so-called blockchains for business don’t create blocks internally in which transactions are stored and are therefore not real blockchains.
The intention is clear everything connected with blockchain can be sold better. As an example, shares of some companies rose immeasurable after they added the wording “blockchain” in their company name, although they don’t have any blockchain technology or just started with a blockchain product.
But actually, what is a blockchain? A Blockchain in our opinion is just another software architecture style. A new style with advantages and disadvantages. Familiar architecture styles like SOA, Microservices, or event-driven all of them have pros and cons and the same is valid for the architecture style blockchain. Blockchain has some very serious disadvantages like throughput or latency and needs to be taken into account.
A blockchain is a chain of blocks and a block contains transactions. How much data is stored in such a transaction is very important because the blocks have to be distributed among the peer to peer network or at least the transactions if the underlying technology is only a distributed ledger. If the blocks or the transactions are data-intensive it needs more time to move this data from one part of the world to the other one. Peers in a distributed ledger are preferably distributed among many locations. If the communication from one peer to another peer takes long, it is more difficult to have the same consensus all the time and this leads to more conflicts and conflicts in turn cause even more network traffic to solve these conflicts. So, it might be not a very good idea to store large images in a distributed ledger.
Big storage capacity
If a new peer of a distributed ledger is born, he has to download the whole transaction history from another peer. History is a requirement that he can prove whether a new transaction is valid or not. In the bitcoin case, a peer can only judge if person A can send 5$ to person B if he knows that person A has at least 5$. This can only be proofed if he has the entire transaction history since the beginning of time. Every peer has to store this history and therefore plenty of storage capacity is needed. In July 2020, the bitcoin chain already needed 285 gigabytes in size.
Proof of work
Proof of work is the consensus algorithm used in bitcoin to reach an agreement about valid blocks among the peers so-called miners. Everyone has heard about the performance issues in bitcoin. Because the performance to create a new block is poor, not a lot of transactions per second can be created. In bitcoin every 10 minutes a new block is created, and this block can at maximum contain 3500 transactions with the given block size limit. See above why a block size limit is essential. The conclusion could be to increase the block frequency. More blocks per hour would result in more transactions per second someone could argue. Unfortunately, the sense is that it needs work (here in the form of time and electrical power) to create a new block. Because the creator of a new block is rewarded with new Bitcoins. If this process would be too simple, meaning not a lot of work is necessary to do it, everyone would do it and if everyone can easily get new Bitcoins the value of one Bitcoin becomes worthless. Because of the transaction limitation proof of work is not suitable for high-frequency business transactions. For example, Visa can process up to 65’000 transactions per second they say. Other sources say the network handles 1700 global transactions per second on an average day. Also, that is about factor 280 faster than bitcoin. This is the reason why many research activities are made in the distributed ledger environment to improve throughput. New faster consensus algorithms arise but not infrequently to the disadvantage of decentralization.
The balancing act between decentralization and performance
As mentioned at the beginning every architectural style has its benefits and drawbacks. In the world of distributed ledger, the drawbacks might be forgotten sometimes. In the end, it is a matter of trust. If you can’t trust your counter-parties or your customer don’t want to trust you as a centralized authority, a distributed ledger technology could be worth the trouble. Whether we can trust big corporations and organizations anymore, after all, we have seen, is another question. In the case of bitcoin, there is no trust and therefore the blockchain technology is indispensable. A system like bitcoin is sometimes called a trustless system.
Keep doing the great work! Happy Performance Engineering!