status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-23 12:18:16 +00:00
Code Issues Projects Releases Wiki Activity

EIP-3529: Rename NEW_MAX_REFUND_QUOTIENT to MAX_REFUND_QUOTIENT (#3538)

Browse Source 
* EIP-3529: Rename NEW_MAX_REFUND_QUOTIENT to MAX_REFUND_QUOTIENT

* EIP-2529: Remove reference to Yellow Paper
This commit is contained in:
Paweł Bylica 2021-05-13 23:47:51 +02:00 committed by GitHub
parent 168245a87a
commit 4c66867229
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
EIPS/eip-3529.md
View File

@ -28,13 +28,16 @@ Gas refunds for SSTORE and SELFDESTRUCT were originally introduced to motivate a
| Constant | Value |
| - | - |
| `FORK_BLOCK` | TBD |
| `NEW_MAX_REFUND_QUOTIENT` | 5 |
| `MAX_REFUND_QUOTIENT` | 5 |
For blocks where `block.number >= FORK_BLOCK`, the following changes apply.
1. Remove the `SELFDESTRUCT` refund.
2. Replace `SSTORE_CLEARS_SCHEDULE` (as defined in [EIP-2200](./eip-2200.md)) with `SSTORE_RESET_GAS + ACCESS_LIST_STORAGE_KEY_COST` (4,800 gas as of [EIP-2929](./eip-2929.md) + [EIP-2930](./eip-2930.md))
3. Reduce the max gas refunded after a transaction to `gas_used // NEW_MAX_REFUND_QUOTIENT`
3. Reduce the max gas refunded after a transaction to `gas_used // MAX_REFUND_QUOTIENT`
Remark: Previously _max gas refunded_ was defined as `gas_used // 2`. Here we
name the constant `2` as `MAX_REFUND_QUOTIENT` and change its value to `5`.
## Rationale
@ -63,7 +66,7 @@ Gas tokens will become valueless. DeFi arbitrage bots, which today frequently us
However, fully preserving refunds in the `new = original = 0 != current` case, and keeping _some_ refund in the other `nonzero -> zero` cases, ensures that a few key use cases that receive (and deserve) favorable gas cost treatment continue to do so. For example, `zero -> nonzero -> zero` storage set patterns continue to cost only ~100 gas. Two important examples of such patterns include:
* Anti-reentrancy locks (typically flipped from 0 to 1 right before a child call begins, and then flipped back to 0 when the child call ends)
* Anti-reentrancy locks (typically flipped from 0 to 1 right before a child call begins, and then flipped back to 0 when the child call ends)
* ERC20 approve-and-send (the "approved value" goes from zero to nonzero when the token transfer is approved, and then back to zero when the token transfer processes)
### Effect on storage clearing incentives
@ -83,7 +86,7 @@ The capping of refunds to 1/5 of gas expended means that this refund can only be
Note, there is a difference between 'hot' and 'cold' slots. This table shows the values as of [EIP-2929](./eip-2929.md) assuming that all touched storage slots were already 'hot' (the difference being a one-time cost of `2100` gas).
| Code | Used Gas | Refund | Original | 1st | 2nd | 3rd | Effective gas (after refund)
| -- | -- | -- | -- | -- | -- | -- | -- |
| -- | -- | -- | -- | -- | -- | -- | -- |
| `0x60006000556000600055` | 212 | 0| 0 | 0 | 0 | | 212 |
| `0x60006000556001600055` | 20112 | 0| 0 | 0 | 1 | | 20112 |
| `0x60016000556000600055` | 20112 | 19900| 0 | 1 | 0 | | 212 |
@ -107,7 +110,7 @@ Note, there is a difference between 'hot' and 'cold' slots. This table shows the
If refunds were to be partially removed, by changing SSTORE_CLEARS_SCHEDULE from 15000 to 4800 (and removing selfdestruct refund) this would be the comparative table.
| Code | Used Gas | Refund | Original | 1st | 2nd | 3rd | Effective gas (after refund)
| -- | -- | -- | -- | -- | -- | -- | -- |
| -- | -- | -- | -- | -- | -- | -- | -- |
| `0x60006000556000600055` | 212 | 0| 0 | 0 | 0 | | 212 |
| `0x60006000556001600055` | 20112 | 0| 0 | 0 | 1 | | 20112 |
| `0x60016000556000600055` | 20112 | 19900| 0 | 1 | 0 | | 212 |