Concurrency and Parallelism in Smart Contracts, Part 1

Why Ethereum’s Throughput is so Frustatingly Low

Published in

Coinmonks

4 min readSep 29, 2021

Ethereum is slow — excruciatingly slow. I recently did a simple USDC approval transaction that took roughly 3 hours to validate. Here’s a more illuminating statistic: Ethereum, on average, publishes a block every 10~20 seconds. Each block contains less than 350 transactions. All of this roughly translates to 30 transactions per second (tps). When criticizing Ethereum’s slowness, Visa’s 2,000 tps is often brought up. Perhaps this is an unfair comparison since Ethereum is still very much in development. However, it certainly seems unlikely that Ethereum will be dominating digital finance anytime soon.

Ethereum’s low throughput is a foundational problem. Ethereum is an Account-Based Blockchain: the ledger state is defined as a key-value mapping from an account address to a piece of data. A simple ETH transaction (Value Transfer) increments and decrements the ETH balance data of an account pair. Similarly, a more complex transaction (Contract Call) will mutate the data of specified accounts. In this context, an Ethereum transaction is a transition function on the global ledger state. This is what makes the Ethereum Virtual Machine (EVM) Turing Complete and allows smart contracts to be possible; an Ethereum smart contract is essentially an interactable piece of account data.

Now let’s look at how EVM processes or validates these transactions. Note that it would be unreasonable to process all transactions in parallel. By design, all transactions are attempting to mutate the entire global state. If transactions were to run in parallel, the EVM would be partial to Race Conditions: two programs (in this case transactions) try to increment a uint variable in parallel. Because the two programs are accessing the variable simultaneously, the variable is incremented only once instead of twice. To solve such concurrency bugs, Ethereum opts to process transactions one by one. In other words, EVM is a Single-Threaded state machine. As a result, Ethereum achieves Concurrency, but not Parallelism.

Ethereum is analogous to a ticket queue with only one teller whose inconsistent in their processing time. The people in line are the transactions awaiting validation, and the lone teller is the Virtual Machine. Things become more complicated when we factor in gas fees. Now, anyone can pay extra and cut in line. An exceptionally long line will mean people who cannot pay for a better position in the queue will have to wait for an inordinate amount of time to get their tickets processed.

Ethereum’s low throughput is problematic, especially in a web3.0 perspective. Say Ethereum indeed becomes the medium of all web applications. If its current throughput were to persist, a menial task like upvoting a Reddit post might take more than two hours to process; not the most realistic vision of a future run by blockchains, but it demonstrates my point. We live in an age where speed is everything, and Ethereum is far too slow.

Why not selectively apply concurrency, you may ask. To elaborate, why not apply concurrency to just the conflicting transactions — e.g., value transfers to the same account — and process the rest in parallel. Unfortunately, Saraph and Herlihy (2019, p2) have shown us that the speed-ups achieved are modest at best.

Many solutions to expedite Ethereum and improve its scalability have been proposed. The recent EIP-1559 — the London hard fork — does not directly affect Ethereum’s transaction speed but should theoretically steady its volatility on massive transaction spikes by reducing the potential number of blocks the average user will have to wait before their transaction is processed. Then there are Layer 2 Rollups, which should directly impact Ethereum’s throughput, without jeopardizing too much of the blockchain’s precious trustlessness.

In the meantime, other blockchains simulating general-purpose virtual machines have been in active development. Some have managed to achieve parallelism, promising throughput much higher than Ethereum’s 30 tps. I want to focus on Algorand, Solana, and Cardano in particular, and their unique methods of achieving parallelism in their smart contracts.

References

Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing

Concurrency and Parallelism in Smart Contracts, Part 1

Why Ethereum’s Throughput is so Frustatingly Low

Also, Read

Written by Doyun Kim