Remediations for EIP-1283 reentrancy bug

[chfast]

For reference, there is a new proposal coming from @AlexeyAkhunov which I’m now promoting which is something in between option 5 and 3.

Already proposed here as number 6.

@k06a

6. Cost could be 2300 gas and 2100 gas refund instead of just cost 200 gas

chfast

I did quick analysis of @AlexeyAkhunov alternative proposal to charge min 2300 for SSTORE but add 1500 refund more. None of the EIPs list use cases for it, so I took a simple lock/mutex which is

SLOAD  # check the lock status
SSTORE 0 -> 1 # lock
... # do something, e.g. make a call
SSTORE 1 -> 0 # unlock

@AlexeyAkhunov’s proposal (let’s call it variant 2) looks pretty solid because SSTORE / SLOAD will cost 800 now (I still have 200 in my mind).
In simplest operation of a CALL costing 700 the variant 2 is less than 7% more expensive in the end.
For the case where in variant 1 we get full refund and the protected operation cost ~17k the difference is less than 4%.
In the final case where variant 2 also get full refund the protected operation cost ~20k (and the end costs are the same obviously).

EIP-2200 analysis - Google Sheets

I admit I might have missed some responses in this thread, but critic found for 3/5 like options are:

@tkstanczak

3,4,5 - all seriously decrease net gas metering impact

I don’t believe the 4% gas cost increase in worst case matches with “seriously”.

@jochem-brouwer

I don’t like this one because now you have to forward much more gas than which is actually used.

I can try to add information how much gas in advance you need to provide in transaction to the spreadsheet. But so far “much more” is not very precise figure.

–
Also, would be nice to put #6 and #7 in the top comment.

[tkstanczak]

What I meant by ‘seriously decreasing the impact’ is that the final gas cost is less important for scaling here than the gas limit of a transaction. If I want to execute 100 SSTOREs out of which 99 are just updating the single storage address I will need at least 21000 + 100 * 5000 gas now (gas limit of 521000), with the EIP 1283 it was meant to be 21000 + 5000 + 99 * 200 (gas limit of 45800). With the 2300 + 2100 refund the gas limit required would be 21000 + 5000 + 99 * 2300 (253700). Maybe we can test the transaction gas limit against the gas used - refund?

[chfast]

@tkstanczak

Maybe we can test the transaction gas limit against the gas used - refund?

We cannot because this test is done before the transaction is executed.

[tkstanczak]

I meant testing the remaining gas in the transaction - transaction limit vs currently used gas.

So if we are executing and having 100k gas used and 70k refund then even if tx gas limit is 51k it would still allow to continue execution.

[chfast]

That would be quite excessive change (considering the scope of this EIP) with a lot of security considerations needed.

[holiman]

@tkstanczak

With the 2300 + 2100 refund the gas limit required would be 21000 + 5000 + 99 * 2300 (253700). Maybe we can test the transaction gas limit against the gas used - refund?

See EIP-2200: Structured Definitions for Net Gas Metering by sorpaas · Pull Request #2200 · ethereum/EIPs · GitHub

If the 2300 gas is to guard against reentrancy following a transfer, then 1600 will also suffice as the underlying CALL will cost at least 700.

So in actual fact, we could do 21000 + 5000 + 99 * 1600 = 184400, which is at least better than 253700