Note in this post: I had skimmed over the thread and started typing but I missed the topic. I think the writeup is still related to the thread title “Decentralization goals” as it reframes the idea of “just pump gaslimit” into “price resources properly”. But now after reading again I realized you were focusing on hardware to figure out how much leeway is there to increase the gaslimit. I don’t think the issues will be solved by insisting on the idea of hardcoded costs on a bigger volume, but since my post is a bit out of scope you can ignore.
If you want to scale Ethereum, you need to think about the worst case. Multiplying gas x100 is a bad idea. The fundamental problem in Ethereum scaling is resource pricing: the cost of resources is not related to its price.
There are various resources:
- Storage creation (if clients need to store N + 1 elements)
- Storage upkeep (how long will clients need to remember something?)
- Storage diff
- Storage access (applies for reading storage, account balances and bytecode)
- Memory (creating and reading temporal memory)
- Max memory (how much are clients expected to track in the same tx context?)
- Bandwidth (how much needs to be transferred around the internet? Txs and their calldata, blockhashes, PoS consensus stuff…)
- Compute (either in the EVM, ECDSA or other precompiles)
These resources are priced according to hardcoded rules, and that means that a series of ugly patches have been applied to prevent everything from collapsing. For example, loading account bytecode (as in, loading a contract) is artificially cheap. If it was priced the same way as cold SLOAD are, it would be very expensive. So there were attacks loading contract bytecode, and this ugly patch was made: EIP-170: Contract code size limit
There is no flexibility on how these resources are priced. A way to fix the problem is pricing each resource with its own token, and controlling the issuance rate and maximum usage per block of those resources.
Another is to have different measures of gas per resource (the resources outlined above), and have the clients vote dynamically the price of those tokens. This is what I’m going to propose below.
Example:
We have this price chart
- Storage creation: 50_000 gwei per word (note that e.g. when you SSTORE a slot 0 → !0, that’s two words, key and value!)
- Storage diff: 5_000 gwei
- Storage cold access: 500 gwei
- Memory: 5 gwei per create/read
- Bandwidth: 100 gwei per 32-byte word
- Compute unit: 0.05 gwei (like, ADD spends 1 compute unit. but you could have ECDSA spend x20000 compute units)
Let’s leave storage upkeep pricing out because I don’t know how I would tackle the problem without needing a time tracker per word, although this could be a convenient solution.
In this model, Creating or reading smart contract bytecode would be priced the same way as storage! Mind this if you storage is too cheap.
And we have these limits:
- Max Storage creation per block: 10000 slots worth (note this would effectively mean max contract size is 320 KB)
- etc etc I think you get the point.
The idea here is our block proposer chooses the TXs, and as part of the PoS the clients get to vote to raise, maintain or lower a threshold per every resource. If the network believes storage is underpriced because the state growth is getting out of control (like it is right now), then they can raise the price. Or they can charge more per year of word storage.
The other grand problem with Ethereum is there’s no sort of garbage collection. All ideas to remove state got broken because they could cause issues, such as gas refunds being an attack vector, SELFDESTRUCT, etc. The garbage needs to be removed. There’s way too much state in Ethereum and there seems to be no way to get rid of it. Here’s a fictitious example of rubbish all clients need to remember:
address(0x14b0…2904) has 12.135 FROG, a forgotten 2017 shitcoin.
If someone wants this trash to be in the protocol, and wants all clients to remember it, they must pay for it, because having the “biggest computer of the planet” remember 64 bytes of garbage does not come for free. This is even worse in the case of smart contracts.
- If Selfdestruct is changing way too much storage in many clients, don’t remove the option, just price it accordingly.
- If SSTORE !0 → 0 is allowing people to do a massive attack thanks to the refunded gas, just don’t refund the gas until the end of the transaction. And only refund a portion of it.
If Storage was properly priced, we would immediately see the effect of application developers being more responsible with their gas usage, designing contracts that can remove unneeded information. The storage required to hold the bytecode of smart contracts would have to be paid for, as with all storage it needs an upkeep to keep clients from removing it.