I think the PR line is that PoS ETH can “scale to 100,000 TPS”, but it’s currently pushing 15-30 [1]. Visa does much more, though various figures are reported from 1,750 to 24,000. So, grains of salt and all that.
Important to note that Ethereum embraces the idea that L2's will provide a lot of the scale and L1 will remain the base, main layer of security. So the goal isn't for L1 to scale massively, but to be able to support a healthy ecosystem of secure L2's which scale in different ways!
Current network demand doesn’t really require them, but after EIP-4844, “100 000 TPS” should be possible.
For one, Visa just does funds transfers. If Ethereum just transferred ETH, it could do 700 tx/sec, based on the gas limit per block divided by the 20K gas for a simple ETH transfer. A lot of Ethereum transactions are more complex and use more gas.
Second, second-layer "rollups" already support transaction rates up to a couple thousand per second, without losing base-layer security guarantees. Essentially they compress the transactions on chain. (Actual traffic is much lower than that, so far.)
The longer-term plan is to move to rollups in a big way, and add a form of data sharding to multiply the on-chain data storage. That's where the 100K/sec comes from.
So... Still an order of magnitude less than Visa.
> A lot of Ethereum transactions are more complex and use more gas.
How complex are they, are they a significant number, and dies this explain the abysmal transaction rates?
Visa aside, on Singles Day AliPay does 1 to 1.5 billion transactions in one day.
Okay. AliPay is an outlier. Klarna does about 2 million transactions per day, an average of 23 per second (it's significantly higher during peak hours, and lower during off-peak hours. Source: worked at Klarna). The transaction includes: client lookup (a complicated affair that differs from country to country and session to session), credit score calculation, order set up, payment (out of a several dozen different options) set up... all while conforming to banking and local regulations across 45 countries. Anything in eth anywhere close to that complexity-wise?
> Second, second-layer "rollups" already support transaction rates up to a couple thousand per second
So layer 2 batches transaction into a batch that then gets batched on layer 1 into a bugger batch that is then written in one go to the blockchain.
Congrats, you've reinvented batch processing.
How complex? -> Turing complete. Also there is more to L2s than batching. Their aim is to maintain the security guarantees of the L1 without sacrificing availability. Plus, Zk proofs and merkle trees allow for great data compression in the rollup.
I stopped making an effort five-seven years ago for many obvious reasons.
> How complex? -> Turing complete.
Ah yes. Unlike every other system in the world that isn't?
Turing completeness isn't a feat. It's such a trivial thing that people arrive at it by accident.
Now the claim was "ethereum is abysmally slow because it runs complex things". What complex things are there that warrant this abysmal performance?
> Also there is more to L2s than batching. Their aim is to maintain the security guarantees
Yeah, yeah. It is batching for any intent and purpose. Do you really think batching in "traditional" systems is done without guarantees etc.?
You take a push down automata (finite state automata plus a stack) and then add the ability to read and write anywhere in the stack.
The essence of Turing completeness is the ability to take any intermediate result as an input to the computation of the next result.
This is why the halting problem is even a problem, because you need all of the intermediate results to know the end result.
Ok now back to the topic at hand. Turing completeness on the L1 layer isn't very impressive because every node is supposed execute the code to validate it. The problem with L2 then is the fact that you must somehow avoid that, i.e. the L2 layer executes the smart contract and determines a result and these results are batched on the L1 where the point is that you're not supposed to execute the contract as otherwise there is no speedup to be gained. It is sort of a paradox.
The end result has to be verified on chain. The most promising strategy so far is build a zkEVM which produces a zero knowledge proof that can be verified on L1 via a smart contract.
I still don't understand how this convinces people to buy Ethereum.
Money is supposed to be a medium of exchange because barter is expensive and time consuming. Instead of trading anything for anything we trade anything for money and money for anything. Competition is good but is Ethereum even competing?
How exactly do random wealth transfers to early adopters serve any purpose that money is supposed to be used for according to classical text books?
> 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.
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?
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.
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.
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.