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 occurs when more transactions are submitted to the network than can fit in the next block. Every blockchain has a maximum amount of computation or data it can process per block, and when demand exceeds that limit, a backlog forms in the mempool (the waiting area for unconfirmed transactions). Congestion leads to higher transaction fees (as users compete for limited block space), longer confirmation times, and degraded user experience. The root causes include fixed block capacity, demand spikes from popular events, fee market dynamics, and the fundamental design tradeoffs that prioritize security and decentralization over 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 如何協助開發者同時應對這兩項挑戰

延伸閱讀

立即開始建置