Aleph Zero Blog
Business

Fundamentals: TPS vs. Latency vs. Finality

Feb 3, 2022

AI Summary

Here's your AI summary of Fundamentals: TPS vs. Latency vs. Finality on Aleph Zero blog

Top 10 key takeaways:

  1. TPS Misunderstandings: Transactions-per-second (TPS) is often mistaken for speed, but it actually measures the throughput of a blockchain, not its velocity.

  2. Latency Importance: Latency, the time between issuing a transaction and its finalization, is a more accurate measure of a blockchain's speed from a user perspective.

  3. Finality Concept: Finality ensures that a transaction is irreversible and secure. Traditional blockchains like Bitcoin offer probabilistic finality, which can take up to an hour.

  4. Industry Challenges: The "blockchain trilemma" involves balancing security, decentralization, and scalability. High TPS often compromises other essential features.

  5. Increasing Block Size: One solution to scalability is increasing block size, but this can limit decentralization and require specialized equipment.

  6. Sharding: Dividing a blockchain into smaller segments to run in parallel can increase efficiency but introduces security risks.

  7. State Channels: Off-chain solutions like the Lightning Network offer quick, low-cost transactions but require locking tokens, limiting broader adoption.

  8. Rollups: Techniques like ZK-SNARKs validate off-chain transactions on-chain, enhancing security and scalability.

  9. Aleph Zero's Approach: Aleph Zero uses a Directed Acyclic Graph (DAG) and a custom proof-of-stake protocol to achieve high TPS and low latency without additional workarounds.

  10. Multichain Ecosystem: Different blockchains will specialize in various areas, and not all applications require high TPS. Bitcoin, for example, excels as a store of value despite its limitations.

AI Summary

In our second article in the Fundamentals series, we will look at the concept of TPS, latency, and finality. These are three terms whose understanding is crucial for the crypto connoisseur. 

One of the most significantly misunderstood concepts in the blockchain space is transactions-per-second (TPS). It is one of the most thrown-around phrases in the industry. Achieving a TPS number that will allegedly allow for mass-market adoption is considered by many to be the “Holy Grail” of blockchain technology. As with many things, though, not all that glitters is gold. When approached with greater scrutiny, we can begin to see several hairline fractures in the entire narrative regarding the supremacy of TPS. So what are these misinterpretations? And how can we measure the speed of blockchains in a way rooted in reality to a greater degree? First, though, we will look at why TPS has come to be regarded with such respect in the industry. 

TPS Is Not What It Seems  

The first mistake to focus on before moving to any other points is that we often mistake TPS for speed. When we hear the phrase “transactions-per-second,” our instinct is to equate that with velocity. TPS has more to do with the throughput of the blockchain! If we want to discuss how quickly a blockchain completes our transaction, the notion of latency is closer to the truth.

Anyone with access to the internet can marvel at the unnoticeable latency through which messages are sent, money transferred, and information accessed. The amount of transactions per second a given network can handle is TPS. To some extent, this can be interpreted as the number of users simultaneously engaging with said network. It wasn’t always the case for the Internet to be capable of hosting billions of users, instantly catering to their every whim. If we look back just 25 years, we’ll see that even accessing a website often took minutes due to high latency and low throughput. 

When the Bitcoin blockchain debuted in 2008, it offered the first solution to a permissionless network. Unfortunately, its design favored liveness by sacrificing latency and throughput (TPS). It took a long time to process a small number of transactions. Over the past decade, the development of newer blockchain projects focused on increasing TPS to levels that would permit day-to-day use while offering competitive transaction fees. Among legacy service providers, Visa holds the record for the load on its network and is the benchmark against which we measure all contenders for the throne. Surpassing or at least matching Visa’s 1,700 TPS was the target

Disassembling the TPS Mythos 

…and so the TPS Wars began with blockchain after blockchain competing for supremacy in this field. Over the last decade, several blockchains have come forth claiming that they have reached figures that could directly compete with Visa. More often than not, these figures were pipe dreams. They relied on clever marketing and repositioning the goalposts of what a transaction actually is. Many of these impressive results occurred solely in test environments that were not always disclosed as such. These sterile laboratory conditions do not represent real-world performance. We must understand these test results as what they are: test results

One of the most significant industry challenges is the “blockchain trilemma”, a balancing act of delivering a protocol that is secure, decentralized, and scalable. Security and decentralization are equally, if not more important than TPS. In the arms race for superior TPS, we have seen the rise of projects that, although fast, have lost touch with other key features of blockchain tech. 

Latency and Finality 

While everyone is obsessing over TPS, latency lurks in the background. This is perhaps the more critical factor that will allow blockchain to gain traction among lay users. Latency is the time that passes between issuing a transaction and finalization. This makes it the actual “speed” of a service that we observe as consumers. It is paramount that the time between these two events is as short as possible. A necessary quality to avoid the average consumer feeling frustrated. Still, more significant consequences can take place if high latency plagues institutions in the financial world. 

The second key concept to grasp is finality. Finality is the process through which the protocol guarantees the acceptance of a transaction. Latency and finality have a lot in common, as latency affects finality. This process ensures that no entity can reverse or change our transactions. Finality is the exact thing that you are waiting for when making a transaction. It is also the factor on which you would like to base your latency measurements on. Crucial here is the understanding that the finality proposed by first-generation blockchain technology is probabilistic finality. This means that it takes a certain amount of blocks to be added to the chain before we can consider our transaction to be fully secured.

