Your Favorite 100k TPS Chain is Probably Slow

Why "The More, The Better" is a Lie

Alice is selling her car to Bob and wants to get paid on her favorite blockchain. How long does she need to wait to be sure Bob's payment is confirmed?

1. Bitcoin (BTC): ~5-7 TPS → 60 min confirmation time
2. Ethereum (ETH): ~17 TPS (~1.22 Mgas/s) → 13 min confirmation time
3. Polygon (MATIC): ~35 TPS (~7.5 Mgas/s) → 4 min confirmation time
4. Stellar (XLM): ~200 TPS → 5 sec confirmation time
5. Arbitrum (ARB): 40k TPS (3.04 Mgas/s) → 13 min confirmation time, same as Ethereum
6. Solana (SOL): 65k TPS → 13 sec confirmation time
7. MegaETH: 100k TPS (~10 Ggas/s) → 13 min confirmation time, same as Ethereum

But wait, shouldn’t the chain with the highest TPS (or GPS) be the fastest? No. TPS, i.e., the average number of transactions finalized per second, isn’t the whole story. While heavily marketed as the metric for blockchain performance, high TPS doesn’t always mean faster payment confirmation. Confirmation times depend on other factors: how the blockchain finalizes transactions, its consensus mechanism, and its execution layer.

Let’s try to understand what is happening here with a simple analogy.

The Problem of Pizza Baking, or High Throughput

Imagine transactions are like pizzas, and Alice’s transaction confirmation is when she gets to savor the hot, delicious pizza she just ordered online. For Alice, satisfaction hinges on one crucial factor: speed. In distributed systems, this is called latency or Time-to-Finality (TTF). It’s the time between a user initiating a transaction and that transaction becoming final. Final means that the transaction is permanently included in the blockchain and can no longer be undone or reverted.

Let’s analyze the pizza-to-Alice process to understand the bottlenecks in transaction confirmation. First, when a pizza order comes in, the shop needs to prepare and bake the pizza. If there are too many orders and only one small oven, pizzas need to wait to enter the oven and the baking process gets delayed. This is similar to the congestion problem: too many incoming transactions saturate the blockchain capacity, delaying inclusion.

Blockchains solve congestion by increasing their TPS, but baking many pizzas in parallel only means that Alice’s pizza gets baked immediately. It does not mean Alice will get her pizza quickly!

The Problem of Pizza Assignment, or Execution Bottleneck

After the pizza is baked, it must be assigned to the correct address and bundled with other pizzas in the same order, if any. If only one person is responsible for checking the pizza and assigning the correct delivery address to the different stacks, it doesn’t matter how quickly pizzas can be baked: this person becomes the bottleneck. Similarly, even with high TPS, if validators must execute and validate every transaction of the blockchains, execution becomes the fundamental limitation.

This was the problem in Ethereum, which is now effectively solved by rollups. Rollups separate transaction ordering from execution, using the Ethereum blockchain as a “dirty” ledger that stores the order of transactions without validating them. A party named Sequencer posts an ordered list of transactions and the resulting rollup state on-chain, offloading execution costs from validators. This is equivalent to hiring extra hands to speed up the checking and address assignation phase.

The Problem of Pizza Delivery, or Low Latency

But here's the thing: Alice doesn't care if the pizza place churns out 10,000 pizzas a day or match pizza-address in record time. What matters to her is how promptly her pizza gets to her, hot and steamy. The same goes for blockchains: High throughput and fast execution are great, but if transactions take forever to become final, users are left waiting.

Rollups alleviate the execution bottleneck, but in the best case, they inherit Ethereum's latency. In the worst case, they introduce additional delays: For example, Arbitrum [5] has a long dispute period (~6.4 days), while zkSync [6] requires time (~1 hour) to generate zk-proofs.

So, where's the bottleneck? It's in the consensus process or, in our analogy, in the delivery system.

Our pizza place can now quickly bake many pizzas and assign them fast but struggles to meet Alice's desired short delivery window. One obvious solution seems to be loading more pizzas onto a big truck and delivering them in bulk - akin to increasing the block size in blockchain consensus. However, larger blocks take longer to propagate across the network, and to maintain security, the ratio between block propagation time and block generation time must remain constant, meaning larger blocks increase latency.

However, the issue is more than the capacity of the delivery truck. No matter the size of the truck, its speed is limited by traffic laws, just like consensus protocols impose fundamental limitations on blockchains: Longest-chain protocols need multiple confirmation blocks for finality whereas Byzantine Fault Tolerance (BFT)-based protocols need several rounds of voting. These requirements ensure security and guarantee that all validators have the same order of transactions, but they also hinder low latency.

A Better Delivery System

But wait, how do we actually deliver pizzas? Did you ever see a bulky truck full of pizzas?!? No, we use several motorbikes and group deliveries efficiently! Motorbikes are faster, more agile, and better suited for delivering hot pizzas within Alice’s satisfaction window.

So why do we keep driving in trucks in the blockchain world?

Acknowledgements

We thank Shresth Agrawal, Zeta Avarikoiti, Orestis Alpos, and Lukas Aumayr for the provided resources, fruitful discussions, and feedback.

References

[1] https://ee374.stanford.edu/blockchain-foundations.pdf

[2] https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro

[3] https://docs.optimism.io/stack/transactions/transaction-finality

[4] https://docs.zksync.io/zk-stack/concepts/finality

[5] https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction

[6] https://docs.optimism.io/stack/fault-proofs/explainer

[7] https://www.cryptofrens.info/p/tiers-of-transaction-finality-for

[8] https://megaeth.systems/research

[9] https://pod.network/blog/wait-why-do-we-need-consensus-again

[10] https://arxiv.org/abs/2003.11506

[11] https://arxiv.org/abs/2310.18042

‍