Development Update 3 ~ [11/11/2021]

# Development Update 3 ~ [11/11/2021] The following document is a third development update for the chosen project “Research removal of gas stipend for `CALL` opcodes”. This update explores the two possibilities for removing the gas stipend to determine the ideal approach by considering the complexity of the implementation and whether there any backward compatibility issues. ## Brief Recap The previous development update explored the impact of removing the gas stipend on transferring Ether methods such as `.send()`, `.transfer()`, and `.call()`. It was found that having 0 gas stipend causes transactions to fail, whereas if all the remaining gas is forwarded, the transactions happen successfully. ## Possibility One - 0 Gas Stipend If the stipend's value is replaced with 0, then all ETH transfers need to issue a standardized log in an automated manner. The function that executes the `CALL` opcode operation will need to be modified to include logic that prevents execution from taking place after the balances are updated. It will ensure that the EVM does not throw the `out of gas` error. After validating and applying the state changes, the EVM needs to call a function that emits a log: ``` //(code taken from the CALL function in evm.go) evm.Context.Transfer(evm.StateDB, caller.Address(), addr, value) // Here ==> ``` This type of log would be different from the traditional smart contract logs as it will be issued seperately by the protocol. Below are the cases when the protocol log will be emitted: * transfers made using `.send()`, `transer()`, and `call`, * when `SELFDESTRUCT` is called. There will be complexities involved in the implementation to cover all the cases for ETH transfers and `SELFDESTRUCT`s. Therefore, extensive testing will be required to prevent bugs or functionalities from breaking. Since the log will be emitted separately by the protocol, contracts will not require any changes to their source code. Only the front-end of DAPPs will require modifications to listen for emitted events, making it a manageable change for application developers to adjust. ## Possibility Two - Infinite Gas Stipend If all the remaining gas is forwarded for computation, it leaves contracts vulnerable to reentrancy attacks. It will affect those that do not follow the "Checks-Effects-Interactions" pattern. There are two reasons that some contracts may not follow this: * Having assumptions that gas costs will remain constant, hence, relying on the gas stipend to avoid reentrancy attacks. * Lack of awareness about smart contract security. All the remaining gas can be forwarded by allowing calls made using `.send()` and `.transfer()` behave similarly to `.call()`. A working implementation has been described in the previous development update, however, there may be other better methods to enable such behavior. It is important to mention that the described implementation only enabled this behavior for the `CALL` opcode. To account for other opcodes such as `CALLCODE` and `DELEGATECALL`, the same changes will need to be applied to the associated functions, including `gasCallCode` and `gasDelegateCall`, for calculating the gas costs. This ensures that `.send()` and `.transfer()` works in all cases. Compared to the first possibility, this change will be equally invasive as it involves modifying multiple functions. As mentioned earlier, testing will be needed here to avoid breaking existing contracts. ## Conclusion The advantage of having infinite gas is it provides greater flexibility for contract developers to create customized logs. On the flip side, it makes contracts susceptible to reentrancy attacks if not properly designed. One possible mitigation could be to increase awareness to incorporate the “Checks-Effects-Interactions” pattern when sending value between contracts. Although, the Solidity documentation already describes this as a [common pattern](https://docs.soliditylang.org/en/v0.5.3/common-patterns.html#withdrawal-pattern). To determine the ideal approach for removing the gas stipend, feedback from the core developers and community would need need to be accounted for. ## Next Steps The next step is to share the findings thus far with the core developers and get feedback. This feedback will be documented in the upcoming development update. ## References 1. https://gitter.im/ethereum/AllCoreDevs?at=5d667f5ee403470ab6ef89ce 2. https://contract-library.com/?page=1&warningType=Accessible+selfdestruct ###### tags: `CDAP`