EIP-5022: Increase price of SSTORE from zero to non-zero to 40k gas #5022
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
greenlucid
changed the title
greenlucid
changed the title
|
@greenlucid - please close this PR and then immediately re-open it |
All tests passed; auto-merging...(pass) eip-5022.md
|
MicahZoltu
approved these changes
May 6, 2022
|
|
||
| ### Abstract | ||
|
|
||
| Increase the price of the SSTORE opcode from `20_000` gas to `40_000` gas when the original slot is zero and the resultant slot is non-zero. |
There was a problem hiding this comment.
Suggested change
| Increase the price of the SSTORE opcode from `20_000` gas to `40_000` gas when the original slot is zero and the resultant slot is non-zero. | |
| Increase the price of the SSTORE (0x55) opcode from `20_000` gas to `40_000` gas when the original slot is zero and the resultant slot is non-zero. |
Opcodes should be referenced at least the first time in the document in the form:
REVERT (0xfe)
Comment on lines
+23
to
+54
| ## Rationale | ||
|
|
||
| ### Why not also raise the cost of non-zero to non-zero? | ||
|
|
||
| Rewriting storage does not affect state growth, which is the main issue this EIP is addressing. Rewriting storage may also be underpriced. | ||
| Increasing the price of state growth will, at least, incentivize developers to reuse storage instead. | ||
|
|
||
| ### Why not also increase the gas refund from setting non-zero to zero? | ||
|
|
||
| More discussion is needed on this. | ||
|
|
||
| ### Why not a better state solution? | ||
|
|
||
| Whereas solutions like state rent, or state expiry have been researched for a long time, they will not be ready on the short to medium term. So, it is desirable to patch pricing for the short term. Opcode repricing has been done before, so it should not impose a large development time investment for clients. | ||
|
|
||
| ### Why was that specific amount chosen? | ||
|
|
||
| The current pricing was made off a naive approach of benchmarking opcodes in a laptop. Not only it did not consider the long term problem of having the same price for a resource that costs more over time, the benchmark itself was wrong. This price is closer to what the naive original benchmark should have been. It could go higher, but that may be too disruptive. | ||
|
|
||
| ### Is this too distruptive? | ||
|
|
||
| This change will severely impact the gas cost of many applications. The network does not have to subsidize state growth at the expense of more expensive regular transactions, so even if it is too disruptive, it will increase the health of the network. | ||
|
|
||
| ### Specification | ||
|
|
||
| | Constant | Value | | ||
| | - | - | | ||
| | `FORK_BLOCK` | TBD | | ||
| | `NEW_STORAGE_PRICE` | `40_000` | ||
|
|
||
| For blocks where `block.number >= FORK_BLOCK`, a new gas schedule applies. Make `SSTORE_SET_GAS`, the price when a slot is set from zero to non-zero, equal `NEW_STORAGE_PRICE`. All other costs remain the same. | ||
|
|
There was a problem hiding this comment.
Specification should come before rationale.
Suggested change
| ## Rationale | |
| ### Why not also raise the cost of non-zero to non-zero? | |
| Rewriting storage does not affect state growth, which is the main issue this EIP is addressing. Rewriting storage may also be underpriced. | |
| Increasing the price of state growth will, at least, incentivize developers to reuse storage instead. | |
| ### Why not also increase the gas refund from setting non-zero to zero? | |
| More discussion is needed on this. | |
| ### Why not a better state solution? | |
| Whereas solutions like state rent, or state expiry have been researched for a long time, they will not be ready on the short to medium term. So, it is desirable to patch pricing for the short term. Opcode repricing has been done before, so it should not impose a large development time investment for clients. | |
| ### Why was that specific amount chosen? | |
| The current pricing was made off a naive approach of benchmarking opcodes in a laptop. Not only it did not consider the long term problem of having the same price for a resource that costs more over time, the benchmark itself was wrong. This price is closer to what the naive original benchmark should have been. It could go higher, but that may be too disruptive. | |
| ### Is this too distruptive? | |
| This change will severely impact the gas cost of many applications. The network does not have to subsidize state growth at the expense of more expensive regular transactions, so even if it is too disruptive, it will increase the health of the network. | |
| ### Specification | |
| | Constant | Value | | |
| | - | - | | |
| | `FORK_BLOCK` | TBD | | |
| | `NEW_STORAGE_PRICE` | `40_000` | |
| For blocks where `block.number >= FORK_BLOCK`, a new gas schedule applies. Make `SSTORE_SET_GAS`, the price when a slot is set from zero to non-zero, equal `NEW_STORAGE_PRICE`. All other costs remain the same. | |
| ## Specification | |
| | Constant | Value | | |
| | - | - | | |
| | `FORK_BLOCK` | TBD | | |
| | `NEW_STORAGE_PRICE` | `40_000` | |
| For blocks where `block.number >= FORK_BLOCK`, a new gas schedule applies. Make `SSTORE_SET_GAS`, the price when a slot is set from zero to non-zero, equal `NEW_STORAGE_PRICE`. All other costs remain the same. | |
| ## Rationale | |
| ### Why not also raise the cost of non-zero to non-zero? | |
| Rewriting storage does not affect state growth, which is the main issue this EIP is addressing. Rewriting storage may also be underpriced. | |
| Increasing the price of state growth will, at least, incentivize developers to reuse storage instead. | |
| ### Why not also increase the gas refund from setting non-zero to zero? | |
| More discussion is needed on this. | |
| ### Why not a better state solution? | |
| Whereas solutions like state rent, or state expiry have been researched for a long time, they will not be ready on the short to medium term. So, it is desirable to patch pricing for the short term. Opcode repricing has been done before, so it should not impose a large development time investment for clients. | |
| ### Why was that specific amount chosen? | |
| The current pricing was made off a naive approach of benchmarking opcodes in a laptop. Not only it did not consider the long term problem of having the same price for a resource that costs more over time, the benchmark itself was wrong. This price is closer to what the naive original benchmark should have been. It could go higher, but that may be too disruptive. | |
| ### Is this too distruptive? | |
| This change will severely impact the gas cost of many applications. The network does not have to subsidize state growth at the expense of more expensive regular transactions, so even if it is too disruptive, it will increase the health of the network. | |
|
|
||
| For blocks where `block.number >= FORK_BLOCK`, a new gas schedule applies. Make `SSTORE_SET_GAS`, the price when a slot is set from zero to non-zero, equal `NEW_STORAGE_PRICE`. All other costs remain the same. | ||
|
|
||
| ### Backwards compatibility |
There was a problem hiding this comment.
Suggested change
| ### Backwards compatibility | |
| ## Backwards Compatibility |
Comment on lines
+61
to
+64
| ## Implementation | ||
|
|
||
| https://github.com/ethereum/go-ethereum/pull/24725 | ||
|
|
There was a problem hiding this comment.
Implementation isn't a valid EIP section. There is a Reference Implementation section, but it should contain an inline implementation, not a link to an external one. Reference Implementation is optional, so if it doesn't make sense to include something inline, then it is best to just leave the section out.
Suggested change
| ## Implementation | |
| https://github.com/ethereum/go-ethereum/pull/24725 |
Comment on lines
+65
to
+67
| ## Security considerations | ||
|
|
||
| TODO |
There was a problem hiding this comment.
Copyright is required.
Suggested change
| ## Security considerations | |
| TODO | |
| ## Security Considerations | |
| TBD | |
| ## Copyright | |
| Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |
Comment on lines
+2
to
+9
| eip: 5022 | ||
| title: Increase price of SSTORE from zero to non-zero to 40k gas | ||
| author: Green (@greenlucid) | ||
| status: Draft | ||
| type: Standards Track | ||
| category: Core | ||
| created: 2022-04-20 | ||
| discussions-to: https://ethereum-magicians.org/t/eip-proposal-increase-cost-of-sstore-from-20k-to-x-when-creating-new-storage/7614 |
There was a problem hiding this comment.
Needs a description and discussions-to must come after the author.
Suggested change
| eip: 5022 | |
| title: Increase price of SSTORE from zero to non-zero to 40k gas | |
| author: Green (@greenlucid) | |
| status: Draft | |
| type: Standards Track | |
| category: Core | |
| created: 2022-04-20 | |
| discussions-to: https://ethereum-magicians.org/t/eip-proposal-increase-cost-of-sstore-from-20k-to-x-when-creating-new-storage/7614 | |
| eip: 5022 | |
| title: Increase price of SSTORE from zero to non-zero to 40k gas | |
| description: <required> | |
| author: Green (@greenlucid) | |
| discussions-to: https://ethereum-magicians.org/t/eip-proposal-increase-cost-of-sstore-from-20k-to-x-when-creating-new-storage/7614 | |
| status: Draft | |
| type: Standards Track | |
| category: Core | |
| created: 2022-04-20 |
MicahZoltu
suggested changes
May 6, 2022
PowerStream3604
pushed a commit
to PowerStream3604/EIPs
that referenced
this pull request
May 19, 2022
…thereum#5022) * init eip * add eip number * add implementation
nachomazzara
pushed a commit
to nachomazzara/EIPs
that referenced
this pull request
Jan 13, 2023
…thereum#5022) * init eip * add eip number * add implementation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.