What Do Scalability, Throughput, and TPS mean?

Developers and users often compare blockchain networks based on their speed and data processing power. Scalability, throughput, and transactions per second (TPS) are some technical jargon that often appear in such comparisons. 

These parameters inform decisions about building on a particular network, taking into account the number of users, transaction volume, and throughput. Builders need to evaluate these metrics to understand what sort of environment they are bringing their product into. Is it one that can support deep liquidity needs, or is it focused on high throughput and micro transactions?

This article will thoroughly examine the significance of these parameters. You’ll learn how to compare blockchains effectively and determine whether these are the only parameters that significantly influence a network. 

This article covers: 

• What do “blockchain scalability,” “throughput,” and “TPS” mean?
• Comparing blockchains in terms of scalability, throughput, and TPS: What matters and why
• How monolithic, single-threaded blockchains limit scalability, throughput, and TPS
• Modern approaches to blockchain scalability
• Beyond TPS: The role of latency and finality
• Introducing Sei: High throughput and low latency by design

What Do “Blockchain Scalability,” “Throughput,” and “TPS” Mean? 

Here’s an overview of the three terms and their importance: 

What Is Blockchain Scalability? 

In the context of blockchains, scalability refers to the network’s ability to accommodate growth in usage (in terms of transactions or users) without experiencing bottlenecks. This doesn’t mean you get to trade off on security or decentralization to scale. 

As a result, highly scalable networks will have increased capacity to process blockchain transactions without a drop in speed or an increase in costs. The network will continue to maintain its security and decentralization, ensuring it remains reliable for users. Conversely, a less scalable network will struggle or slow down as it gets busy. 

Blockchain scalability reflects how future-proof a chain is and its ability to grow and support mainstream-level traffic without compromising on performance or security. 

What Does Throughput and Transaction Per Second Mean?

Throughput refers to the rate at which the network can process transactions. Typically, it is measured over a second, indicating the average number of transactions finalized per second. 

It depends on different factors, like: 

• Block size: How many transactions fit in a block?
• Block time: How frequently are blocks produced?
• Time to Finality: How soon will the network’s current state be verified? 

This reflects the blockchain’s capacity. If transactions are like cars passing through a tunnel, throughput will be like the tunnel’s capacity. 

However, if users don’t submit transactions, the observed throughput will be lower, regardless of what is possible in terms of transaction rate. Throughput sets the upper limit. 

Transactions Per Second measures the number of transactions a network can process per second. It’s a metric that highlights a blockchain’s throughput. If a blockchain’s throughput is its capacity, TPS is the numeric figure expressing that capacity.

There are different ways to measure TPS, making it essential to distinguish between real-world TPS and theoretical TPS. 

• Real-world TPS: The observed value, which may fluctuate due to network conditions, usage, and the mix of transaction types.
• Theoretical TPS: The calculated value assuming ideal conditions and minimum transaction complexity.

Tip: When comparing blockchain networks based on TPS, be cautious that marketing claims of XYZ TPS may represent the value under lab conditions. Under normal conditions, it will be much less.

All blockchain transactions aren’t the same and require different levels of compute. If you’re measuring throughput solely based on TPS, it may not provide the most accurate performance insights due to varying levels of compute required. 

Jay Jog, Co-founder at Sei Labs, explains, “An Ether transfer requires 21000 units of gas, but an ERC-20 transfer needs 65000. It confirms that TPS doesn’t convey value when tracking mass transactions and network throughput.” 

An alternative performance metric would be “Gas per second.” It evaluates the gas fees required to process transactions, taking into account different transaction types. Gas per second provides a broader perspective compared to TPS, considering all computational efforts in complex transactions. 

Comparing Blockchains In Terms of Scalability, Throughput, and TPS: What Matters and Why

Before comparing blockchains, you must have a clear understanding of the concepts outlined below. 

Scalability isn’t a standalone goal. It’s tied to security and decentralization. 

This interconnected goal is often referred to as the “blockchain trilemma.” If you focus solely on the “scalability” aspect, the naive approach to increasing transactions per second would involve using a larger block or reducing block time. However, it leads to centralization as only a few nodes are capable of handling the load or staying in sync. Moreover, it also introduces security risks. 

