Discussion topic for
Reading the EIP, it’s unclear how “failure” of a call is defined. I assume “failure” is when the call can’t be initiated due to the contract’s balance < value or there being insufficient remaining gas? Are there any other constellations that would constitute a “failure” pushing the status code 2 onto the stack? An exceptional revert in the call context would still be considered a “revert” and not a “failure”, right?
revert is only returned if the callee uses the REVERT instruction. Should clarify it.
Historical context: these reworked CALL instructions were discussed starting late December when certain unobservability properties were required from EOF. The basic specification was discussed in January and until now kept in the “EOF mega spec”:
Creating the EIP is the next step, especially as it is not strictly dependant on EOF.
Note: Unlike
CALLthere is no extra charge for value bearing calls.
What is the justification for this?
Currently the cheapest way to change a value in a MPT is by modifying a storage key. This costs 5000 gas, leading to a theoretical limit 6000 MPT writes per block under current gas limits. Under this EIP, using the CALL opcode you can modify the balance of an account for only 2600 gas, raising the theoretical limit to 11538 MPT writes per block.
MPT writes are likely to be expensive. Each MPT write incurs multiple database writes (due to a trie node updates) compared to a singe database read for an MPT read. Charging the same for a read and a write seems questionable.
I agree with @Philogy that non-malicious code overpays for value carrying calls in practice, but I’m concerned this might be DOS vector.
So the “revert state” does not include e.g. INVALID (0xfe) and exceptional reverts due to e.g. missing jumpdest, insufficient stack args, out-of-bounds returndatacopy?
Correct, all these cases result with status code 2 on stack.
1 Like