Choosing the right chain: Scalability, speed, finality and transaction fees
The last big, technical thing from the blockchain trilemma is scalability and that is what we will look at today.
Scalability is that one blockchain aspect that is probably most noticeable to users (of course only until you become a victim of a security breach). Everyone just wants a faster chain as this is the thing that impacts us the most, usually multiple times per day, but I want to state is here again, there’s always a tradeoff between scalability, decentralization, and security. Therefore, it is called the blockchain trilemma. Each chain can scale up and become faster to the point that it will become fully centralized.
Despite the intense research and development, scalability remains a crucial challenge in wider blockchain adoption.
With that in mind let’s talk chain scalability.
What is blockchain scalability?
When most think about blockchain scalability, they think about Transactions Per Second (TPS). Some chains even misuse this term as TPS and state results that are misleading. We will see that TPS is mostly determined by the least performant node in the network. This for instance leaves room for representation of such data.
Despite the fact that scalability is a well-defined term it can have quite different meaning in the blockchain space.
In a general sense scalability refers to the capability of a system to handle growing amount of work. A system should be able to scale proportionally to the resources allocated. Solutions that do not scale well would experience diminishing returns while adding new resources.
Within blockchain, scalability is not 100% well defined. Some would call scaling anything that provides better throughput, latency, bootstrap time or cost per transaction.
In the blockchain space the term “scalable” means a comparative term, comparing different blockchains in regard to their TPS. When a blockchain is called scalable it indicates that the system achieves higher TPS by modifying its consensus mechanism or adjusting some parameters.
Let’s look at some examples to understand scalability in blockchain.
Scaling Bitcoin (PoW)
Bitcoin is known to be quite unscalable. Bitcoin uses PoW (Proof of Work) consensus mechanism to randomize the validator that can produce a valid block. All nodes are running PoW for a certain amount of time to determine the winner. The new block then needs to be synchronized to the whole network so that the race for the next block can continue.
To allow for full synchronization and security, Bitcoin block time is 10 minutes. Lowering the block time significantly would increase in throughput but because not all nodes would be able to synchronize on time it would create multiple chain forks and result in very long confirmation time and reduced security level.
Increasing the block size, meaning more transactions can fit in one block would also increase the throughput but again bigger blocks create bigger ledgers and longer synchronization times, and the end result leads again to the same problems.
There are attempts on making PoW scalable the selectin process only determining the round leader and not the whole transaction set. This would allow for syncing done in parallel and larger block sizes could be used. This is actually the principle that is used in PoS networks.
Proof of Stake achieves shorter block times because a leader is selected and synchronization can proceed in parallel to block validation. Leader selection is usually achieved through some random generation process that does not take a long time to run to achieve fairness. PoS systems are thus generally more scalable than PoW.
We will not go into Byzantine Fault Tolerance (BFT) algorithms or Directed Acyclic Graph (DAG) in this article as it is already to complex to what it’s set out to be.
In a sense, this type of scaling is trying to achieve higher throughput as the network grows. This unfortunately still doesn’t come close to the original “scalability” term used in centralized systems. That would require for linear growth to the number of nodes, but because of decentralization, this is just not possible.
In scale-out solutions not all nodes have the full information. This increases the risk of double spending as coins spent in a transaction could be again spent in another node that does not know this transaction. Methods to prevent this again go into a sort of not fully decentralized solutions but will be necessary to provide scalability to blockchains in the future.
There are currently two popular solutions for this one is Sharding and the other is off-chain.
Sharding is about dividing the whole network into sub-networks or Shards. Nodes in each sub-network share a local ledger. To prevent double spending once could use his coins only within that one shard. To spend them in another shard they would need to be transferred across to a different shard. Ethereum 2.0 (or Ethereum Consensus layer as it is called now) is taking this approach.
The off-chain schemes are largely inspired by the Lightning Network. They use an off-chain channel between two nodes for fast payment without needing to register every transaction between them directly on the Bitcoin layer. To make that possible three is again a tradeoff as both nodes need to put down a deposit on chain in advance, to open the off-chain channel between them.
Layer 2 solutions are also a kind of off-chain scaling.
If a blockchain does not scale out (sharding, off-chain) its TPS would be limited by the least capable node in the network. That would mean that the throughput of an average home PC (probably 100–1000 TPS) would be the maximum TPS that a fully decentralized blockchain can achieve. If a non-scale-out chain claims higher throughputs that goes into tens of thousands of TPS, it would mean a fairly centralized solution as the lower capacity nodes cannot join. On the other hand, a scale-out blockchain could theoretically achieve unbounded throughput but keep in mind the compromises in security, decentralization or functionality as it is impossible to simultaneously achieve them all.
There is another term that is connected to perceived speed of a blockchain and that it time to finality. Finality of a transaction means that a transaction cannot be altered, reversed or canceled anymore. The latency level of a blockchain will ultimately affect the chains finality rate.
Finality is measured in time needed for a reasonable guarantee that crypto transactions executed will not be reversed or changed.
Finality in blockchain is mostly represented on a scale as the more blocks are added to the chain, the more secure the transaction becomes. These additional blocks are usually called confirmation blocks.
What will determine the time to finality is then the average time per block and average blocks needed to achieve finality. For instance, if you have a block time of 10 minutes and 6 confirmations are needed, the time to finality will be around 1 hours. On the other hand, if you have a block time of 1 second and you only need 1 confirmation, you will have 1s time to finality.
Scalability comes into play once there is a lot of traffic on the blockchain as this might fill up blocks. The maximum block size determines that how many transactions can be confirmed in one block. If there are more transaction request per block time being generated that one block can accept, then your transaction may not get into the current block. In cases of high congestions you might be in cue for minutes, hours or even days.
And that brings us to another topis and that are transaction fees.
Transaction fees eventually serve 2 purposes. One is to prevent spammy transactions being sent in a form of a DDoS attack and the other to provide incentive for validators.
We have all seen the huge fees that are plaguing Ethereum, neatly called Gas fees. So let’s take a look what a transaction fee is in the Ethereum blockchain.
A transaction fee is calculated as the multiplier between Gas and price per Gas. Gas is determined by the computing power required to perform a transaction or a smart contract. This is why transferring ETH will be almost half cheaper than transferring an ERC20 token (ERC20 are smart contract based while ETH is native).
While providing a transaction request one needs to decide how much is he willing to pay for a transaction. The miners (or validators) will then usually sort the current transaction requests and only include the ones onto the block that make them the most money (mostly refer to as MEV). Of course, there are constantly new transactions incoming and you may be left out for good. This mechanism raises the price of transaction fees sky high.
Another problem in such systems is that frontrunning is always present. This means that if you find a valuable transaction like an arbitrage opportunity there will be competition in paying higher fees to the point of the actual value of the transaction benefit. Sometimes miners themselves participate in such transactions having an unfair advantage knowing the current max fee that is offered.
Not all blockchains use the same fee calculation mechanism. Some have fixed fees, some allow tips, some prevent transaction ordering altogether and fight the frontrunning problem.
Altogether, with scalability there come lower fees as the blocks do not get filled up and users do not need to offer higher gas prices to be included in a block. Also, with more transactions processed even a smaller fee will amass to a satisfying profit for the validator.
With this we conclude the most complex and technical part of the chain selection process. Understanding how different aspects within the blockchain influence each other shows the true extent of the complexity behind the decision-making process (let alone designing it from the ground up). In the next articles we will go into other, more soft factors influencing our final decision.