EIP-2045: Particle gas costs

[cdetrio]

@sorpaas

@cdetrio

There may be other types of backwards compatibility issues and problems with reducing the cost of computational opcodes, but currently there are no known issues

The real point I’m saying is really about “there are no known issues”. Just half a year ago we thought both raising gas costs and reducing gas costs will not have any huge side effects at all. I’m not arguing that you cannot do it by reducing the gas costs. What I’m saying is that, you will need really in-depth backward compatibility assessment to carry this out. For a start, if we reduce the gas costs, then previously we may only be able to do one CALL under 2300 gas cost, but now it may be possible to do several, and will this break any assumptions of current contracts? The cost of doing those assessment might be more expensive compared with if we just raise the rest of the gas costs instead (or just put it under account versioning).

That’s a good point. We can use a script to do an analysis of all transactions, and what opcodes are used after a CALL to consume the 2300 gas stipend and trigger an OOG. Then we’ll have a list of opcodes whose gas costs may be an assumed invariant by some actively used contract.

An assessment around the 2300 gas stipend will not be too much work. Expanding it to an analysis of all contract interactions in general (all CALLs with any gas amount, not only CALLs with a 2300 gas stipend), or an analysis of all potential contract interactions (not just interactions we can observe in the transaction history) would be a lot of work.

@sorpaas

I also don’t quite get why raising gas costs will cause issues. We have done it many times in the past just fine. And please note that here we’re talking about protocol-level EVM changes. “Miners/wallets/exchanges need to adjust” is, in my opinion, an inconvenience, rather than an issue.

The main opcode where increasing the gas cost may cause issues is SSTORE. There is EIP-1884 to raise the cost of SLOAD (see EthMagi thread here), which I guess is less of an issue because at 200 gas (or even 800 gas) SLOAD might not be the dominant gas expense. On the other hand, SSTORE at 5000 or 20000 gas tends to dominate. It is already the gas bottleneck so dapps and certain use cases are more sensitive to change in the absolute gas cost (but hopefully not overly sensitive to change in the relative cost).

The change in cost we need is drastic (again, potentially 20x or more). Past times opcode gas costs have been raised:

• EIP-150
  • Increase the gas cost of EXTCODESIZE to 700 (from 20).
  • Increase the base gas cost of EXTCODECOPY to 700 (from 20).
  • Increase the gas cost of BALANCE to 400 (from 20).
  • Increase the gas cost of SLOAD to 200 (from 50).
  • Increase the gas cost of CALL, DELEGATECALL, CALLCODE to 700 (from 40).
  • Increase the gas cost of SELFDESTRUCT to 5000 (from 0).
  • If SELFDESTRUCT hits a newly created account, it triggers an additional gas cost of 25000 (similar to CALLs).
• EIP-160
  • increase the gas cost of EXP from 10 + 10 per byte in the exponent to 10 + 50 per byte in the exponent.

As you can see, the cost of SSTORE has never been changed before.

@sorpaas

@cdetrio

increase the rate of state growth

This should not be hugely relevant. If we want to deal with the issue of state growth, we’d better work on it directly – reducing block limit is the easiest way, state rent is the most sophisticated. Re-calibrating gas costs provides balances, but if current Ethereum usage needs this amount of state changes, then with or without EIP-2045, the state growth rate will not change a lot. This is the same as we don’t discourage people to use Ethereum to reduce state growth.

In discussions around 1.x we’ve learned that an important aspect around reducing state growth is that before state rent gets introduced on the mainnet, dapp devs need to have an alternative development model, e.g. a way to write “rent-compatible” contracts. If state rent is introduced but dapp devs have no way to write rent-compatible contracts, then we’d just be choking off usage and discouraging people from using Ethereum rather than fixing the problem.

One class of contracts that are rent-compatible are stateless contracts. Given the current gas cost imbalance between transaction data (overpriced) and storage (underpriced), it is not cost effective for devs to write stateless contracts. EIP-2028 will correct this imbalance (see EthMagi thread: EIP-2028: Transaction data gas cost reduction - #5 by elibensasson).

We want to prototype more stateless contracts and run benchmarks to estimate what, besides the cost of calldata, will be gas bottlenecks. But I suspect the cost of computation, e.g. verifying the merkle proofs passed in the calldata, is going to be a bottleneck. If the cost of computation is a bottleneck for stateless contracts, then reducing the cost to achieve a rebalance (or rebalance by increasing the absolute cost of storage and boosting the gas limit) is best step we can take to provide devs a way to deploy rent-compatible contracts.

With the right cost balance, devs will even be incentivized to deploy such rent-compatible, stateless contracts. If devs are deploying stateless contracts, we should see the rate of state growth start to slow down. Then state rent can be introduced with less disruption; it would further disincentivize stateful contracts with continual cost of storage (though after a rebalance, the one-time cost of storage will already be more expensive than passing in data through calldata). To ensure that state growth is completely flat or even negative, we could apply rent to existing contracts regardless of breakage (backward-breaking rent), rather than only to new contracts through account versioning (forward-compatible rent). But we could see state growth flatten out even without rent, or only with forward-compatible rent.

@sorpaas

From an emotional perspective, reduce gas costs while keep state change gas costs the same will make developers think the EVM is more efficient, so people may actually care less about performance. In the contrary, increase gas costs will have the possibility to make developers treat efficiency more carefully, and encourage better optimization, thus reduces unnecessary processing/state writes.

Applications that care less about performance will be slower and more costly than apps from developers who put in extra effort to optimize them. We see this in all software (not just Ethereum contracts).

At first I thought “we’re boosting the gas limit! (but also raising the price of storage)” had better marketing appeal than “we’re keeping the gas limit the same (but reducing the price of computation)”. But on second thought, “cheap gas for everyone! (for computation)” sounds better than “there’s a lot more gas now! (for computation)” imo.