Update eip-1418.md (#6416)

* Update eip-1418.md

* Update EIPS/eip-1418.md

* MD formatting

---------

Co-authored-by: Sam Wilson <[email protected]>

EIPS/eip-1418.md

@@ -1,7 +1,7 @@
 ---
 eip: 1418
 title: Blockchain Storage Rent Payment
-description: At each block, deduct an amount of value from every account based on the quantity of storage used by that account.
+description: At each block, deduct value from every account based on the quantity of storage used by that account.
 author: William Entriken (@fulldecent)
 discussions-to: https://ethereum-magicians.org/t/eip-1418-storage-rent/10737
 status: Draft
@@ -13,7 +13,7 @@ requires: 1559
 
 ## Abstract
 
-At each block, deduct an amount of value or rent from every account based on the quantity of storage used by that account.
+At each block, deduct an amount of value ("rent") from every account based on the quantity of storage used by that account.
 
 ## Motivation
 
@@ -23,7 +23,7 @@ Ethereum is a public utility and we are underpricing the long-term costs of stor
 
 **Updated transaction type**
 
-[EIP-1559](./eip-1559.md) transaction type 2 is updated so that clients can send a contract's code as part of a transaction, just the same way as now how clients can send state variables.
+A new transaction type is introduced. Whereas [EIP-1559](./eip-1559.md) introduced warm access for contract state, this new type introduces warm access for contract code.
 
 **New state variables (per account)**
 
@@ -39,7 +39,7 @@ Ethereum is a public utility and we are underpricing the long-term costs of stor
 **New opcodes**
 
 * **`RENTBALANCE(address)`** -- G_BALANCE -- Similar to `BALANCE`
-  * This returns the logical `σ[a]_rent` value which is defined to reduce each block. It is possible for the implementation to calculate this value using the recommended implementation variables, rather than storing an updating  `σ[a]_rent` every block for every account.
+  * This returns the logical `σ[a]_rent` value which is defined to reduce each block. It is possible for the implementation to calculate this value using the recommended implementation variables, rather than storing and updating  `σ[a]_rent` every block for every account.
 * **`SENDRENT(address, amount)`** -- G_BASE -- Convert value to rent and send to account
   1. `σ[account]_rent` += amount
   2. `σ[msg.sender]_balance` -= amount
@@ -69,19 +69,20 @@ END PAYRENT
 
 * **`SSTORE(account, key, value)`**
   * Perform PAYRENT(account)
-  * If `account` is evicted (i.e. `NUMBER` > `σ[account]_rentEvictBlock`) then transaction fails unless the transaction includes this storage key in EIP-1559 type 2 transaction.
+  * If `account` is evicted (i.e. `NUMBER` > `σ[account]_rentEvictBlock`) then transaction fails unless using the new transaction type and sufficient proofs are included to validate the old storage root and calculate the new root.
   * Do normal SSTORE operation
-  * If the old value was zero for this [account, key] and the new value is non-zero, then `σ[account]_storageWord++`
+  * If the old value was zero for this [account, key] and the new value is non-zero, then `σ[account]_storageWords++`
   * If the old value was non-zero for this [account, key] and the new value is zero, then `σ[account]_storageWords--`, and if the result is negative then set to zero
 * **`SLOAD(account, key)`**
-  * If `account` is evicted (i.e. `NUMBER` > `σ[account]_rentEvictBlock`) then transaction fails unless the transaction includes this storage key in EIP-1559 type 2 transaction.
+  * If `account` is evicted (i.e. `NUMBER` > `σ[account]_rentEvictBlock`) then transaction fails unless using the new transaction type and sufficient proofs are included to validate the existing storage root and the existing storage value.
   * Do normal SLOAD operation.
 * **`CALL (and derivatives)`**
-  * If the target block is evicted (i.e. `NUMBER` > `σ[account]_rentEvictBlock`) then transaction fails unless the transaction includes this account's code in EIP-1559 type 2 extended transaction.
+  * If the target block is evicted (i.e. `NUMBER` > `σ[account]_rentEvictBlock`) then transaction fails unless using the new transaction type and sufficient proof is included to validate the existing code.
   * Do normal CALL operation
 * **`CREATE`**
   * Set σ[account]_rentLastPaid = NUMBER
   * Do normal CREATE operation
+  * `σ[account]_storageWord = 0`
   * Note: it is possible there is a pre-existing rent balance here
 
 **New built-in contract**
@@ -90,6 +91,22 @@ END PAYRENT
   * This is a convenience for humans to send Ether from their accounts and turn it into rent. Note that simple accounts (CODESIZE == 0) cannot call arbitrary opcodes, they can only call CREATE or CALL.
   * The gas cost of PAYRENT will be 10,000 or lower if possible.
 
+**Calculating `σ[account]_storageWord` for existing accounts**
+
+DRAFT...
+
+It is not an acceptable upgrade if on the fork block it is necessary for only archive nodes to participate which know the full storage amount for each account.
+
+An acceptable upgrade will be if the required `σ[account]_storageWord` can be calculated (or estimated) incrementally based on new transaction activity.
+
+DRAFT: I think it is possible to make such an acceptable upgrade using an unbiased estimator
+
+* add one bit of storage per `SSTORE` for legacy accounts on the first access of a given key
+* add log(n) bits for each trie level
+* assume that storage keys are a random variable
+
+To think more about...
+
 **No changes to current opcode gas costs.**
 
 ## Rationale 
@@ -120,6 +137,8 @@ But the contract can spend all of its value.
 
 By maintaining a separate rent and value balance, this allows people to contribute to the rent while being confident that this is allowing the contract to stay around.
 
+NOTE: cloning. With this EIP, it may become feasible to allow storage cloning. Yes really. Because the new clone will be paying rent. See other EIP, I think made by Augur team.
+
 ### Economics & constants
 
 An `SSTORE` executed in 2015 cost 20,000 gas and has survived about 6 million blocks. The gas price has been around 1 ~ 50 Gwei. So basically 4,000 Wei per block per word so far. Maybe storing an account is 10 times more intensive than storing a word. But actually `G_transaction` is 21,000 and `G_sstore` is 20,000 so these are similar and they can both create new accounts / words.
@@ -167,9 +186,10 @@ Many smart contracts allow anybody to use an arbitrary amount of storage in them
 Copyright and related rights waived via CC0.
 
 <!--
+
  ## TODO
 
  To discuss:
 
  - Can/should an evicted account be allowed to be un-evicted when paying past due rent?
--->
+   -->