Automatically merged updates to draft EIP(s) 1930 (#2076)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-1930.md

@@ -52,6 +52,23 @@ if !callCost.IsUint64() || gas < callCost.Uint64() {
 }
 ```
 
+Since checks on gas break current implementation of `eth_estimateGas`, the opcodes need to also use the mechanism described in [EIP-2075](https://github.com/ethereum/EIPs/pull/2075) to ensure `eth_estimateGas` return a value that is sufficient for the transaction to succeed. It must thus set `minimalGas` to equal the max of the current value of `minimalGas` and the sum of the gas spent so far added to the gas required.
+
+More precisely, as described in EIP-2075:
+
+Let specify `minimalGas` as a new variable that the EVM need to keep track for the purpose of `eth_estimateGas`. At the start of a tx, it is set to zero.
+
+At the end of an `eth_estimateGas` call, the gas spent is compared to `minimalGas`. The bigger value of the two is returned as "estimate". It does not have any other role in the context of a transaction call, its only purpose is to fix the current behavior of `eth_estimateGas` so that call to the opcodes describe here return a useful estimate
+
+If there is enough gas, the gas amount specified will be added to the gas spent up to that point. If that amount is bigger than minimalGas it replaces it. In other words:
+
+```minimalGas = max(minimalGas, X + <gas spent so far including the gas used for the opcode>)```
+where X is the value passed to REQUIRE_GAS
+
+As mentioned the result of an `eth_estimateGas` is now
+
+```max(<gas used>, minimalGas)```
+
 ### Rationale
 
 Currently the gas specified as part of these opcodes is simply a maximum value. And due to the behavior of [EIP-150](http://eips.ethereum.org/EIPS/eip-150) it is possible for an external call to be given less gas than intended (less than the gas specified as part of the CALL) while the rest of the current call is given enough to continue and succeed. Indeed since with EIP-150, the external call is given at max  ```G - Math.floor(G/64)``` where G is the gasleft() at the point of the CALL, the rest of the current call is given ```Math.floor(G/64)``` which can be plenty enough for the transaction to succeed. For example, when G = 6,400,000 the rest of the transaction will be given 100,000 gas plenty enough in many case to succeed.