Hey frangio,
On this post was wondering why 4 SLOAD operations are given for the ReentrancyGuard Modifier? I would have thought 1 SLOAD as it checks if the number for comparison, then makes 2 state changes in the same transaction, 2 SSTORES.
The contract has changed since then. Your numbers are correct. 1 SLOAD + 2 SSTORES. All to the same slot. The last SSTORE restores the original value.
Ah so writing to a state variable is only an SSTORE, it doesn’t need an SLOAD? Also are you able to figure the fascists for this? I did testing on remix locally and got a rough difference of 2400 gas.
Figure what?
Ah, I meant the gas costs. Also when changing state to the variable, i.e. status = 1, does this concur an SSTORE only? Or does it take both SLOAD and SSTORE and when we write to status, that incurs a read/SLOAD operation?
status = 1 is only an SLOAD. But the value is read before for the require statement.
The cost breakdown will be:
- Warm up storage slot: 2000
- SLOAD: 100
- SSTORE: 2900
- SSTORE: 100, refunds 2800
So roughly it will be 2300 = 2000 + 100 + 2900 + 100 - 2800. However, the refund is capped at 20% of the total cost of a transaction, so -2800 may not fully realize and the net cost may be higher.
Do you mind if I make this a public post?
1 Like
Hi there,
Do you mean _status = 1 is an SSTORE?
require(_status != _ENTERED, "ReentrancyGuard: reentrant call"); -> SLOAD as _status is read.
_status = _ENTERED; -> SSTORE
_status = _NOT_ENTERED; -> SSTORE
This is the workflow I had in mind?
My bad, yes I meant that _status = 1 is an SSTORE.
1 Like
Cool thanks for that, feel free to share!