I'm reading about the on-chain scalability solutions. At the moment I'm looking at sharding.

Currently, in all blockchain protocols each node stores all states (account balances, contract code and storage, etc.) and processes all transactions. This provides a large amount of security, but greatly limits scalability: a blockchain cannot process more transactions than a single node can. In large part because of this, Bitcoin is limited to ~3-7 transactions per second, Ethereum to 7-15, etc.

I cant seem to understand this, could someone elaborate?

So in other words:

The number of transactions the blockchain can process can never exceed that of a single node that is participating in the network.

Further more:

In a traditional database system, the solution to scalability is to add more servers (i.e. compute power) to handle the added transactions. In the decentralized blockchain world where every node needs to process and validate every transaction, it would require us to add more compute to every node for the network to get faster. Having no control over every public node in the network leaves us in a pickle.

So if I understand this correctly, the weakest node (or is it full node?) in the blockchain sets the limit on tx/s. Why is that? Is it possible then to add a really really slow node that slows down the whole processing of transactions?

2 Answers 2


Distinguish between mining nodes and non-mining nodes. The latter have nothing to do with the speed of the chain. Non-mining nodes are simply following along behind the miners.

Think now about the miners--a slow miner will almost always lose the race to produce a block to a fast miner. Therefore, they will have no ability to slow anything down. The chain simply moves forward. Slow miners keep up if they can.

Think about keeping up. A huge part of the time it takes to find a block is spent searching for the block hash at a given difficulty level. (This is why fast miners usually win--they can scan many more hashes.) Verifying the block once it's found takes very little time (by design). Once a block is found, all the nodes (both slow and fast) verify it very quickly, and everyone moves to searching for the next block hash.

The fastest miners move the chain forward. The difficulty level forces the miners to waste electricity for 14 seconds (on average) per block.


No, there is no limiting the Ethereum Blockchain with slow nodes. But it wouldn't survive, if the tech specs required to run a node were so high that only very powerful computers could catch up with the calculations to be done. That's why you limit Ethereum's performance, so more people can take part in the network, also with slower computers or even a Raspberry Pi (tough job though ;) ). Of course the network could agree on more performance in the next couple of years, where the average computing power per node will be higher, but do we want to leave smaller and slower devices behind?

  • So Ethereum has a "minimum requirement" on nodes? Are we talking about nodes or full nodes?
    – gel
    Sep 26, 2017 at 14:06
  • For now, in the most cases nodes == full nodes. Although I havn't seen any min. system specs for node clients yet (maybe there are some official recommendations out there), it's clear they won't run on a calculator. The lower you set the bar, the more "devices" are able to take part.
    – n1cK
    Sep 26, 2017 at 15:35
  • I'm still confused. Does all the miner nodes wait for the weakest mining node?
    – gel
    Sep 26, 2017 at 17:59
  • It's the other way round: The nodes sync with mined blocks from the network and apply the contained calculations to their state. Imagine the latter taking more time than the mining of blocks, the nodes could never sync. This is easily the case on slower IoT devices if the complexity of calculations when syncing is high.
    – n1cK
    Sep 29, 2017 at 9:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.