I have concerns regarding preventing all external calls from being able specify less than 63/64 of the overarching transaction’s gas. EOF1 removes CALL, so the new EXTCALL is the only option available, but with regressed functionality.
I think there are many important use cases where giving the developer control of the gas available to an individual EXTCALL is important to avoid certain attack vectors. Examples include:
- executing arbitrary instructions on behalf of multiple users in a single transaction, e.g. account abstraction ERC-4337. The EIP defines a User Operation parameter
callGasLimit, which the reference implementation in the EIP enforces on each call: account-abstraction/contracts/core/EntryPoint.sol at 04ee30e3130dc1145ad7032318cf841909a8bc71 · eth-infinitism/account-abstraction · GitHub- without enforcing on each call, there is likely an attack vector opened where a tx can use more gas than estimated when actually executed, and the following logic in ERC-4337 becomes invalid: “If the call reverted, the bundler MUST use the trace result to find the entity that reverted the call. This is the last entity that is CALL’ed by the EntryPoint prior to the revert.”
- while not a preferred pattern, the widely used “safeSendETH” pattern, where a
GAS_STIPEND_NO_GRIEFis tried before falling back to an expensiveSENDALL, becomes impossible.- see popular implementation in solady repo here: solady/src/utils/SafeTransferLib.sol at main · Vectorized/solady · GitHub
I think the reasons above are enough to consider updating revamped call instructions to include a configurable gas limit. Curious if I’m missing anything though!