The Scalability Problem

Smart contracts made blockchain useful for thousands of applications, but success revealed a bottleneck. Ethereum processes about 15 transactions per second. Visa processes 65,000. For blockchain to support global applications, it needs to scale.

Ethereum is slow because of sequential execution. The EVM processes one transaction at a time. Network congestion is market pricing of scarce block space. Bitcoin's 7 TPS and Ethereum's 15 TPS hit the same wall: sequential processing limits throughput.

The Sequential Execution Bottleneck

Sequential execution limits blockchain throughput. Transactions execute one after another because the system cannot predict which transactions will conflict.

Consider two transactions:

• Transaction A: Alice sends 10 ETH to Bob

• Transaction B: Carol increases the price of an NFT by 10%

These transactions do not conflict—they touch completely different state. They could execute simultaneously. But Ethereum does not know this in advance. The EVM processes every transaction sequentially to guarantee consistency.

Why sequential: Smart contracts share global state, so when one contract modifies shared data, all other transactions must wait. Without knowing which accounts and contracts a transaction will touch in advance, the system cannot determine which transactions are safe to run in parallel.

Imagine Transaction C calls a contract that internally calls three other contracts, modifies six account balances, and updates complex data structures. The EVM cannot predict these effects until the transaction executes, so to guarantee consistency, it processes transactions one at a time.

Single-threaded execution creates a fundamental throughput limit, regardless of hardware improvements.

Throughput Comparison

Ethereum: Approximately 15 transactions per second. A block is produced every 12 seconds and can hold roughly 180 simple transfers (fewer if the transactions involve complex smart contract interactions).

Bitcoin: Approximately 7 transactions per second. A block is produced every 10 minutes and is limited to roughly 1 megabyte, which holds about 2,400 simple transfers.

Visa: Approximately 65,000 transactions per second peak capacity (24,000 TPS average).

Traditional payment systems process 1,000 to 10,000 times more transactions per second than blockchains. As adoption grows, this bottleneck constrains which applications are feasible.

When demand exceeds capacity, users compete for block space through fees. During high usage periods, Ethereum gas prices have exceeded $50 per simple transaction and hundreds of dollars for complex smart contract interactions. Small users cannot afford these fees, and many applications become economically infeasible.

Why Fast Blocks Don't Work

Making blocks faster and bigger sounds simple but creates two problems.

Faster blocks cause more orphans: Block propagation takes time. When a miner finds a block, they broadcast it to the network, and other miners receive it, validate it, and switch to building on top of it. This process takes several seconds.

If blocks come too fast, multiple miners find valid blocks before hearing about each other's blocks. Each builds on their own block, creating competing chain forks where only one chain survives and the others become orphans, wasting computational work.

Orphan blocks reduce security because attackers can exploit the confusion to double-spend, making the network less stable. Ethereum's 12-second block time is carefully chosen to balance throughput with low orphan rates.

Bigger blocks centralize validation: Larger blocks mean more data to download, store, and validate. A 10-megabyte block every 12 seconds requires 72 megabytes per minute—over 100 gigabytes per day just to stay synchronized.

As blocks grow, fewer people can afford the bandwidth and storage to run full nodes. When only large datacenters can validate the chain, the network becomes centralized. Permissionless verification requires that anyone can run a validator on consumer hardware.

Bitcoin's 1-megabyte blocks keep the chain small enough for individuals to validate on consumer hardware. Increasing block size improves throughput but sacrifices decentralization.

The Blockchain Trilemma Revisited

The Blockchain Trilemma explains why scaling is hard. You can optimize for two properties, but not all three simultaneously:

Security: Resistance to attacks, consistency guarantees Scalability: High transaction throughput Decentralization: Many independent validators

Bitcoin's choice: Security + Decentralization → 7 TPS

• Highly secure (never successfully attacked)

• Highly decentralized (thousands of validators)

• Low throughput (cannot support global usage)

Ethereum's choice: Security + Decentralization → 15 TPS

• Strong security (never successfully attacked at base layer)

• Reasonably decentralized (thousands of validators)

• Low throughput (high fees during peak usage)

Visa's choice: Security + Scalability → 65,000 TPS

• Strong security (fraud protection, compliance)

• High throughput (global payment network)

• Completely centralized (one company controls everything)

The trilemma is a fundamental constraint. Increasing one property requires sacrificing another. Simple throughput improvements without architectural changes will always hit this limit.

The Shared State Problem

Smart contracts sharing global state prevents parallelism.

In Ethereum, smart contracts can call any other contract. A lending protocol might interact with price oracles, token contracts, governance systems, and other lending protocols, creating dependencies that prevent parallel execution.

Consider two transactions:

• Transaction 1: User A swaps token X for token Y on Exchange Protocol

• Transaction 2: User B swaps token Y for token Z on the same Exchange Protocol

Both transactions modify the exchange protocol's state, specifically the token reserves. If they execute simultaneously, they might read the same reserve values, perform calculations based on outdated state, and write conflicting updates that overwrite each other's effects and break consistency.

To prevent this, the EVM processes them sequentially. Transaction 1 executes completely and updates state, then Transaction 2 executes with the new state. This guarantees consistency but limits throughput.

The shared state problem means every transaction is potentially dependent on every other transaction. Without knowing dependencies in advance, the system must assume everything conflicts and process sequentially.

Attempts to Scale

Four approaches have been tried to increase blockchain throughput:

Increase block size: Process more transactions per block. Larger blocks require more bandwidth and storage, reducing the number of participants who can validate. Sacrifices decentralization.

Decrease block time: Produce blocks more frequently. Faster blocks increase orphan rates, reducing security. Ethereum's 12-second blocks are near the limit before orphan rates become problematic.

Optimize execution: Make the EVM faster. This improves performance but does not solve the sequential execution bottleneck. A faster single-threaded processor still has throughput limits.

More powerful hardware: Require validators to run expensive servers. This improves throughput but reduces the number of people who can afford to validate. Sacrifices decentralization.

None of these approaches break the trilemma. They trade one property for another. Scaling without sacrificing security or decentralization requires architectural changes.

Different blockchain scaling solutions attempt to break or circumvent the trilemma through various architectural approaches.