Copy sections from EIP-1283 and EIP-1706 to EIP-2200

sorpaas · sorpaas · commit 01b66af08d05 · 2019-09-06T15:59:45.000+02:00
diff --git a/EIPS/eip-2200.md b/EIPS/eip-2200.md
@@ -1,6 +1,6 @@
 ---
 eip: 2200
-title: Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change
+title: Structured Definitions for Net Gas Metering
 author: Wei Tang (@sorpaas)
 discussions-to: https://github.com/sorpaas/EIPs/issues/1
 status: Draft
@@ -12,24 +12,54 @@ requires: 1283, 1706, 1884
 
 ## Simple Summary
 
-A repricing effort for several trie-size-dependent opcodes are being
-carried out. This EIP also reprices net-metered SSTORE opcode.
+This is an EIP that implements net gas metering. It's a combined
+version of EIP-1283 and EIP-1706, with a structured definition so as
+to make it interoperable with other gas changes such as EIP-1884.
 
 ## Abstract
 
-Change the intermediate write and no-op write of SSTORE to always have
-the same gas cost of SLOAD. Change the refund of resetting after
-setting for SSTORE to take consideration of gas cost of SLOAD.
+This EIP provides a structured definition of net gas metering changes
+for SSTORE opcode, enabling new usages for contract storage, and
+reducing excessive gas costs where it doesn’t match how most
+implementation works.
+
+This is a combination of EIP-1283 and EIP-1706.
 
 ## Motivation
 
-Net gas metering for SSTORE was priced according to SLOAD values. For
-consistency, when SLOAD is repriced, SSTORE should be as well.
+This EIP proposes a way for gas metering on SSTORE, using information
+that is more universally available to most implementations, and
+require as little change in implementation structures as possible.
+
+* Storage slot’s original value.
+* Storage slot’s current value.
+* Refund counter.
+
+Usages that benefits from this EIP’s gas reduction scheme includes:
+
+* Subsequent storage write operations within the same call frame. This
+  includes reentry locks, same-contract multi-send, etc.
+* Exchange storage information between sub call frame and parent call
+  frame, where this information does not need to be persistent outside
+  of a transaction. This includes sub-frame error codes and message
+  passing, etc.
+
+The original defintion of EIP-1283 created a danger of a new kind of
+reentrancy attacks on existing contracts as Solidity by default grants
+a "stipend" of 2300 gas to simple transfer calls. This danger is
+easily mitigated if SSTORE is not allowed in low gasleft state,
+without breaking the backward compatibility and the original intention
+of EIP-1283.
+
+This EIP also replaces the original EIP-1283 value definitions of gas
+by parameters, so that it's more structured, and easier to define
+changes in the future.
 
 ## Specification
 
 Define variables `SLOAD_GAS`, `SSTORE_SET_GAS`, `SSTORE_RESET_GAS` and
-`SSTORE_CLEARS_SCHEDULE`. The old and new values for those variables are:
+`SSTORE_CLEARS_SCHEDULE`. The old and new values for those variables
+are:
 
 * `SLOAD_GAS`: changed from `200` to `800`.
 * `SSTORE_SET_GAS`: `20000`, not changed.
@@ -39,7 +69,7 @@ Define variables `SLOAD_GAS`, `SSTORE_SET_GAS`, `SSTORE_RESET_GAS` and
 Change the definition of EIP-1283 using those variables. The new
 specification, combining EIP-1283 and EIP-1706, will look like
 below. The terms *original value*, *current value* and *new value* are
-defined in EIP-1283. 
+defined in EIP-1283.
 
 Replace SSTORE opcode gas cost calculation (including refunds) with
 the following logic:
@@ -68,29 +98,221 @@ the following logic:
         refund counter.
       * Otherwise, add `SSTORE_RESET_GAS - SLOAD_GAS` gas to refund
         counter.
-* If *gasleft* is less than or equal to 2300, fail the current call
-  frame with 'out of gas' exception.
+* If *gasleft* is less than or equal to gas stipend, fail the current
+  call frame with 'out of gas' exception.
 
-An implementation should also note EIP-1283's refund counter
-implementation details, in the *Specification* section.
+An implementation should also note that with the above definition, if
+the implementation uses call-frame refund counter, the counter can go
+negative. If the implementation uses transaction-wise refund counter,
+the counter always stays positive.
 
 ## Rationale
 
