If cryptocurrencies are to replace existing payment solutions, they need to be fast. Why are some cryptocurrencies faster than others and what are the fastest coins?
When you talk to a cryptocurrency naysayer, sooner or later, he will come up with a "Yes, but" moment such as:
- "Yes, but they are unregulated..."
- "Yes, but criminals use them..."
- "Yes, but they are slow..."
This lesson is going to shed light on the last issue because there is some truth to the argument that cryptocurrencies are impractical due to being slower than traditional payment processors. Here is what you will learn:
- What the blockchain trilemma is and why it matters
- How to determine a blockchain's speed
- Why blockchain speed matters
- How different currencies try to solve the speed problem
- An overview of transaction speeds across blockchains
The Blockchain Trilemma
At the heart of this issue lies the so-called blockchain trilemma. Conceptualized by Ethereum founder Vitalik Buterin in 2016, it postulates that no blockchain can simultaneously achieve decentralization, security, and scalability.
There is always a trade-off between sacrificing one attribute to maximize the other two. Bitcoin is decentralized (anyone can participate and validate transactions) and secure (relying on complex cryptographic functions). But it isn't very scalable, as we will later see in more detail.
EOS is one of many examples of a blockchain that can process a lot more transactions per second than Bitcoin. However, it relies on 21 validators to validate transactions. In essence, these 21 parties control the direction of the blockchain, which is not very different from a regular company and not a prime example for decentralization.
Lastly, a blockchain needs to be resilient (able to withstand short-term attacks) and immutable (leaving the transaction history unchanged). The more blocks a blockchain processes, the longer it will take for all nodes to be synchronized, assuming there are many nodes. This time delay is called network latency. The more transactions are processed, the higher a blockchain's network latency and the more probable an attack becomes.
For example, an attacker could change the value of a transaction that has not been fully confirmed yet. Another option would be a 51%-attack, in which a malicious party takes over a majority of the blockchain's computing power.
With this conundrum in mind, the question begs: why does this even matter? Why do we need a fast blockchain in the first place?
Why blockchain speed matters
A much-cited study from Nielsen Group, a user experience research firm, found three main limits when optimizing web and application performance. A user's experience when interacting with a computer will change according to these three limits:
- 0.1 seconds is the limit to providing the user with a feeling of instantaneity. Within this limit, you won't feel a delay using a computer.
- 1 second is the limit to keeping the user's flow of thought uninterrupted. However, you will notice the delay.
- 10 seconds is the limit of keeping the user's attention. If the delay is longer, you will start another task in the meantime.
Keep in mind that regular payment processors act within the third limit. A blockchain that operates at a slower speed would not be practicable for daily use and, therefore, would not be in a position to challenge payment processors like VISA.
Blockchain companies have come to this conclusion as well and are actively working on solving the speed problem. However, given the blockchain trilemma, no company has yet been able to come up with an ideal solution. Another question is how quick is quick enough? To determine that, you have to look at what determines blockchain speed.
How to determine blockchain speed
To determine how quick a blockchain is, we need to look at:
- The size of each block
- How frequently blocks are made (the block time)
- How large the average transaction on the blockchain is
For example, Bitcoin has a block size of one megabyte, and its block time is ten minutes. The average transaction size is 400 bytes. We can thus approximate the transaction speed:
Block size / transaction size = transactions per block
For Bitcoin: 1,000,000 / 400 = 2,500 tx
One block is made every ten minutes (=600 seconds). This yields:
2,500 tx / 600 sec = 4.18 tx/sec
Which is close to the actual transaction speed of about 5 tx/sec. We can see that transaction speed depends on block time and block size. If we want to increase the transaction speed, we'd need to reduce block time (more block gets confirmed) or increase block size (more transactions in one block). Let's try that for Bitcoin and assume the block size was ten times bigger and the block time ten times faster:
Block size / transaction size = transactions per block
For Bitcoin: 10,000,000 / 400 = 25,000 tx
25,000 tx / 60 sec = 418 tx/sec
Still nowhere near as fast as VISA with 40,000 tx/sec but quicker than the current state.
Unfortunately, this isn't possible for two reasons.
First, reducing block times would generate orphan blocks. Orphan blocks are unconfirmed blocks that have not yet been validated by all nodes in the network. This would result in weaker blockchain security and a higher probability of hacks.
Second, each computer must download the entire Bitcoin blockchain to participate in the validation process. Currently, it is only 344 gigabytes in size. The blockchain would also grow much faster if Bitcoin were to change to higher throughput, i.e., process more transactions per second,
This would come at the expense of decentralization because regular users would quickly not be able to participate in the process. You would need a data center to store the entire blockchain history.
Moreover, the necessary internet speed to upload transactions would need to increase. In our hypothetical example, Bitcoin would need 10 megabytes per second for roughly 400-500 transactions per second. That is not very data-efficient.
How you can solve the speed problem
Hence the question of how to solve the speed/scalability problem of blockchains. Since a blockchain's scalability refers to its ability to maintain the same performance at a larger scale, it's synonymous with speed in this regard. The third leg of the trilemma cannot be sacrificed, which leaves two possible options that can be explored.
This is the route most scaling solutions for established blockchains and most new blockchains have been going. The examples above showed that many nodes confirming transactions can result in a security problem. At higher user and transaction numbers, this architecture becomes impractical. So how about doing away with some of the nodes?
Layer two solutions for Ethereum, such as Polygon, have been applying this solution. Only 7-10 nodes actually produce blocks. The same is true for competing blockchains like Polkadot, whose smart contracts will be validated by 10 validators.
In addition to that, one has to keep in mind the difference between transaction confirmation and execution speed. Bitcoin transactions take ten minutes to get executed but require about six confirmations (blocks added after your transaction) to be confirmed. This circles back to security; the more blocks have been added to a blockchain after the block containing your transaction, the higher the probability the payment cannot be reversed. That's why unsecured blockchains like Ethereum Classic need up to 40,000 (!) confirmations.
Centralized blockchains like Ripple, Stellar, and Cosmos offer instant transaction finality and are faster. However, this again comes at the cost of decentralization. Hypothetical central bank digital money would operate in the same manner.
The second option would be to compromise on security. Solana is an example of a very fast blockchain that can process up to 65,000 tx/sec. This looks good on paper, but there are a few banana skins for Solana.
First, it had to deal with an outage in December 2020 that lasted for about six hours. This is unheard of for other legacy blockchains like Bitcoin and Ethereum. Second, its small transaction size per block means the blockchain is growing rapidly. In a little over a year, it has already amassed more than two terabytes. This has prompted Solana to outsource its data storage to a decentralized cryptocurrency storage project called Arweave. Validators only store the last two days of data.
While this is already bad news for its decentralization, there's also the fact that Solana is backed by Sam Bankman-Fried, CEO of FTX (a trading exchange), and Alameda Research (a cryptocurrency hedge fund). There is nothing inherently wrong with this. Arguably, Alameda Research is a powerful player to have as backers. However, it's unclear how much influence they have on Solana behind the scenes and how decentralized the project de facto is.
In conclusion, Solana is a case that compromises a little bit on both to achieve scalability.
Overview of different transaction speeds
Below, you find an overview of the current transaction speeds and throughput of several major blockchains. Transactions per second are indicated according to the current capabilities. For example, while Solana can theoretically support up to 65,000 tx/sec, the current capability is much lower. Equally, transaction times are indicated with confirmation time since it is the de facto measuring stick for a blockchain.
|Attribute||Transactions per second (throughput)||Transaction time (with confirmations)|
It took VISA several decades to scale to the current throughput, so it would be premature to call blockchain technology a failure after merely a decade of existence. So far, Solana seems the most promising solution to scale and retain a degree of decentralization. Ethereum 2.0 aims to increase its tx/sec to up to 100,000. However, it will sacrifice its current degree of decentralization and essentially plans to rely on 64 isolated blockchains with 128 validators confirming transactions. Cardano is working on a solution that is supposed to process up to 1 million tx/sec, thanks to separating smart contract and transaction data. Currently, though, this is only possible on paper, and no blockchain has convincingly overcome the blockchain trilemma problem.