Let addresses directly store gas for refunds

[Mister-Meeseeks]

This is a general idea for an EIP, but I'd like to solicit informal feedback here before proceeding.

Many sophisticated users implement a trick, where they exploit the contract self-destruct refund to lower their gas usage on expensive transactions. In fact this is even so common, that there's even a token built around this. The idea is that you "store" gas by creating a bunch of dummy contracts, when gas is cheap. Then you "spend" it by self-destructing those dummy contracts when gas is expensive. Ballpark estimate is that 95%+ of calls to SELFDESTRUCT come from these gas tank contracts.

In general, I think this behavior is "good" for the health of the blockchain. In effect it acts as a shadow version of EIP-1559, by shifting gas usage from when the network is congested to when it is not. The downside is that in aggregate, the contract creation/self-destruct cycle burns a lot of gas unnecessarily. That part contributes to the gas shortage. Creating a contract costs 32k Gwei, plus more for the byte code. Self destruct spends another 5k Gwi, but refunds 19k. Overall, each one of these "gas-tank" contracts slurps up 20k Gwei from the aggregate gas supply. Not to mention, the cost associated with bookkeeping, like tracking contract owners. From an economic standpoint this is far too high a cost, since a "store-and-spend" cycle has a net zero impact on the long-term state growth.

Would it not be an improvement to simply incorporate "gas storage" as part of the EVM? That leaves the advantage of smoothing congestion, but doesn't needlessly waste gas supply. The second effect is it would democratize access to this ability, whereas now it's only available to highly sophisticated players. I propose the introduction of a new Opcode "BANKGAS" and "REFUNDGAS", which would let any contract directly store gas, and use it to refund later. Just the same as how contract self-destructs refund transaction gas.

(Secondarily, it may be a good idea to increase the refund ceiling from its current 50% of transaction cost. Given how volatile gas prices are, more smoothing is probably a good thing.)

[github-actions]

Since this is your first issue, we kindly remind you to check out EIP-1 for guidance.

[MicahZoltu]

In general, I think this behavior is "good" for the health of the blockchain. In effect it acts as a shadow version of EIP-1559, by shifting gas usage from when the network is congested to when it is not.

Currently, block space is a resource that has a fairly even availability over time, similar to cloud servers, electricity, or space on a toll road. We do not have any way (currently) to move the supply around, just as you cannot move the supply of road space from night time to day time. Because of this, we do not want people to be able to pay off-peak prices in order to use space during on-peak hours. What we want people to do is move their usage to off-peak.

There is currently a proposal floating around to remove refunds specifically because they are used predominately for paying off-peak prices for on-peak usage.

---

What I think would be an interesting problem to solve is figuring out how we can move off-peak resources to on-peak time, so during peak season we have more resources available. One could imagine this like a battery, where you save up some off-peak space for on-peak demand. For example, if blocks are empty at night, we make up for that emptyness during the daytime. 1559 does this over very short time periods, and I'm not sure how to extend the strategy over longer periods of time other than changing the base-fee adjustment rate to be very slow (which has its own set of problems).

[Mister-Meeseeks]

Thanks Micah. That explanation was very clear.

Just taking a step back, it seems that there's really a distinction between fungible and non-fungible resources. CPU and bandwidth are non-fungible. It's not feasible to double the CPU load on Monday morning in exchange for halving in on Saturday night. In your analogy they're like road space.

Whereas state growth is fungible across time. The bottleneck is the long-term average, not peak utilization. It is perfectly feasible to let blocks on Monday morning grow state size at two or even ten times the off-peak rate. In the analogy it's more like (real-life) fuel. Cars can and do use more fuel at certain times of day.

The limitation of the current EVM gas model is that it doesn't recognize the distinction between fungible and non-fungible resources. Gas refunds are a good thing if they're used to "pay" for fungible-heavy operations like SSTORE or CREATE2 or even the transaction base fee. But they're a bad thing if they're used for non-fungible operations like BALANCE, SLOAD or SHA3.

If I was designing from scratch, I'd fix it by creating a second type of fungible gas (F-gas). Each OPCODE and fee schedule row would have both a gas and F-gas cost attached. Accounts would be able to "bank" F-gas during low cost periods, then use it as a refund to the F-gas specific cost of their transactions. That's a pretty major overhaul though, so I recognize that it's not practical.

But a less radical approach might be changing the general-purpose gas refunds to operation specific pre-allocations. For example, maybe let users pre-pay for future SSTORE operations, then "spend" those allocations at a much reduced gas fee later.

[MicahZoltu]

Very good point about the fungible vs non-fungible (with respect to time) gas costs. It is an interesting idea to have some mechanism by which you can explicitly ensure that storage space is not being used during off-peak and then use that storage space during on-peak. One can imagine an account being initialized with a "new storage slot creation" counter (20,000 gas initialization cost) and then paying 20,000 * num_purchased + 5000 gas to "bank" a number of new storage slot writes. Then during on-peak they could redeem those tokens for new storage slot writes instead of using gas like normal (they would still have to pay 5000 for the counter update). You could have a similar counter for banked storage slot updates as well (5000 each) and for contract creation (pay per byte).

Certainly not a trivial proposal, but I don't think it is out of the realm of possibility.

[wjmelements]

I am working on a specification here.

[RileyDesrochers]

What is the use case for storing just state_size? Why not have the gas cost of storage be fixed since it doesn't matter when it is used i.e.

total_gas_cost = (gas_used * gas_cost) + (storage_gas_used * fixed_storage_gas_cost)

Furthermore, why not have a different cost for all network resources. For example, why not lower the cost of a transaction that uses a lot of CPU but not very much bandwidth if it's in a block with transactions that use lots of bandwidth and not very much CPU? i.e.

total_gas_cost = (CPU_gas_used * CPU_gas_cost) + (bandwidth_gas_used * bandwidth_gas_cost) + (storage_gas_used * storage_gas_cost)

[MicahZoltu]

It becomes very difficult to appropriately sort transactions when there are multiple dimensions to sort by. Also, miners care much less about long term state growth but a lot more about uncle risk, so they may be incentivized to include transactions that pay very low (maybe 0) for state writes but very high network utilization gas prices.

Perhaps we could manage state growth through an EIP-1559 like mechanism alone though? We have some target state growth rate, and a base fee that adjusts up/down based on how much the user wants to write and miners can basically just ignore that since it doesn't significantly impact their uncle risk (maybe we would have a small regular gas charge for state writes to account for processing time costs).

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.