Question 1

Blockchain throughput vs latency

Accepted Answer

TL;DR: Throughput and latency are two different measurements of blockchain performance that are frequently confused. Throughput is capacity: how many transactions the network can process per second (TPS). Latency is speed: how long it takes for an individual transaction to be confirmed and finalized. A highway analogy helps clarify the distinction. Throughput is how many cars the highway can carry per hour. Latency is how long it takes one car to drive from entrance to exit. A highway can have high throughput (many cars) but high latency (slow speed due to congestion), or low throughput (few cars) but low latency (each car moves fast). The best blockchains optimize for both, but tradeoffs are real. The Simple Explanation When people ask "which blockchain is the fastest?" they usually mean latency: how quickly does my transaction get confirmed? But the marketing materials for most blockchain projects emphasize throughput: how many transactions per second the network can handle. These are related but distinct metrics, and confusing them leads to poor architectural decisions and unrealistic performance expectations. Throughput, measured in transactions per second (TPS), tells you how much total work the network can do. Ethereum processes roughly 15-30 TPS. Solana processes hundreds to thousands of TPS in practice. Bitcoin processes 5-7 TPS. These numbers represent the aggregate capacity of the network, the total number of transactions from all users that can be included in blocks per second. Latency, measured in seconds or minutes, tells you how long your individual transaction takes from submission to finalization. On Ethereum, a transaction is typically included in a block within 12-24 seconds but is not considered final until roughly 12-13 minutes (two epochs of finality). On Bitcoin, a transaction usually appears in a block within 10-60 minutes and is considered reliably settled after six confirmations (roughly 60 minutes). On Solana, a transaction is typically confirmed within 400 milliseconds to a few seconds. A blockchain can have high throughput but high latency (processing many transactions per second, but each one takes a long time to finalize), or low throughput but low latency (processing few transactions per second, but each one finalizes quickly). The ideal is high throughput and low latency, but achieving both simultaneously without sacrificing decentralization or security is the core engineering challenge of blockchain design. Why the Distinction Matters for Developers The throughput-latency distinction has direct practical implications for application design. If your application is a payment system, latency is the primary concern. Users waiting at a checkout counter care about how quickly their individual payment confirms, not how many other payments the network is processing simultaneously. A blockchain with 100 TPS and 2-second finality provides a better payment experience than one with 10,000 TPS and 60-second finality. If your application is a high-volume data platform (like a DEX aggregator, a gaming backend, or an analytics service), throughput matters more. You need the network to handle a large number of concurrent operations without the system becoming congested and degrading performance for all users. A blockchain with 10,000 TPS and 10-second finality may be preferable to one with 100 TPS and 1-second finality if your application generates thousands of transactions per second. For infrastructure providers and node operators, the distinction affects how they architect their systems. High-throughput chains produce more data per second, requiring more bandwidth, storage, and processing power from nodes. High-latency chains with probabilistic finality require more sophisticated reorg handling in data pipelines. Understanding the throughput and latency profile of each chain you support determines your hardware requirements, your data pipeline design, and your cost model. What Affects Throughput Throughput is primarily determined by three protocol parameters: block size (or gas limit), block time, and transaction complexity. Block size defines the maximum amount of data or computation that can fit in a single block. Ethereum's gas limit caps the total computation per block. Bitcoin's weight limit caps the total data per block. Larger blocks can include more transactions, increasing throughput, but they also take longer to propagate across the network (increasing the risk of forks) and require more resources from nodes (potentially reducing decentralization). Block time is how frequently new blocks are produced. Ethereum produces blocks every 12 seconds. Bitcoin every 10 minutes. Solana every 400 milliseconds. Shorter block times increase throughput because the network processes blocks more frequently, but they also increase the communication overhead between nodes and can introduce stability challenges. Transaction complexity varies by chain and by transaction type. A simple ETH transfer uses 21,000 gas, while a complex DeFi interaction might use 500,000 gas or more. Chains that handle simpler transactions (or that optimize execution through parallelism, as Solana, Sui, and Monad do) can achieve higher TPS for a given block size and block time. Consensus mechanism overhead also impacts throughput. Proof-of-work systems like Bitcoin devote significant resources to mining, limiting how quickly blocks can be produced safely. Proof-of-stake systems reduce this overhead but still require communication rounds between validators. BFT-style consensus (used by chains like Cosmos, Aptos, and Sui) can achieve faster finality but typically requires a smaller validator set, which has implications for decentralization. What Affects Latency Latency for an individual transaction has several components: mempool wait time (how long the transaction sits in the queue before being selected for a block), block production time (how frequently new blocks are created), propagation time (how long it takes the new block to reach all nodes), and finality time (how many additional blocks or epochs must pass before the transaction is considered irreversible). Under normal conditions, mempool wait time is minimal because block capacity exceeds demand. During congestion, mempool wait time dominates latency as transactions compete for limited block space. Transactions with higher fees are selected faster; transactions with lower fees may wait through multiple block production cycles. Finality model is the biggest differentiator in latency between chains. Chains with instant (deterministic) finality, like those using Tendermint-based consensus, confirm transactions in a single round of consensus with no possibility of reversion. Chains with probabilistic finality, like Bitcoin and Ethereum, require multiple confirmations before a transaction is considered settled. The difference is dramatic: a transaction on a Tendermint chain is final in seconds, while a Bitcoin transaction is not reliably final for an hour. Layer 2 networks add complexity to the latency picture. A transaction on Arbitrum or Base confirms quickly on the L2 (sub-second to seconds), but the underlying data is not settled on Ethereum L1 until the rollup posts its proof or batch, which can take minutes to hours. Depending on the security requirements of the application, the relevant latency might be L2 confirmation time (fast) or L1 settlement time (slow). What is the difference between throughput and latency? Throughput and latency are easy to confuse because both describe speed, but they answer different questions. Throughput is about volume: how many transactions the whole network can clear per second. Latency is about an individual transaction: how long it takes to go from submitted to final. The two can move independently, which is why infrastructure teams often track them alongside RPC latency separately. The table below lays out the contrast. AspectThroughputLatencyWhat it measuresTotal capacity of the networkSpeed of a single transactionUnitTransactions per second (TPS)Seconds or minutesHighway analogyCars per hour the road carriesTime for one car to crossMatters most forHigh-volume data platformsPayments and interactive appsImproved byBigger blocks, shorter block times, parallel executionFaster finality and less congestionKey riskNode resource and decentralization pressureLong confirmation waits How do throughput and latency compare across blockchains? Different chains land in very different places on the throughput and latency map, largely because of their consensus designs and finality models. The table below gives approximate figures for several widely used networks. Treat them as rough guides, since real numbers shift with network conditions and protocol upgrades. BlockchainThroughput (TPS)Block timeTime to finalityBitcoin5 to 7About 10 minutesAbout 60 minutesEthereum15 to 30About 12 secondsAbout 12 to 13 minutesSolanaThousandsAbout 400 msSecondsArbitrumThousandsAbout 250 msSeconds on L2, longer to settle on L1BNB Smart ChainDozens to hundredsAbout 3 secondsAbout 2 to 3 seconds Can a blockchain have high throughput and low latency at the same time? In principle yes, but pushing both at once usually costs something else, most often decentralization. Bigger blocks and shorter block times raise throughput, yet they also demand more from every node, which can shrink the set of participants who can keep up. This tension is the core of the decentralization vs performance tradeoff. One common way to get both speed and capacity is to move execution off the base layer onto a Layer 2 blockchain, which confirms quickly while still settling to a secure Layer 1. How does network congestion affect throughput and latency? Congestion is where the two metrics collide. When demand exceeds block space, transactions pile up in the mempool, fees rise, and latency spikes even though the chain is still processing near its maximum throughput. In other words, the network is busy but slow for any single user. Understanding what causes blockchain congestion and the broader reasons blockchains slow down helps you design applications that degrade gracefully instead of stalling when traffic surges. Frequently Asked Questions Is higher TPS always better? Not necessarily. High TPS only helps if your application actually generates high transaction volume. For a payment app or an interactive product, low latency and fast finality usually matter more than raw capacity. The right metric to optimize depends on your workload, not on which number looks largest in marketing. Does low latency mean a transaction is final? No. Fast confirmation is not the same as finality. A transaction can appear in a block quickly yet still be reversible until the chain reaches its finality threshold. On chains with probabilistic finality you wait for multiple confirmations, while deterministic chains finalize in a single consensus round. See blockchain finality for the full distinction. How is RPC latency different from blockchain latency? Blockchain latency is how long the network takes to confirm a transaction, while rate limiting and provider response time add a separate, infrastructure-level delay to every request your app makes. A fast chain can still feel slow if your RPC layer is overloaded, which is why both layers matter. Do Layer 2 rollups improve throughput or latency? Both, with a caveat. A rollup raises effective throughput and gives fast confirmations on the L2, but full settlement back to Layer 1 can take longer. Whether the fast L2 time or the slower L1 time is the relevant latency depends on how much security your application requires. Which blockchain has the best throughput and latency? There is no single winner; it depends on what you are building. Solana and other high-performance chains lead on raw TPS and sub-second confirmation, while chains with deterministic finality settle fastest, and Bitcoin trades both for maximum security and decentralization. Match the chain's profile to your application's needs rather than chasing a single headline number. How Quicknode Helps Developers Navigate Both Quicknode's infrastructure is optimized for both throughput-intensive and latency-sensitive workloads. The Core API delivers low-latency RPC access through a globally distributed node network across 80+ chains, with response times 2.5x faster than competitors. This directly reduces the infrastructure-contributed latency for every RPC call your application makes. For chains where latency is especially critical (like Solana's 400ms slots), Quicknode supports Yellowstone gRPC, which uses binary Protocol Buffers instead of JSON for faster serialization and lower overhead. For throughput-intensive workloads, Quicknode Streams handles high-volume data ingestion regardless of the underlying chain's TPS. Whether you are indexing Ethereum at 15 TPS or Solana at thousands of TPS, Streams delivers complete block data to your destination with guaranteed delivery and configurable batching for optimal throughput. Dedicated Clusters provide isolated infrastructure for applications that need predictable performance under variable network conditions, ensuring that congestion-driven throughput spikes do not impact your data pipeline's reliability. Further Reading QuickLee - Blockchain Latency Benchmarking Tool Justifying Quick in Quicknode: Response Time Comparison - Quicknode Blog Getting Started with Streams - Quicknode Docs

