There's a gulf between "can run" and "actually runs".
So what exactly is so complex that Ethereum runs that it processes stuff so slowly?
The good news is that there’s a lot of room for improvement in the design. The bad news is twofold: (1) efficiency improvements will eventually cause transaction processing to be data-bound rather than compute-bound, and (2) these improvements to improve compute may be incompatible with existing Ethereum nodes. ZK and optimistic rollups potentially offer a way out of this update mess that don’t require dramatic changes to the underlying consensus system. However they will also inherit some of the limitations above, including tradeoffs between availability and processing speed.
This is probably the first reply I've seen that doesn't shy away from saying "yes, we're inefficient", and looking at the solutions with a critical eye.
Blockchains are designed to meet the most extreme requirements of availability, censorship-resistance and cost of attack. They achieve them by exploring the extremes of replication of the solution space of distributed systems. For example, Ethereum runs on a Raspberry Pi, and every node runs the exact same things. Therefore how fast it goes is limited to the slowest node you want to make able to run the blockchain.
But, what you are dismissing as simple batch processing are the application of very novel techniques (novel as in math was invented in the last 5 years to make them possible) that allow to externalize most of the heavy computation outside the blockchain and delegate to the blockchain the verification of a proof. Therefore allowing to inherit the security properties of the blockchain but achieving much higher scalability.
Ethereum settles nowadays 200 bitcoin equivalent transactions per second. And is targeting to scale to 1-10M transactions per second by 2030.
All of those "oh my god complex things" on Ethereum are a variation of "look up a single number in one account, look up a second number in the other account, add or subtract two numbers".
Even doing a KYC + proper credit check on a client will cripple Ethereum.
> that allow to externalize most of the heavy computation outside the blockchain and delegate to the blockchain the verification of a proof.
So, batching. But with an extremely complex processing that you trust devs implemented correctly.
> Ethereum settles nowadays 200 bitcoin equivalent transactions per second.
No one cares about "equivalent transactions" to be honest. People care about actual things being handled by actual transactions they engage in.
Nothing against the talented devs working at Klarna, but if they have trouble handling the load, they can always add a couple TB of memory or a couple hundred CPU cores.
Ethereum needs to solve 100k tps while continuing to run on a Raspberry Pie on a home internet connection.
Ouch. Burn :)
A lot of fat has been trimmed from Kred and it's now rammed into an AWS instance, but the pain is real :)
> Ethereum needs to solve 100k tps while continuing to run on a Raspberry Pie on a home internet connection.
To run a node you need a 2TB disc, at least 16 GB of RAM and a quad-core CPU. So, not on Raspberry Pi yet (and probably not ever).
This is just an example, there is plenty other hobbyists doing so.
And here detailed instructions for you to try at home: https://docs.rocketpool.net/guides/node/local/prepare-pi.htm...
So, for a single combination (Geth + Nimbus) it may just be possible to run this tower of babel on a Raspberry Pi. And.... The only thing it will be doing is... nothing, really.
> Congrats, you've reinvented batch processing.
This is an extreme over-simplification of zero knowledge proofs. You would do well in digging deeper what is being achieved instead of dismissing it without any understanding.