There is a moment I still don't understand about blockchain. I've never seen ethereum client coniniously under 100% CPU or network load. So why isn't it possible to process transactions faster? I assume that 100% GPU load on mining machine is not a bottleneck, because block size is arbitrary. So, where is exactly the bottleneck?
Thanx!
There are two types of speed limits that are in play here. These are latency and throughput. Latency is the amount of time one must wait until a transaction is processed. The other is throughput: the number of transactions that can be processed in a particular amount of time. Imagine the difference between a supermarket with 100 patrons and 10 checkout counters and a grocery store with 5 patrons and one checkout counter. Now, imagine each checkout counter can process one patron per minute. In the first case, the average person waits 5 minutes to get checked out. In the second, each person waits an average of 2.5 minutes. On the other hand, the supermarket can handle 10x as many customers per minute. Thus, a busy supermarket might have higher throughput than a small grocery store, but the latency might be higher. Now imagine that both stores are closed for 20 consecutive hours a day and gets 100 customers a day. Essentially, you need to wait, on average, 10 hours to buy your groceries (the checkout time is negligible). You can see that the checkout counters show low utilization.
In Ethereum, the minimum time between blocks is, on average, around 25 seconds at the moment. Thus, the minimum latency is an average of about 12.5 seconds (i.e., if your transaction is selected for the next block, you wait on average around 12.5 seconds for it to be included). If only one transaction were sent per minute, this would have no effect on the average latency and the throughput would be one block per minute. The CPU utilization for processing blocks would remain very low. For technical reasons, the interval between blocks was previously set to a lower value to enable the network to stay in sync (i.e., so that nodes can reach consensus). This number could technically be lower, and it used to be. The average block time is rising due to the Ethereum ice age/difficulty bomb, a non-technical reason, which is being used to provide strong incentives to developers to hurry up the introduce proof-of-stake (PoS) to replace proof of work and for nodes to upgrade their clients when the PoS mechanism is introduced. Since much of the time is spent waiting for information, CPU utilization remains low.
Meanwhile, there are technical limitations regarding throughput. The first of these limits is practicality: it would be very difficulty for many/most node operators to run a node if the storage capacity required to store the blockchain grew by 1TB a week since I'm guessing not many people run (or even know how to run) systems that enable scaling their storage at that rate, if at all. There is an economic aspect to this as well: Even if people knew how, it would be costly for someone just trying to add a node for verifying transactions to keep up with that kind of growth rate.
A second technical limit on throughput is there are limits on nodes' processing and storage speed meaning that some nodes would be unable to verify blocks quickly enough to stay in sync without some sort of limit on the processing/processing involved for the transactions in each block. This results, for the same reason, in a limit on the number of transactions mining nodes could include in a block. Without a limit on processing/storage per block, it would be harder to determine what fees to include for a transaction to ensure timely processing: the number of transactions included per block could vary drastically, depending on which miner processes a block, and the network would often be out of sync. Sharding is a way around this technical limitation. Note that while waiting for a disk to return data, the CPU is twiddling its thumbs and you'd see low CPU utilization. Even if blocks ran up against processing limits on some mining nodes, faster nodes would take less time to verify a block's transactions and wouldn't see a 100% CPU utilization rate.
A third limit arises out of the technical limits on throughput above: an artificial limit on the amount of processing/storage that can be used by transactions in a block comes in the form of the block gas limit. I assume one of the reasons why this is in place is to avoid hitting either of the two technical limits. This makes it easier and cheaper to run a node. In that situation, the technical limits on throughput rise proportionally with the number of shards and the block gas limit could be raised that way, too. In practice, it may not be desirable to increase the block gas limit directly proportionally to the technical throughput of the network: I assume it is desirable for any node to be able to verify that the Ethereum network is operating as designed (i.e., to detect cheaters); as such, a node could randomly check shards' correct operation. The chance of detecting cheaters decreases with the number of shards. If you require dedicating a node to testing a single shard -- in order to keep up with the transactions -- then you can use the birthday paradox to your advantage to maintain a sub-linear growth in number of verification nodes (relative to total number of shards) to detect cheaters with reasonably high probability.
Both latency and throughput bottlenecks exist in Ethereum and there are solutions being worked on to work around both of them. The current Ethereum bottlenecks are artificial (ice age and block gas limit) but are useful to enable relatively inexpensive Ethereum nodes to exist and provide a more level playing field for users of the Ethereum network.
There are no two types like "latency" and "throughput" bottlenecks really. These ones are reduced to the "hardware" bottleneck.
So, again:
There are 2 types of bottlenecks.
1.The hardware bottleneck
2.The algorithm bottleneck
The hardware bottleneck is basically the limitation of the hardware you are running your blockchain on. If all the peers of Ethereum would use 10 Gigabit ethernet cards , 16 core processors, they would achieve higher transaction rate. Theoretically, Ethereum can handle 1,000 transactions per second.
Now, the algorithm bottleneck. The algorithm bottleneck is explained in non-technical language in this article on my website: http://www.afterether.org/blockchain-scalability-by-blockchain-clustering.html But here is just a summary:
To solve the bottleneck problem you can fine-tune the hardware and the software, or split the currency in many blockchains.
So why isn't it possible to process transactions faster?
Transactions have to be put into blocks. The number of transactions that can fit into a block is dictated by the block gas limit, so...
... because block size is arbitrary.
...blocks aren't arbitrarily large. As above, they can only be as large as the block gas limit allows. So this is one of the "bottlenecks".
So we can't change how many transactions fit into a block. Why not just have more blocks, by decreasing the amount of time between each one?
The average block time is now around 25 seconds. (It's a bit longer than Thomas suggested in his answer because we're moving towards Metropolis, and the "difficulty bomb" is kicking in, which is incrementally increasing the time between blocks.)
Making the time between blocks shorter would lead to an increase in the number of chain forks and rearrangements. Consider the scenario outlined in the white paper (also taken from this previous question):
... blockchains with fast confirmation times (i.e. block times) currently suffer from reduced security due to a high stale rate - because blocks take a certain time to propagate through the network, if miner A mines a block and then miner B happens to mine another block before miner A's block propagates to B, miner B's block will end up wasted and will not contribute to network security.
So a balance has to be found between quickly including a transaction in a block (shorter block times), and reducing the number of chain rearrangements to reach a true consensus (longer block times). Where the balance lies depends on the use-case and design of the chain. This is your second "bottleneck" (though by design).
Finally, the Ethereum block time is much shorter than the Bitcoin block time (10 minutes?). Ethereum can do this because it uses something called GHOST, which helps to recover some of the hashing power used in mining "wasted" (orphaned) blocks.
See also: What happens if the block time changes to 5 seconds?
The system must come to consensus and do so under proof of work. The designers of the system chose 14 seconds as the amount of work they wanted to impose on the miner (on average) who wins the block and receives the block reward. The best place to help you figure this stuff out is still, for my money, the original Bitcoin white paper. Others may have better sources. Learn about how Consensus and proof of work operate, and you will have your answer.
The bottleneck is most probably caused by imperfect system design. Proof of work is used to solve few problems together in bitcoin. Ripple cryptocurrency works without blockchain and has different consensus algorithm. Which, as creators claim, allows to reduce tramsaction cost to fractions of cents and confirmation time to minutes. You can watch this lecture to get more details: https://www.youtube.com/watch?v=7abKUs9tYZg