While comparing, consider how a blockchain addresses the scalability challenge without undermining the trust guarantees.

Scalability, throughput, and TPS directly impact user experience, economic viability, and the types of applications that a blockchain supports. A blockchain with low throughput will experience congestion when too many users access it simultaneously. This was famously seen with early blockchains.

High demand for limited throughput led to skyrocketing transaction fees and slow confirmations, pricing out many use cases. 

For blockchain applications such as decentralized exchanges, gaming, or supply chain tracking, throughput refers to the number of actions (trades, moves, updates) that can be processed per second. If the TPS is too low, these applications either become sluggish or completely impractical. 

How Monolithic, Single-Threaded Blockchains Limit Scalability, Throughput, and TPS

Why exactly did early blockchains like Bitcoin and Ethereum have such low throughput? 

A primary reason is their monolithic and single-threaded architecture. In a traditional monolithic blockchain, every node in the network performs all the work. This includes: 

• Executing every transaction
• Maintaining the entire state
• Participating in a consensus on one chain

Execution Onchain

The execution is typically single-threaded and sequential. Simply put, one transaction’s changes must be finalized before the next begins. It ensures deterministic results, but also means that the blockchain cannot fully use modern, multi-core processing or parallelism. 

Since the transactions are processed in a strict order, the node uses only one core out of many to process them. The Ethereum Virtual Machine (EVM), for instance, was designed with this sequential execution model. It’s single-threaded because concurrent state updates could happen in an uncontrolled way. 

Simply put, if two transactions update the same account or a piece of state at the same time, it might lead to inconsistencies. This is why Ethereum processes them sequentially. 

Realistically, the design of Ethereum and Bitcoin networks never accounted for such scale as we see today. 

Managing Consensus, Execution, and Storage In One Chain

On monolithic blockchains, every full node must execute every transaction and store every piece of data. Scaling such a system by simply “adding more nodes” doesn’t increase throughput. Adding more nodes can make consensus slower as there would be more communication overhead, and you’re still constrained by the slowest node’s ability to process the chain. 

If you increase parameters on a monolithic chain with bigger and faster blocks, it has its downside. You’ll risk overwhelming nodes. Since more powerful computers with high bandwidth would be able to accommodate this, it would naturally lead to centralization, as most users may not have such advanced computers.

Due to these factors, the single-threaded architecture and “do-everything-on-one-chain” approach stage a throughput ceiling without sacrificing accessibility or security.

Modern Approaches to Blockchain Scalability

The blockchain community has developed several solutions to surpass the traditional throughput limits. The approach is to divide the workload so more can be done in parallel, or simply offload work to secondary systems. 

Below are some of these approaches. 

Sharding

Sharding is a technique that splits the blockchain’s state and transaction processing across multiple shards, which are parallel sub-chains that handle a portion of the transactions. 

A sharded architecture is considered linearly scalable if adding more shards increases the TPS linearly. However, implementing sharding is complex. It requires mechanisms for cross-shard communication. This is because a transaction on shard A might need to interact with an account on shard B while ensuring security. 

Overall, sharding effectively addresses the single-thread bottleneck by having multiple threads (shards) run concurrently, but it introduces new challenges in maintaining system coherence.

Layer-2 Rollups

Rollups move transaction execution off the main chain (Layer 1) and post only summarized data or proofs back to the L1. There are two main types: 

• Optimistic rollups assume transactions computed off-chain are valid and only run a fraud-proof on L1 if there’s a challenge. They bundle hundreds or thousands of transactions into one batch, post a compressed representation on L1, and amortize the cost. The downside is a longer finality if you consider withdrawing to L1. Examples include Arbitrum and Optimism on the Ethereum network.
• ZK rollups generate a cryptographic proof of a batch of transactions’ correctness and post that proof on L1. The L1 verifies the proof, which attests that all those transactions followed the rules, without needing to execute them itself. It offers high throughput and faster finality, but the technology is more complex. 

