status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 1283 

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Ayrat Badykov 2018-09-18 12:19:22 +03:00 committed by EIP Automerge Bot
parent 7b3104cb47
commit b076285459
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
EIPS/eip-1283.md
View File

@ -13,15 +13,15 @@ created: 2018-08-01
This EIP proposes net gas metering changes for SSTORE opcode, as an
alternative for EIP-1087. It tries to be friendlier to implementations
that uses different opetimiazation strategies for storage change
that use different optimization strategies for storage change
caches.
## Motivation
EIP-1087 proposes a way to adjust gas metering for SSTORE opcode,
enabling new usages on this opcodes where it is previously too
enabling new usages on these opcodes where it is previously too
expensive. However, EIP-1087 requires keeping a dirty map for storage
changes, and implictly makes the assumption that a transaction's
changes, and implicitly makes the assumption that a transaction's
storage changes are committed to the storage trie at the end of a
transaction. This works well for some implementations, but not for
others. After EIP-658, an efficient storage cache implementation would
@ -29,11 +29,11 @@ probably use an in-memory trie (without RLP encoding/decoding) or
other immutable data structures to keep track of storage changes, and
only commit changes at the end of a block. For them, it is possible to
know a storage's original value and current value, but it is not
possible to iterate over all storage changes without incur additional
possible to iterate over all storage changes without incurring additional
memory or processing costs.
This EIP proposes an alternative way for gas metering on SSTORE, using
information that is more universially available to most
information that is more universally available to most
implementations:
* *Storage slot's original value*.
@ -43,7 +43,7 @@ implementations:
For the specification provided here:
* We don't suffer from the optimization limitation of EIP-1087, and it
never costs more gas compared with current scheme.
never costs more gas compared with the current scheme.
* It covers all usages for a transient storage. Clients that are easy
to implement EIP-1087 will also be easy to implement this
specification. Some other clients might require a little bit extra
@ -100,7 +100,7 @@ consumed.
## Explanation
The new gas cost scheme for SSTORE is divided to three different
The new gas cost scheme for SSTORE is divided into three different
types:
* **No-op**: the virtual machine does not need to do anything. This is
@ -143,7 +143,7 @@ state because that is trivial:
![State Transition](../assets/eip-1283/state.png)
Below are table version of the above diagram. Vertical shows the *new
Below is table version of the above diagram. Vertical shows the *new
value* being set, and horizontal shows the state of *original value*
and *current value*.
@ -187,7 +187,7 @@ Examine examples provided in EIP-1087's Motivation:
## Backwards Compatibility
This EIP requires a hard fork to implement. No gas cost increase is
anticipated, and many contract will see gas reduction.
anticipated, and many contracts will see gas reduction.
## Test Cases