# How many transactions per second can Ethereum currently handle? What changes will allow the network to be able to handle more? [duplicate]

I've been searching for a more precise answer to this question, but I've seen a lot of conflicting information stating that Ethereum can currently handle anywhere from 12-45 transactions per second. What is the correct current number?

In creator Vitalik Buterin's words, the long-term goal is for the platform to be able to process transactions at "Visa-scale transaction levels" or beyond.

"Visa-scale" is referenced as being 45,000 transactions per second.

• So what has to happen at the technical level in order for this goal to be realized?
• More miners?
• More nodes?
• More efficient core code?

Or will a completely new evolution of Ethereum be necessary to reach that level of transaction capacity?

I did the math to show the aprox tx/s:

• The block gas limit is 7,999,992

• Transaction costs 21,000 gas (let's assume nothing else is attached)

• That's ~380 transactions per block

• With a block time of around 15.03 seconds. As https://ethstats.net/ shows.

This gives us aproximately: 25.346 tx/s.

At the end of your question, you have mentioned some possible ways to bring this number up.

• The more miners on the network, the more network difficulty, because difficulty calculation algorithms are always trying to make the next block's time be around 15s.
• More nodes will increase the block time even more because more delay between them will appear and then, more time will be needed for them to sync with each other.

There exists an inversely proportional relationship between the consensus volume and the tx/s rate. The more time the nodes need to accomplish the sync and achieve consensus, the less tx/s you will have.

To improve all of the features you mention, there are now a few ways on which Ethereum is entering:

• Sharding (Borns, while you realize that the whole blockchain can't process more transactions than a single node, can): "Solution" -> We split the state and history up into K = O(n / c) partitions that we call “shards”. For example, a sharding scheme on Ethereum might put all addresses starting with 0x00 into one shard, all addresses starting with 0x01 into another shard, etc. In the simplest form of sharding, each shard also has its own transaction history, and the effect of transactions in some shard k are limited to the state of shard k. One simple example would be a multi-asset blockchain, where there are K shards and each shard stores the balances and processes the transactions associated with one particular asset. In more advanced forms of sharding, some form of cross-shard communication capability, where transactions on one shard can trigger events on other shards, is also included.

Ethereum Fundation is donating lots of \$ in order to incentivate the research on sharding and plasma.

Here I leave some really good github's info about sharding.

Another important improvement is the next:

• CasperFFG (As said before, PoW consensus algorithm is not scalable, because of that, new Proof of Concepts of consensus algorithms are being researched. Now Ethereum plans to move to PoS by implementing CasperFFG to start the transaction period on which 1/100 tx's will be done by PoS. Essentially it's a mixed PoW, PoS algorithm which it's purpose is to arrive one day to a PoS full implementation.) Solution -> By using PoS consensus algorithms, you eliminate the mining concept (as doing non-profitable calculations to find a hash in a certain range). Then, the block time can decrease till arriving at even 5 - 7s (Said by Vitalik Buterin).

Here I leave the CasperFFG paper's link.

There are more ideas to improve the speed of the network without losing it's main objective: consensus. But I posted the most important ones.

Hope it helps!

• 7,999,992 isn't "pi million". 3141592 is, which is what the block gas limit used to be :-) Commented May 25, 2018 at 12:55
• Propose the edit, I'll accept it!! :) Commented May 25, 2018 at 12:57
• I appreciate the incredibly thought out response. I and the community will benefit a lot from this. Commented May 25, 2018 at 14:16
• I'm not sure I understand your point on reducing the block time. (Perhaps I'm reading it in the wrong way.) If you reduce the block time to below 15s, the uncle rate will increase, which is bad. The difficulty adjustment algorithms are set so that this block time is maintained - it's not related to the number of mining nodes. Commented May 28, 2018 at 20:03
• Okay, so you're talking about a protocol change to increase the block time, rather than something that will automatically happen as a result of more nodes joining the network - thanks for clarifying. Commented May 29, 2018 at 10:14