This is a modular approach to scaling. However, they’re not the proper solution to blockchain scalability. Jay Jog adds more context to this by saying, “Layer 2 solutions come with unique challenges, primarily tied to centralization and interoperability. Many of today’s layer two blockchains run with centralized sequencers that could expose the network to transaction censorship, transaction reordering, and more.”

This suggests that the solution to EVM scalability is a different design than an L2. 

Aside from L2s, there are other alternatives for scaling throughput and TPS, such as parallel execution on a Layer 1 blockchain. Sei’s Parallelization Engine increases blockchain performance by allowing multiple non-conflicting transactions to run at the same time, instead of one after another like in traditional systems. It uses multi-core processors to speed up execution and improve scalability.

Beyond TPS: The Role of Latency and Finality

When evaluating blockchain performance, focusing solely on TPS is insufficient. It's essential to consider additional factors such as latency and finality to make an informed decision. 

Latency refers to the delay between submitting a transaction and its confirmation, which confirms the block’s inclusion (inclusion in a block), and ultimately reaching finality. Finality means the transaction is irreversible. Some high-TPS chains have relatively slow finality. For example, a blockchain could pack many transactions per second. Still, if it uses a probabilistic consensus, you might need to wait many blocks for safety. 

In Bitcoin, finality is conventionally around 60 minutes, which is impractical for many real-time use cases. Ethereum PoS improved finality (~6–12 minutes) but still isn’t “instant.” In contrast, chains like Solana or Avalanche prioritize fast finality. Avalanche offers finality in less than 1 second, and Solana offers finality in approximately 12.8 seconds. 

Fast finality is crucial for applications like payments or trading, where waiting even a minute can be too long. It also improves the user experience, as nobody wants to wait minutes to ensure their app action is completed.

TPS Isn’t The Only Metric That Matters

A balanced blockchain system needs to maximize TPS and minimize latency without compromising security. If a network has very high TPS but regularly suffers outages, re-orgs, or requires trust in a small set of nodes, it diminishes its value for critical applications. Likewise, a chain that is highly secure but processes 5 TPS with hour-long finality is unsuitable for high-volume use. The sweet spot is achieving Web2-like performance while retaining the open, decentralized, and safe nature of blockchain.

The Sei network attempts to thread this needle with a 400ms finality and block time. In Sei, time to finality is equal to the block time. It means that when a block is produced, it’s immediately final. 

Exploring Sei’s Design Principle as an Alternative Solution

Sei is a modern Layer 1 blockchain built with scalability and speed at its forefront. It combines parallel execution and consensus optimization to achieve high throughput and fast finality, all while maintaining compatibility with the widely used Ethereum environment. 

Explore Sei

Sei is a parallelized EVM chain as it runs highly parallelized execution while maintaining Ethereum compatibility. The network assumes most transactions do not conflict and can be processed simultaneously. 

Additionally, Sei features a streamlined consensus mechanism known as Twin Turbo Consensus. This involves two key optimizations at the consensus level: 

• Intelligent block propagation: The block proposer sends only the transaction identifiers to validators instead of whole blocks. Since other nodes are likely already holding the transactions in their mempools, they reconstruct the block themselves. It saves network bandwidth and speeds up propagation of new blocks.
• Optimistic block processing: Allows validators to start processing transactions during the consensus rounds before final agreement is reached. In a traditional consensus, nodes might wait until a block is agreed upon before executing its transactions; Sei overlaps these steps, cutting down idle time. 

In addition to these, Sei uses optimized storage and state management, which helps the network optimize operations toward better efficiency. As a result, Sei has achieved a 400ms time to finality, which is equal to the block time. 

The Sei network demonstrates the ability to manage up to 100 megagas per second. Most importantly, Sei achieves this without sacrificing compatibility.  It is entirely EVM-compatible, enabling developers to deploy Solidity smart contracts and use Ethereum tooling. This lowers the barrier for projects to build on Sei since they can reuse code and knowledge from the Ethereum ecosystem. 

Learn more about EVM-compatible blockchains and see why Sei’s value is unique.