A simple Ethereum proposal
This is a simple Ethereum proposal to fix a major problem that has plagued the smart contract ecosystem. When the Ethereum protocol requires an increase or decrease to the gas cost of various operations, this can in-turn provably break some smart contracts or even provably make them open to attack. A fixed gas limit for contract calls is typically used to eliminate the risk of reentrancy attacks. The amount of gas specified for this purpose is usually 2300. This is enough gas that a few things can be done, but some things can not be done, namely storing any data, ie, using the SSTORE instruction. I've proposed solutions before to this problem, but they had quite a few more features and thus complexity. Instead, I propose something considerably more simple, something fitting into a single paragraph.
Proposal
Add a new opcode called CALLWITHSCHEDULE. This operates in the exact same way as a standard CALL opcode, but takes an additional argument "use gas schedule at block". With this, you now pass in an additional argument of which gas cost schedule to use, by using the gas schedule which was active at a particular block height. The actual operation of this would track 2 gas usage counters during the execution of the called contract. One for "retro gas" which is computed using the old schedule and one for "actual gas" which is computed using the current gas schedule of the blockchain. The gas limit specified with CALLWITHSCHEDULE would be directly tied to "retro gas". This means that if the contract's "retro gas" counter hits the gas limit, then the contract call terminates with an out of gas error. The "actual gas" counter is tied to the overall transaction's gas limit and a separate actual gas limit can not be specified otherwise. If the actual gas consumed exceeds the transaction's gas limit, then the entire chain of execution would terminate with an out of gas error.
This prevents contract breakage by effectively presenting a “fixed” gas cost schedule, while still charging the appropriate amount of actual gas corresponding to blockchain resources, etc.
Scenarios are covered below.
Ethereum decreases cost of SSTORE (store data into storage)
This could allow for smart contracts to store data which previously did not have enough gas to. By using CALLWITHSCHEDULE it is possible to ensure that called contracts still abide by the old gas schedule and thus will never have enough gas to store data. However, the actual execution will cost less gas due to these reduced costs, thus allowing users to have the benefits of reduced costs, while not breaking any assumptions about gas costs within the logic of smart contracts.
Actual reference: https://blog.ethereum.org/2019/01/15/security-alert-ethereum-constantinople-postponement/
Ethereum increases cost of SLOAD (load data from storage)
This can break some smart contracts which rely on a series of dependent smart contracts. For example, a fixed 2300 gas limit was used in a contract to ensure no recursion was exploitable, however, the called contract needs to use SLOAD to load some kind of data. By increasing the cost of SLOAD, this dependent contract can no longer be executed with the 2300 gas limit. By using CALLWITHSCHEDULE, the 2300 gas limit will still allow using SLOAD at the old gas price, and thus the contract will remain operating properly. The actual gas cost of executing the smart contract would increase, but this would not affect any smart contract execution. Some user interface code may need updated to use a higher gas limit for transactions concerning that smart contract, but this of course is outside of the blockchain and easy to do.
Actual reference: https://cointelegraph.com/news/aragon-expects-ethereums-istanbul-hard-fork-to-break-680-smart-contracts
Side effects
The only smart contract visible effect this would have is that the amount of actual gas used by a CALLWITHSCHEDULE may not match the gas limit specified to the call. There is no additional complexity to deal with in terms of nested calls either. In all cases there is "retro gas" determined by the current call context, and a consistent view of "actual gas".