-The same as EIP-1283's rationale. If EIP-1884 is applied, then `SLOAD_GAS`
-related to SSTORE opcode will also need to be changed.
+This EIP mostly achieves what a transient storage tries to do
+(EIP-1087 and EIP-1153), but without the complexity of introducing the
+concept of "dirty maps", or an extra storage struct.
+
+* We don't suffer from the optimization limitation of
+  EIP-1087. EIP-1087 requires keeping a dirty map for storage 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 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
+  incurring additional memory or processing costs.
+* It 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
+  refactoring on this. Nonetheless, no extra memory or processing cost
+  is needed on runtime.
+
+Regarding SSTORE gas cost and refunds, see Appendix for proofs of
+properties that this EIP satisfies.
+
+* For *absolute gas used* (that is, actual *gas used* minus *refund*),
+  this EIP is equivalent to EIP-1087 for all cases.
+* For one particular case, where a storage slot is changed, reset to
+  its original value, and then changed again, EIP-1283 would move more
+  gases to refund counter compared with EIP-1087.
+
+Examine examples provided in EIP-1087's Motivation:
+
+* If a contract with empty storage sets slot 0 to 1, then back to 0,
+  it will be charged `20000 + 200 - 19800 = 400` gas.
+* A contract with empty storage that increments slot 0 5 times will be
+  charged `20000 + 5 * 200 = 21000` gas.
+* A balance transfer from account A to account B followed by a
+  transfer from B to C, with all accounts having nonzero starting and
+  ending balances, it will cost `5000 * 3 + 200 - 4800 = 10400` gas.
+
+In order to keep in place the implicit reentrancy protection of
+existing contracts, transactions should not be allowed to modify state
+if the remaining gas is lower then the gas stipend given to
+"transfer"/"send" in Solidity. These are other proposed remediations
+and objections to implementing them:
+
+* Drop EIP-1283 and abstain from modifying SSTORE cost
+  * EIP-1283 is an important update 
+  * It was accepted and implemented on test networks and in clients.
+* Add a new call context that permits LOG opcodes but not changes to state.
+  * Adds another call type beyond existing regular/staticcall
+* Raise the cost of SSTORE to dirty slots to >=2300 gas
+  * Makes net gas metering much less useful.
+* Reduce the gas stipend
+  * Makes the stipend almost useless.
+* Increase the cost of writes to dirty slots back to 5000 gas, but add
+  4800 gas to the refund counter
+  * Still doesn’t make the invariant explicit.
+  * Requires callers to supply more gas, just to have it refunded
+* Add contract metadata specifying per-contract EVM version, and only
+  apply SSTORE changes to contracts deployed with the new version.
 
 ## Backwards Compatibility
 
-This EIP has the same backward compatibility property of EIP-1283 and EIP-1706.
+This EIP requires a hard fork to implement. No gas cost increase is
+anticipated, and many contracts will see gas reduction.
+
+Performing SSTORE has never been possible with less than 5000 gas, so
+it does not introduce incompatibility to the Ethereum mainnet. Gas
+estimation should account for this requirement.
 
 ## Test Cases
 