On the Bitcoin blockchain, our transaction attains immutability after about six blocks. When we consider that appending a new block to the Bitcoin blockchain takes 10 minutes, it means that it takes about an hour before our transaction is irreversible. That is a long time to wait! Even waiting 10 minutes to add our transaction to the Bitcoin blockchain renders it an impractical solution for transferring funds for daily expenses. Newer solutions such as AlephBFT offer 100% finality. 

Industry Solutions 

The industry is more than aware of the limitations of the technology. During the last few years, it has been actively working to increase the speed of blockchain while ensuring security and immutability are not compromised. Let’s look at some of the solutions to these challenges:

  • Increasing block size: One of the initial solutions to dealing with scalability issues in the blockchain space was to increase the block size used by the Bitcoin blockchain. Bitcoin blocks are roughly 1MB in size. Their actual size depends on the types of transactions that go into the blocks. The suggested unreachable theoretical limit is 4MB. An obvious solution is to increase the block size. Bitcoin Cash, a fork of Bitcoin, boasts block sizes of 32MB. The challenge one encounters when going this route is a limit to which we can increase the block size. Larger blocks mean that we require more specialized equipment to validate transactions. As a result, this limits the accessibility and decentralization of a protocol. 
  • Sharding: Sharding is a technique through which we divide a blockchain into smaller segments. These segments run in parallel to each other. This makes it easier to share the workload among nodes and increases efficiency. The Ethereum network is experimenting with sharding as part of its modernization attempts. This technique does possess though specific security weaknesses that need addressing. For example, it is possible to corrupt an individual shard and, as a result, introduce misinformation into the wider network. Ethereum has decided to assign nodes randomly to particular shards and reassign them at random intervals to combat this threat. Some examples of projects employing sharding are NEAR and Elrond. 
  • State Channels: Probably the most famous example of a state channel implementation is the Lightning Network. This solution is native to Bitcoin. It permits users to perform transactions off-chain between select users without forcing them to go through the Bitcoin blockchain and its limitations. This channel offers a quick, private, and low-cost alternative to the Bitcoin network. Although not Bitcoin-specific, as Ethereum offers similar solutions through its Plasma chain, this method of increasing transaction speeds will not take hold in the broader blockchain space. It comes with major tradeoffs. Mainly because it requires locking a significant amount of tokens in place specifically for the purpose of enabling fast transactions for users. 
  • Rollups – A technique of performing transactions essentially off-chain, but then validating them on-chain by using ZK-SNARKs. These are modern cryptographic primitives that allow proving the validity of arbitrary statements in such a way, that verifying such proofs is significantly simpler than verifying the statement itself. Currently, Ethereum deploys various versions of rollups as Layer 2. Vitalik Buterin has hinted at this being the way for laying many of the industries woes to rest by using a combination of:
    • Second-tier staking: The transactions in a block are split up into 100 “buckets.” Each second-tier staker is randomly assigned to a bucket. Block acceptance occurs when ⅔ of the validators assigned to a bucket sign off on it.  
    • Fraud proofs/ZK-SNARKS: These solutions test block validity, adding another layer of security beyond the randomly assigned validators. 
    • Data availability sampling: This solution allows users to check block availability and to confirm the publication of the block. They can do this by downloading only a few pieces of randomly chosen elements of the block. 
    • Adding secondary transaction channels: This design prevents attempts at censorship. It does so by allowing secondary stakers to submit lists of transactions that the next main block must include. 

The end result of such a solution is a chain that although possessing a centralized method of block production achieves decentralization with regards to block validation. It is also safe from censorship in the event that the block producers behave maliciously. 

The Aleph Zero Touch Regarding TPS and Latency

Aleph Zero is a Layer 1 solution that employs a Directed Acyclic Graph (DAG) in conjunction with a custom proof-of-stake consensus protocol. The Aleph Zero blockchain does not take advantage of any of the above concepts. Rather, it attempts to squeeze as much throughput from the chain itself without any additional workarounds. Through the application of DAGs, the Aleph Zero team has managed to create a blockchain solution that offers superior TPS while also offering virtually unnoticeable latency.

This results in Aleph  Zero possessing subsecond latency. This feature is currently not possible to achieve via any of the previously listed solutions. It is crucial to note that, besides low latency, the Aleph Zero blockchain also boasts TPS levels that are more than enough for most of the use cases coming our way, e.g., processing medical records. More importantly, the solutions used by Aleph Zero don’t require expensive gear, batched payments, or sharding. 

TPS and Latency: Different Use Cases Require Different Solutions 

It’s easy to get carried away in this whole discussion, and more often than not, as a community, we tend to fall into tribalism. We treat our favorite projects as we would sport teams. This misplaced rivalry forgets that the industry’s future lies in a multichain ecosystem. In this multichain world, different blockchains specialize in their chosen area. 

When we take this into account, we can conclude that an impressive TPS number is not necessary for every application. If that were true, Bitcoin would be a “has been.” Clearly not the case, as 13 years later, it remains the most popular cryptocurrency in the world. Bitcoin has excelled as a store of value and will continue to do so despite its limitations. Its reputation as “digital gold” has served it well. As the granddaddy of all cryptocurrencies, it still has a future ahead of it. We probably won’t be building “the Netflix of Web 3.0” on the Bitcoin blockchain, but it was never designed to do that.

Before getting carried away by the TPS hype train, we should first do our research on what the project intends to do and the use cases it is pursuing. We don’t live in a world where one size fits all, and we are all the better for it.