Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
EIP-1283: Net gas metering for SSTORE without dirty maps #1283
Abstract: This EIP proposes net gas metering changes for SSTORE opcode, as an
So, here's a state transition diagram as best I can establish. This diagram ignores no-op writes, which are trivial. The graph has two parts: one for where the original value is 0, and one for where the original value is nonzero.
I agree that there doesn't seem to be a way to "pump" the refund counter. There are a couple of situations where a series of writes can result in moving gas in 5k chunks from gas meter to refund counter still, however - such as when the value is nonzero to start, and it's repeatedly set to another value and then back to its original value.
I think a table version of this would probably be useful, too. Each of the two graphs can likely be summarised in a table fairly intuitively.
Here's the graphviz source for the diagram:
Thanks so much! I added the diagram and the table version to the spec Explanation section (if that's okay for you)!
Yes indeed. That's the case for current scheme as well (repeatedly call SSTORE to set a slot from 0 to non-zero, and then back to zero, each cycle would cost 25k and gets 15k refund). I can't think of a way to use the methodology in this EIP to fix that, though.
referenced this pull request
Aug 9, 2018
Reentrancy attack returns: https://www.coindesk.com/ethereums-constantinople-upgrade-faces-delay-due-to-security-vulnerability
Any ideas on mitigating?