Blockchain Performance Issues and Limitations

Have you noticed that when we talk about blockchain performance, we usually name approximate numbers? Where do 1000, 100,000 tx per second and other round numbers come from? Why don't blockchain developers proudly claim 3,423 tx/sec on their websites after each blockchain code update?

The truth is that it's close to impossible to give an accurate numerical performance estimate of a system that consists of tens and hundreds of computers, especially when they are scattered across the planet and connected by a network. A number of tx/sec will not reflect a huge variety of states of a large decentralized network.

Speaking about performance of any system, blockchain or database with a large number of servers, we don't usually mean actual performance, but the ability to process N transactions per second under controlled conditions (when running on a small number of test computers that perform a predefined set of transactions). In reality, the numbers are completely different and depend mainly on user actions.

Blockchain performance measurement is even more complicated than that of traditional services, for example, distributed databases. Let's figure out why.

For users, blockchain performance is the speed at which they get the requested service. For example, a cryptocurrency transfer transaction or a transaction, calling a smart contract function. In all these cases, we prepare a transaction, send it to the network and expect a response. This parameter shows the time during which a client will receive a reliable confirmation of a successful payment, confirmed booking or a deal.

Below is a rough sequence of steps that the client software spends time on:

1. User prepares and signs a transaction
2. User sends a transaction to the network and waits for confirmation of acceptance
3. Network replicates information between network participants
4. Some of participants generate new blocks including a user transaction and replicate new blocks between network participants
5. User receives information about a new block with his transaction from the network

This scheme is similar to accessing a distributed database. The user sends a transaction that modifies the data, and waits until many computers make changes to the database. Then the user receives a response that roughly means the following: "It looks like the biggest cluster part has applied changes to the database".

A blockchain transaction should also "be accepted by the majority", but each computer checks the changes more thoroughly. Computers do not trust each other, so there are significantly more checks, especially the cryptographic ones. In addition to that, the participants also agree on the order and contents of blocks.

What are the problems that slow down blockchain operation and don't let it obtain performance of centralized systems?

Imagine that we have designed a super-blockchain. How can we identify its performance issues and when they may arise?

Any blockchain transaction is digitally signed. Any data change request always involves small non-zero fees. Thus, transaction costs in blockchain are higher than in standard databases: a signature check must be paid by the processor work time, an increased transaction size - by the network bandwidth, any changes in blockchain - by storage size.
In fact, blockchains are decentralized systems in which the client performs most of the work. Thus, amount of computations on the client side is gradually increasing, and blockchains themselves get lighter and faster. In some cryptographically advanced blockchains, a client can perform calculations that can last for tens of seconds or even minutes.
So, browser, wallet or blockchain game transactions can take significant time. This important factor affects overall blockchain performance from user's view. The more we use modern cryptography to confirm correctness of participant behavior, the more this factor affects total blockchain performance.

When a transaction is ready, the user sends it to the p2p network, through which all blockchain nodes communicate. In other words, the user sends it any available computer from the list of so-called peers - computers that do not trust each other. Having received a transaction, the peer immediately begins to distribute it between random peer neighbors from the list. After several transfers, a lot of peers have a transaction copy. Then computers that produce blocks (also called miners, block producers or BPs for short) include the transaction in the next block and distribute it across the network.

As a result, information is distributed over the network twice. First, the transaction travels from the user to the block producer, then back to the node waiting for the blockchain "news". Each time information is delivered in a new way and via different peers. This is what makes blockchain different from a large centralized system in which request paths are rigidly set to ensure maximum speed. Unfortunately, a block, or block part may sometimes be found on a few nodes that are currently unavailable. In this case, the peer will wait until the required data appears in the network. Likewise, it is possible that important data is so popular that it can reach a random node in no time at all and with better efficiency than in a pre-defined system.

Peer-to-peer networks cannot ensure fast and stable data transfer as optimized data delivery schemes in large centralized systems. On the other hand, peer-to-peer networks are more resistant to entire network segments cut-off and malicious behavior of participants. They may demonstrate fantastic bandwidth due to distribution of popular data parts between peers. It is extremely difficult to predict the exact time of such network request processing as it varies a lot.

This stage is quite time consuming, especially if network nodes are scattered all over the world. It is very difficult to measure network performance by emulating a large number of p2p network states. Thus, there is no exact tx/sec value for blockchains.

Consensus algorithm is another factor that affects transaction acceptance speed. Network nodes (miners, block-producers, validators) that are responsible for block and chain production, agree on correct blocks and those that should be discarded. Negotiating nodes exchange information about the blocks with the help of digital signatures, thus "voting" for one or several blocks.

The number of messages between nodes varies in different blockchains. For example, in most Proof-of-Stake algorithms it is required to receive messages("votes") from at least 1/3 of block producers to accept the given block and the chain it's built upon. In case of network problems such networks does not have time to deliver the messages to all participants in a reasonable time. Sometimes the algorithm requires additional messages - to add or remove block producers, resume work after a pause in block production, etc.

Evaluating blockchain performance in transactions per second, it is important to understand how much time is spent on network consensus, how effective it is and whether it can be further optimized. A 100 tx/sec blockchain may demonstrate a more stable quality of service than a high-speed 1000 tx/sec blockchain with periodic pauses during network reconfiguration or complex transactions. For now, several thousands tx/sec are maximum. But only for now...

Nowadays blockchains are reliable networks with malicious-resistant transactions. They are slower than their centralized counterparts — we cannot speak about millions of transactions per second. If you see messages about a million tx/sec, ask about the architecture. The creators of the ultra-fast "blockchains" often keep back a little, since millions of tx/sec usually mean middleware connection. In fact, such software is nothing but a common centralized service that meets such speeds requirements. In most cases, this is a L2 solution (Lightning, Plasma) or solutions that promise to assemble many parallel chains.

Be careful when you read about or assess blockchain performance as it is an extremely difficult and controversial question. Performance of a modern blockchain with a more or less standard scheme and consensus may reach 1 000 - 10 000 tx/sec under load in real projects (Bitshares, Steemit, EOS, Ethereum, PoA Network), not millions. Current p2p networks with a few dozen validators can distribute and process thousands and tens of thousands of transactions per second as a maximum, even with a fairly fast network. Everything works even slower for a bigger number of participants. Be skeptical about promises to solve performance problems, this issue has not been solved successfully yet, despite the work of a large number of teams. However, there are many good approaches and we're waiting for working solutions in this area of software research.

In the next articles we will talk about blockchain performance assessment and important metrics that will help to answer the "tps/sec" question.