-To be added.
+Below we provide 17 test cases. 15 of them covering consecutive two
+`SSTORE` operations are based on work [by
+@chfast](https://github.com/ethereum/tests/issues/483). Two additional
+case with three `SSTORE` operations is used to test the case when a
+slot is reset and then set again.
+
+| Code                               | Used Gas | Refund | Original | 1st | 2nd | 3rd |
+|------------------------------------|----------|--------|----------|-----|-----|-----|
+| `0x60006000556000600055`           | 412      | 0      | 0        | 0   | 0   |     |
+| `0x60006000556001600055`           | 20212    | 0      | 0        | 0   | 1   |     |
+| `0x60016000556000600055`           | 20212    | 19800  | 0        | 1   | 0   |     |
+| `0x60016000556002600055`           | 20212    | 0      | 0        | 1   | 2   |     |
+| `0x60016000556001600055`           | 20212    | 0      | 0        | 1   | 1   |     |
+| `0x60006000556000600055`           | 5212     | 15000  | 1        | 0   | 0   |     |
+| `0x60006000556001600055`           | 5212     | 4800   | 1        | 0   | 1   |     |
+| `0x60006000556002600055`           | 5212     | 0      | 1        | 0   | 2   |     |
+| `0x60026000556000600055`           | 5212     | 15000  | 1        | 2   | 0   |     |
+| `0x60026000556003600055`           | 5212     | 0      | 1        | 2   | 3   |     |
+| `0x60026000556001600055`           | 5212     | 4800   | 1        | 2   | 1   |     |
+| `0x60026000556002600055`           | 5212     | 0      | 1        | 2   | 2   |     |
+| `0x60016000556000600055`           | 5212     | 15000  | 1        | 1   | 0   |     |
+| `0x60016000556002600055`           | 5212     | 0      | 1        | 1   | 2   |     |
+| `0x60016000556001600055`           | 412      | 0      | 1        | 1   | 1   |     |
+| `0x600160005560006000556001600055` | 40218    | 19800  | 0        | 1   | 0   | 1   |
+| `0x600060005560016000556000600055` | 10218    | 19800  | 1        | 0   | 1   | 0   |
 
 ## Implementation
 
 To be added.
 
+## Appendix: Proof
+
+Because the *storage slot's original value* is defined as the value
+when a reversion happens on the *current transaction*, it's easy to
+see that call frames won't interfere SSTORE gas calculation. So
+although the below proof is discussed without call frames, it applies
+to all situations with call frames. We will discuss the case
+separately for *original value* being zero and not zero, and use
+*induction* to prove some properties of SSTORE gas cost.
+
+*Final value* is the value of a particular storage slot at the end of
+a transaction. *Absolute gas used* is the absolute value of *gas used*
+minus *refund*. We use `N` to represent the total number of SSTORE
+operations on a storage slot. For states discussed below, refer to
+*State Transition* in *Explanation* section.
+
+### Original Value Being Zero
+
+When *original value* is 0, we want to prove that:
+
+* **Case I**: If the *final value* ends up still being 0, we want to charge `200 *
+  N` gases, because no disk write is needed.
+* **Case II**: If the *final value* ends up being a non-zero value, we want to
+  charge `20000 + 200 * (N-1)` gas, because it requires writing this
+  slot to disk.
+  
+#### Base Case
+
+We always start at state A. The first SSTORE can:
+
+* Go to state A: 200 gas is deducted. We satisfy *Case I* because
+  `200 * N == 200 * 1`.
+* Go to state B: 20000 gas is deducted. We satisfy *Case II* because
+  `20000 + 200 * (N-1) == 20000 + 200 * 0`.
+  
+#### Inductive Step
+
+* From A to A. The previous gas cost is `200 * (N-1)`. The current
+  gas cost is `200 + 200 * (N-1)`. It satisfy *Case I*.
+* From A to B. The previous gas cost is `200 * (N-1)`. The current
+  gas cost is `20000 + 200 * (N-1)`. It satisfy *Case II*.
+* From B to B. The previous gas cost is `20000 + 200 * (N-2)`. The
+  current gas cost is `200 + 20000 + 200 * (N-2)`. It satisfy
+  *Case II*.
+* From B to A. The previous gas cost is `20000 + 200 * (N-2)`. The
+  current gas cost is `200 - 19800 + 20000 + 200 * (N-2)`. It satisfy
+  *Case I*.
+  
+### Original Value Not Being Zero
+
+When *original value* is not 0, we want to prove that:
+
+* **Case I**: If the *final value* ends up unchanged, we want to
+  charge `200 * N` gases, because no disk write is needed.
+* **Case II**: If the *final value* ends up being zero, we want to
+  charge `5000 - 15000 + 200 * (N-1)` gas. Note that `15000` is the
+  refund in actual definition.
+* **Case III**: If the *final value* ends up being a changed non-zero
+  value, we want to charge `5000 + 200 * (N-1)` gas.
+  
+#### Base Case
+
+We always start at state X. The first SSTORE can:
+
+* Go to state X: 200 gas is deducted. We satisfy *Case I* because
+  `200 * N == 200 * 1`.
+* Go to state Y: 5000 gas is deducted. We satisfy *Case III* because
+  `5000 + 200 * (N-1) == 5000 + 200 * 0`.
+* Go to state Z: The absolute gas used is `5000 - 15000` where 15000
+  is the refund. We satisfy *Case II* because `5000 - 15000 + 200 *
+  (N-1) == 5000 - 15000 + 200 * 0`.
+  
+#### Inductive Step
+
+* From X to X. The previous gas cost is `200 * (N-1)`. The current gas
+  cost is `200 + 200 * (N-1)`. It satisfy *Case I*.
+* From X to Y. The previous gas cost is `200 * (N-1)`. The current gas
+  cost is `5000 + 200 * (N-1)`. It satisfy *Case III*.
+* From X to Z. The previous gas cost is `200 * (N-1)`. The current
+  absolute gas cost is `5000 - 15000 + 200 * (N-1)`. It satisfy *Case
+  II*.
+* From Y to X. The previous gas cost is `5000 + 200 * (N-2)`. The
+  absolute current gas cost is `200 - 4800 + 5000 + 200 * (N-2)`. It
+  satisfy *Case I*.
+* From Y to Y. The previous gas cost is `5000 + 200 * (N-2)`. The
+  current gas cost is `200 + 5000 + 200 * (N-2)`. It satisfy *Case
+  III*.
+* From Y to Z. The previous gas cost is `5000 + 200 * (N-2)`. The
+  current absolute gas cost is `200 - 15000 + 5000 + 200 * (N-2)`. It
+  satisfy *Case II*.
+* From Z to X. The previous gas cost is `5000 - 15000 + 200 *
+  (N-2)`. The current absolute gas cost is `200 + 10200 + 5000 -
+  15000 + 200 * (N-2)`. It satisfy *Case I*.
+* From Z to Y. The previous gas cost is `5000 - 15000 + 200 *
+  (N-2)`. The current absolute gas cost is `200 + 15000 + 5000 -
+  15000 + 200 * (N-2)`. It satisfy *Case III*.
+* From Z to Z. The previous gas cost is `5000 - 15000 + 200 *
+  (N-2)`. The current absolute gas cost is `200 + 5000 - 15000 + 200 *
+  (N-2)`. It satisfy *Case II*.
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