Question 2

What causes blockchain congestion?

Accepted Answer

Blockchain congestion happens when more transactions are sent to a network than fit in the next block. Every chain has a cap on how much computation or data it can process per block. When demand goes past that cap, a backlog builds in the mempool, the waiting area for unconfirmed transactions. Congestion means higher fees as users compete for limited block space, slower confirmations, and a worse user experience. The root causes are fixed block capacity, demand spikes from popular events, fee market dynamics, and design choices that put security and decentralization ahead of raw throughput.

Question 3

Why blockchains slow down

Accepted Answer

Blockchains slow down when demand for block space exceeds the network's processing capacity. The most common causes are network congestion (too many transactions competing for limited block capacity), state bloat (growing storage requirements that increase the computational cost of processing each block), consensus overhead (communication costs that scale with validator count), and infrastructure limitations (slow nodes, high-latency RPC endpoints, and inefficient data pipelines). Slowdowns manifest as longer confirmation times, higher fees, stale data in applications, and degraded user experience. Some causes are inherent to blockchain design, while others can be mitigated with better infrastructure.

方面	吞吐量	延迟
测量内容	网络总容量	单笔交易的速度
单位	每秒交易量（TPS）	秒或分钟
高速公路的比喻	该道路每小时通行车辆数	一辆车通过所需的时间
最重要的是	海量数据平台	支付与交互式应用程序
由……改进	更大的区块、更短的区块生成时间、并行执行	更快的交易最终性，更少的网络拥塞
主要风险	节点资源与去中心化压力	漫长的确认等待

区块链	吞吐量（TPS）	时段	最终裁决所需时间
Bitcoin	5 到 7	大约10分钟	大约60分钟
Ethereum	15 至 30	大约12秒	大约12到13分钟
Solana	数千	约 400 毫秒	秒
Arbitrum	数千	约 250 毫秒	L2上只需几秒，L1上则需要更长时间才能结算
BNB Smart Chain	数十到数百	大约3秒	大约2到3秒

想随时了解最新动态吗？

开发者工具

文档与指南

区块链吞吐量与延迟

简明解释

为什么这种区分对开发者很重要

哪些因素会影响吞吐量

哪些因素会影响延迟

吞吐量和延迟有什么区别？

不同区块链的吞吐量和延迟有何差异？

区块链能否同时具备高吞吐量和低延迟？

网络拥塞如何影响吞吐量和延迟？

常见问题解答

TPS 越高就越好吗？

低延迟是否意味着一笔交易已最终确认？

RPC 延迟与区块链延迟有何不同？

第2层Rollup能否提升吞吐量或降低延迟？

哪种区块链的吞吐量和延迟表现最佳？

Quicknode 如何帮助开发者应对这两方面

延伸阅读

立即开始构建