Actually, that last bit isn't true - current gas estimators do a binary search until the execution succeeds.
Also, we would need to have this not apply to simple ETH transfers I'm guessing, since they currently use exactly 21,000 gas (and there is a lot of tooling that depends on this). I doubt this is a problem since I'm guessing this logic would be part of EVM execution, not simple value transfers.
I would say this - it is likely that we will be changing the cost of SSTORE again soon - to manage the state size growth. I do not exactly know how. So I would not rush re-introducing this EIP unless it is really critical for something. Like REVERT in Constantinople, it makes the gas pricing fairer, but it does accelerate the state growth, unfortunately (because by saving gas on SSTORE, more state expansions can be done in one block)
@MicahZoltu Sort of
Does STATICALL preserve log outputs, though?
@Arachnid Eh, I'm not convinced it is an invariant. It is a common "best practice", but it is well known that gas prices can change and people (me) have been trying to warn others about that fact for some time (since those people started recommending stipends as a best practice).
@axic With reverts, the invariant checks became much more economical
For me, this is the best way to transfer ETH without the reentrancy danger: https://www.reddit.com/r/ethdev/comments/6ekz2j/a_secure_way_to_make_a_send_in_ethereum/
Any attempts to make state-changing operations inside an execution instance with STATIC set to true will instead throw an exception. These operations include CREATE, CREATE2, LOG0, LOG1, LOG2, LOG3, LOG4, SSTORE, and SELFDESTRUCT. They also include CALL with a non-zero value. As an exception, CALLCODE is not considered state-changing, even with a non-zero value.
LOG* is the major reason token contracts would have code in the “fallback” function
Make
.transfer be KINDA_STATIC_CALL, which allows LOG*. :wink:
I honestly think the best long-term solution here would be to allow contracts to specify an EVM-version or set of EVM-flags. This way you could always depend on your contract working a specific way, but we could allow new contracts to have different behavior (e.g. the benefit of lower gas costs). The problem is that contract-to-contract calls would become difficult or impossible to analyze. It would also make it clear that contracts cannot depend on certain aspects of remote contracts, such as gas limits on unknown code.
At this point I don't think we can, or should, remove the invariant. And even if we come up with another solution for the net gas metering change, I think we should consider adding the
gas > 2300 restriction to clients anyway. Presently we have an invariant that's not explicitly enforced anywhere. We should add a guard that explicitly ensures the invariant is preserved.
@MicahZoltu No, a
CALL with value > 0 and gas < 2300 will automatically provide 2300 gas instead.
Also, regarding the intent of EIP-1283 (which was previously EIP-1087), it was mainly to enable inter-frame communication within the same transaction. I wrote an alternative EIP, which has the same intent, but does not have the issue of EIP-1283 (1087): https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1153.md. Of course, I did not know about the the problem with EIP-1283/1087. What I am saying - if the demand for this change is really high, we can still do it, and even cheaper