EIP-2045: Particle gas costs

[cdetrio]

Pasting comments from @sorpaas on allcoredevs:

@sorpaas

I remember we discussed this previously. Basically, any upgrades currently to EVM will break something, even adding new opcodes. The ultimate solution is of course account versioning. I think the conclusion at that time was that if we want to apply something without versioning, then we just rather decide what invariant and backward compatibility we want to preserve, and ignore issues that nobody may care, or is a clearly misuse. Remediations for EIP-1283 reentrancy bug - #83 by sorpaas

There’s a difference between bending and breaking. Small changes might bend certain use cases, large changes might break them. The statement “any upgrades will to EVM will break something, even adding new opcodes” might technically be true if your definition of “something” is so wide that includes contrived examples of EVM contracts (e.g. a contract that, rather than using the designated invalid opcode 0xfe, uses some random unassigned opcode for the same effect, and would break if in the future that opcode is assigned some functionality and becomes valid). But there is a major downside to such a strict interpretation of backwards-compatibility, and using account versioning to preserve strict backwards-compatibility.

The downside to account versioning for the case of reducing gas costs, is that if gas costs are reduced for the new protocol version and not the old, then all dapps will have to redeploy their contracts to benefit from the reduced gas costs. It would be nice to reduce the gas costs for the existing set of dapps and contracts, and not force all contracts to be redeployed in order to benefit. If we can propose a protocol upgrade in a way that doesn’t break any known use cases and deployed dapps, though it might break some contrived examples (which nobody actually uses on the mainnet), then users will be happy to adopt the upgrade.

So yeah, basically what you said.

@sorpaas

Regarding block gas limit – I think that may not be a huge issue. Miners can collectively raise the gas limit so that the average is on the previous level.

Note that the above discussion is about on-chain EVM. For wallets, compilers and ecosystem programs, every hard fork will break something for them, and most of them will need to do some updates. And if all they need to do is to re-calibrate the gas estimator, I don’t think that’s a big ask.

To be clear, EIP-2045 is a proposal to re-calibrate opcode gas costs (“gas estimators” are tools around the tx fee market between miners and tx senders; miner-accepted tx gas price is a different issue from protocol-defined opcode gas costs).

re: “collectively raise the gas limit so that the average is on the previous level”. This is addressed in the EIP:

One way to boost the transaction capacity is to raise the block gas limit. Unfortunately, raising the block gas limit would also increase the rate of state growth, unless the costs of state-expanding storage opcodes (SSTORE, CREATE, etc.) are simultaneously increased to the same proportion. […] Another way to boost the transaction capacity of a block is to reduce the gas cost of transactions. Reducing the gas costs of computational opcodes while keeping the cost of storage opcodes the same, is effectively equivalent to raising the block gas limit and simultaneously increasing the cost of storage opcodes.