Hi,
While I definitely think ethereum CALL opcodes and gas behavior could be improved, I am not sure karma or the counter proposals brought here really bring much value.
From my understanding the idea behind karma is just to allows contract to continue using opcode pricing assumption (that is in gas, not in karma) in their code.
While this might sounds good in theory, I am not sure we should actually care about contract that have hard-coded gas assumption in their code.
If we talk about
“moving toward a more long-term sustainable model”
then we can simply stop hardcoding gas opcode pricing assumption and I think the message is already clear by now.
What would be interesting to know though is why the authors of such contract decided to hardcode such assumption and if it was because of certain lack of features in the EVM that we could then fulfil.
Regarding meta transaction, while the griefing attack is a possible scenario that metatx relayer need to consider, they are normally able to compute the outcome before submitting. It is indeed true that they still run the risk of state change between the time they submit the tx and the time it get mined, but then this is not unique to having not enough gas : the metatx user could have submitted the same tx to another relayer, user could have removed all its fund from the relay repayment mechanism,.etc…
In the metatx case, the gas limit specified as part of the inner call has actually a more important role : protecting the meta tx signer that its meta-tx is executed with the exact amount specified by its signed message. In other word, the gas limit act here as a lower bound. Else the relayer could maliciously make the inner call fails while getting paid as a result (due to 63/64 rule).
As EIP-1930 points out, such “strict gas semantic for call” is not possible to do it today without relying on tricks (relying on the 63/64 rules) or specific opcode pricing (by computing the amount of gas required to perform the call). See details in EIP-1930.
None of the proposals here would help.
In regard to the scenario where the upper bound is useful, they are usually circumvented by the “favor pull over push transfers” approach. The idea behind it is already that we should not trust the recipient. And that’s why I think the strict call semantic advocated in 1930 might be all we need: contract either give 63/64 or give a specific amount (in which case, if that amount is not available it fails). The latter might be useful only for meta-tx in which case a potential improvement could be to support meta-tx at the native level, so we could have one simple rule : every call gives 63/64 (though I would advise against making any assumption on that particular value being forever the same)
On the subject though, gas and call opcodes have other issues. I describe some of them in my blog here : https://ronan.eth.link/blog/ethereum-gas-dangers/ .
For example, it would be useful if a contract could know whether an inner call failed because of a lack of gas (instead of another type of failure) so it could revert the whole tx knowinggly.
This would not allow “push transfer” to be safe but this could ensure that a inner call is not interpreted wrongly as a genuine failure when it actually did not receive enough gas.