4 ms·
Making "mining" cheap, and speeding up the network, were originally supposed to be one project, but got split into two separate efforts so that PoS could be shi
by derefr 4y ago
Making "mining" cheap, and speeding up the network, were originally supposed to be one project, but got split into two separate efforts so that PoS could be shipped sooner (and so stop consuming half the world's supply of GPUs + 0.1% of all electricity sooner.) Gas is still expensive because "space for transactions in a block" is still a scarce resource, because blocks are still only being produced once per 10 seconds.
And they can't just flip a switch making it go N times faster right now, because transaction execution is a serial bottleneck — a "full" Ethereum node can only evaluate transactions at the speed of a single pinned CPU core, and the average CPU's single-core performance isn't going to become orders-of-magnitude faster any time soon. So there is currently a fundamental limit on how many transactions the network can execute per second, regardless of how they're packed into blocks. (And also, even if there was no such bottleneck, the per-node chain state would also then be growing N times faster, which causes its own scalability problems.)
Sharding will fix both of those problems, making the chain into N independent shards where any given "full" node only has to sync some reasonable subset of said shards, and where a node syncing multiple shards can run those syncs independently in parallel (and so — presuming a large number of shards — can use as many CPU cores as are available.) But sharding is not done yet. So gas fees remain for now.
- MuffinFlavored 4y agowhen might sharding be in production?
- moffkalast 4y agoAh interesting info. I wouldn't have thought that to ever be the problem, but then again I guess Ethereum does all those smart contracts and extra processing now which is bound to increase complexity I guess. There should still've been a massive speedup to block confirmation, no? I thought that the final mining part had to be applied to an already computed block, which would be sequential.
- derefr 4y agoYes, but this only really means that you can now get blocks out faster (lower block times), not that you can evaluate more transactions to put in them. And you can only start evaluating those transactions once you see the previous block, since you need to know what transactions are now confirmed and so should not be included in your block (save for "greedy" mining that doesn't put any txs in the block in order to avoid waiting — which doesn't really work with Ethereum's GHOST consensus-selection anyway.) Block times on Ethereum were already very long compared to other Ethereum-alike blockchains, to reduce the impact of mining processing on throughput (i.e. if block time is 10s, then you only need to deal with mining overhead once per 10s period.) Combined with the fact that people were spending exactly as much on GPUs to accelerate this process as profit margins would allow, and you'll find that not that much wall-clock time was really being spent per minute on the sequential bottleneck of mining. It's the aggregate CPU time that was being spent on mining that was economically and ecologically damaging.