Transaction. 2. Size Of Transaction And Scalability Problem
In the previous article, we have described main components of blockchain transactions. Now it’s time to talk about some volume issues.
Each transaction contains at least one record for the input and one record for the output. In regard to the overall value of transferred funds, there is no fundamental difference how many units are used to compose a transaction. But when it comes to a memory size, this amount does matter. A single transaction size increases depending on the number of units that was set to transfer. As a result, the number of transactions in a block decreases.
Let’s assume that a user needs to transfer 1 BTC. He or she can specify 1 BTC as a solid money unit. After a block with the transaction inside is closed, the value on the user’s account will decrease by 1 BTC, while a recipient’s account value will gain 1 BTC. Due to the nature of money accounting inside transactions, such a transfer may be simply presented as a pair of records from a previous input message and a further output message.
At the same time, the 1 BTC transfer may be presented as the transfer of two 0.5 BTC units, or ten 0.1 BTC units. In these cases, each unit should include an input messages record with its own address and service data. Therefore, the smaller units will be included in a transaction, the more place the transaction will occupy.
After multiple exchanges, solid bitcoins will be divided into smaller units. This will lead to the increase of the average transactions size and the decrease of the transferred nominal value. Besides, with the growing popularity of the Bitcoin protocol, the number of participants willing to transfer assets raised as well. This and other reasons caused a serious problem called the scalability problem.
Initially, the Bitcoin proposal did not contain any fundamental restrictions of the block size. But soon, this volume was limited to one megabyte. Once the number of transactions increased, it took some of them several hours or even days to be added to a block. Of course, users were not satisfied with this situation.
As the blockchain network was growing, the Bitcoin community and the blockchain developers started looking for ways to solve the problem. One of such solutions was the increase of a block size. During the discussion, the community’s opinions were divided, which soon led to protocol separation into several versions. Each version is now supported by its own audience.
Apart from the change of a size, there were also solutions with a dynamic variation. Gavin Andresen and Mike Hearn suggested periodically increasing the block size over several years. Jeff Garzik recommended to change the block size through the voting among users.
There were also other ways to reduce blockchain overload. One of them was the increase of the blocks’ frequency. Some developers suggest partially moving data out of the block transactions part to side chains, which doesn’t actually solves the main task. The Lightning Network (LN) protocol allows carrying out multiple transactions via the channel without approving them each time. This approach became available due to another solution called Segregated Witness (or SegWit).
In contrast to other approaches, involving side chains, SegWit moves data inside of a transaction and slightly changes content accounting rules. As a result, the efficient block size increased by around 1.8 times.
Bitcoin is basically developed in such a way that concepts of transaction, block and mining on blockchain give no opportunity for the system to grow, even if it is necessary. Significant efforts were applied to reduce the number of transactions, but it did not solve the problem completely. From this perspective, the SegWit implementation was very successful.