Ethereum won’t scale like you’ve been told.
If you followed the Ethereum project over the last few years you might be familiar with the great amount of hype that comes with its community and founders. No matter if it’s app developers that claim to have a “Uber killer” or a presentation about “Decentralized Commercial Banking”… big claims are made as only the sky seems to be the limit.

Ethereum founder Vitalik Buterin gave a presentation called “The Mauve Revolution” where he talks about “tens of thousands of transactions per second” for Ethereum. If we dive some further into these claims it all comes down to the following:

Founder of Ethereum Vitalik Buterin claims he has found the ultimate solution to the problem of scalability haunting cryptocurrency networks. That will be made possible with lightning networks and sharding.

The current Bitcoin blockchain is limited to around 7 transactions per second and that number is around 15 for Ethereum. When talking about Ethereum, “transactions” aren’t the only thing that counts. Ethereum is a “decentralized computer” that runs contacts and transactions are only a small part of that. But even when we look at transactions only… the “tens of thousands of transactions per second” don’t add up. This is due to some limitation of “lightning networks”. Great that we have off-blockchain transactions but every coin in a “channel” will end up on the blockchain after all. Let’s say ALICE wants to give some Ether to BOB for a game. Why would they use a lightning network? It would only lock the Ether in some off-blockchain channel where Bob can’t do anything with it except for paying someone else. The same goes for the whole idea of a “decentralized computer” where you need Ether (gas) to run code. So all coins need to end up on the blockchain anyway. But even if we assume that 95% of all transactions take place off-blockchain? Would it match the “tens of thousands of transactions per second” for the system as a whole? The answer is no, let’s see why:

10.000 x 0.05 (5%) = 500 Tps which still take place on the blockchain.

And as we learned from Vitalik himself the current Ethereum implementation is only capable of doing 15 of them. So even with a very popular lightning network the Ethereum ecosystem goes up in smoke quite fast if the transaction volume goes up.

Time to look at the second part of the solution called “Sharding”. This idea comes close to a “multi-core” implementation on regular computer chips. Only in this case we work with a combination of several blockchains (sidechains) and EVMs (Ethereum Virtual Machines). In this article the following claim is made:

After the initial basic sharding (which will result in the implementation of Ethereum 2.0) Ethereum 3.0 will be developed — a blockchain system that will be capable of infinite sharding.

This one goes to eleven? Wrong! This one will have “infinite sharding”! That’s right: with enough EVM’s and sidechains Ethereum is capable of doing almost everything. Although this claim is again far from truth. Vitalik talks about a “main chain” to interact with several sidechains. Think of it like a Merkle tree-structure where the hashes of the lower blocks end up in the highest chain. This is completely different from your average Intel chip where calculations do happen in parallel. This is where the speed-improvement comes from. So can’t we run the EVMs in parallel then? No, this is extremely hard to sync as each sidechain has it’s own miners. 1 chain might have a valid block in 4 seconds while the other one takes up to 65 seconds. Just like the current network with only 1 blockchain:

Time delays will prevent Ethereum from infinite sharding.

And even if we could add 100 sidechains in parallel with a guaranteed blocktime we’re still in trouble with the 10K transactions per second. It means we have 100 Tps per chain (assuming even distribution). That’s far more than the 15 Tps which are possible at Ethereum’s current implementation. And notice that I’m talking about transactions here, not about calculations.

......................
.........
....
.....