diff --git a/EIPS/eip-1108.md b/EIPS/eip-1108.md
index 792cc9085c016..e67cd8a8f286c 100644
--- a/EIPS/eip-1108.md
+++ b/EIPS/eip-1108.md
@@ -59,7 +59,19 @@ Following is a table with the current gas cost and new gas cost:
The gas costs for `ECADD` and `ECMUL` are updates to the costs listed in
EIP-196, while the gas costs for the pairing check are updates to the cost
listed in EIP-197. Updated gas costs have been adjusted to the less performant
-client which is Parity, according to benchmarks[3]. The updated gas costs are scaled relative to the `ecrecover` precompile. i.e. in the benchmark, `ecrecover` ran in 116 microseconds. If we consider 3,000 gas the fair price for `ecrecover`, we can obtain a metric how much gas should be charged per microsecond of an algorithm's runtime, and use that to price the elliptic curve precompiles.
+client which is Parity, according to benchmarks[3].
+
+To come up with these updates gas costs, the performance of the `ecrecover` precompile
+was measured at 116 microseconds per `ecrecover` invocation. Assuming the `ecrecover`
+gas price is fair at 3,000 gas, we get a price of 25.86 gas per microsecond of a precompile
+algorithm's runtime. With this in mind, the pairing precompile took 3,037 microseconds to
+compute 1 pairing, and 14,663 microseconds to compute 10 pairings. From this, the pairing
+algorithm has a fixed 'base' run-time of 1,745 microseconds, plus 1,292 microseconds per
+pairing. We can split the run-time into 'fixed cost' and 'linear cost per pairing'
+components because of the structure of the algorithm.
+
+Thus using a 'fair' price of 25.86 gas per microsecond, we get a gas formula of
+~`35,000 * k + 45,000` gas, where `k` is the number of pairings being computed. [4]
[1]- Per [EIP-196](https://github.com/ethereum/EIPs/blob/984cf5de90bbf5fbe7e49be227b0c2f9567e661e/EIPS/eip-196.md#gas-costs).
@@ -67,6 +79,8 @@ client which is Parity, according to benchmarks[3]. The updated gas c
[3]- [Parity benchmarks.](https://gist.github.com/zac-williamson/838410a3da179d47d31b25b586c15e53)
+[4]- [PR comment clarifying gas cost math](https://github.com/ethereum/EIPs/pull/1987#discussion_r280977066).
+
## Rationale
### Existing protocols would benefit immensely from cheaper elliptic curve cryptography
@@ -116,3 +130,7 @@ Both the Parity and Geth clients have already implemented cryptographic librarie
* [Geth bn256 library (golang)](https://github.com/ethereum/go-ethereum/tree/master/crypto/bn256/cloudflare)
* [MCL, a portable C++ pairing library](https://github.com/herumi/mcl)
* [Libff, a C++ pairing library used in many zk-SNARK libraries](https://github.com/scipr-lab/libff)
+
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
diff --git a/EIPS/eip-1418.md b/EIPS/eip-1418.md
index 6289137a62550..398adaa3f87e0 100644
--- a/EIPS/eip-1418.md
+++ b/EIPS/eip-1418.md
@@ -1,7 +1,7 @@
---
eip: 1418
title: Blockchain Storage Rent Payment
-author: William Entriken <@fulldecent>
+author: William Entriken (@fulldecent)
discussions-to: https://github.com/ethereum/EIPs/issues/1418
status: Draft
type: Standards Track
diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md
index 0021feaae2663..c7e99985869ec 100644
--- a/EIPS/eip-1679.md
+++ b/EIPS/eip-1679.md
@@ -29,6 +29,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista
### Proposed EIPs
- [EIP-615](https://eips.ethereum.org/EIPS/eip-615): Subroutines and Static Jumps for the EVM
+- [EIP-663](https://eips.ethereum.org/EIPS/eip-663): Unlimited SWAP and DUP instructions
- [EIP-1057](https://eips.ethereum.org/EIPS/eip-1057): ProgPoW, a Programmatic
Proof-of-Work
- There is a
@@ -36,6 +37,8 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista
above and beyond standard security considerations, that should be evaluated
prior to inclusion.
- [EIP-1108](https://eips.ethereum.org/EIPS/eip-1108): Reduce alt_bn128 precompile gas costs
+- [EIP-1109](https://eips.ethereum.org/EIPS/eip-1109): PRECOMPILEDCALL opcode (Remove CALL costs for precompiled contracts)
+ - requirement of EIP-1962
- [EIP-1283](https://eips.ethereum.org/EIPS/eip-1283): Net gas metering for SSTORE without dirty maps
- [EIP-1344](https://eips.ethereum.org/EIPS/eip-1344): Add ChainID opcode
- [EIP-1352](https://eips.ethereum.org/EIPS/eip-1352): Specify restricted address range for precompiles/system contracts
@@ -48,8 +51,18 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista
- [EIP-1829](https://eips.ethereum.org/EIPS/eip-1829): Precompile for Elliptic Curve Linear Combinations
- [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes
- [EIP-1930](https://eips.ethereum.org/EIPS/eip-1930): CALLs with strict gas semantic. Revert if not enough gas available.
+- [EIP-1985](https://eips.ethereum.org/EIPS/eip-1985): Sane limits for certain EVM parameters
- [EIP-1959](https://eips.ethereum.org/EIPS/eip-1959): New Opcode to check if a chainID is part of the history of chainIDs
+- [EIP-1962](https://eips.ethereum.org/EIPS/eip-1962): EC arithmetic and pairings with runtime definitions
+ - replaces EIP-1829
+- [EIP-2014](https://eips.ethereum.org/EIPS/eip-2014): Extended State Oracle
+- [EIP-2026](https://eips.ethereum.org/EIPS/eip-2026): State Rent H - Fixed Prepayment for accounts
+- [EIP-2027](https://eips.ethereum.org/EIPS/eip-2027): State Rent C - Net contract size accounting
- [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028): Calldata gas cost reduction
+- [EIP-2029](https://eips.ethereum.org/EIPS/eip-2029): State Rent A - State counters contract
+ - requirement of EIP-2031
+- [EIP-2031](https://eips.ethereum.org/EIPS/eip-2031): State Rent B - Net transaction counter
+- [EIP-2035](https://eips.ethereum.org/EIPS/eip-2035): Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs
- [EIP-2046](https://eips.ethereum.org/EIPS/eip-2046): Reduced gas cost for static calls made to precompiles
## Timeline
diff --git a/EIPS/eip-1930.md b/EIPS/eip-1930.md
index abf1456cb9b15..8223277326e09 100644
--- a/EIPS/eip-1930.md
+++ b/EIPS/eip-1930.md
@@ -52,6 +52,23 @@ if !callCost.IsUint64() || gas < callCost.Uint64() {
}
```
+Since checks on gas break current implementation of `eth_estimateGas`, the opcodes need to also use the mechanism described in [EIP-2075](https://github.com/ethereum/EIPs/pull/2075) to ensure `eth_estimateGas` return a value that is sufficient for the transaction to succeed. It must thus set `minimalGas` to equal the max of the current value of `minimalGas` and the sum of the gas spent so far added to the gas required.
+
+More precisely, as described in EIP-2075:
+
+Let specify `minimalGas` as a new variable that the EVM need to keep track for the purpose of `eth_estimateGas`. At the start of a tx, it is set to zero.
+
+At the end of an `eth_estimateGas` call, the gas spent is compared to `minimalGas`. The bigger value of the two is returned as "estimate". It does not have any other role in the context of a transaction call, its only purpose is to fix the current behavior of `eth_estimateGas` so that call to the opcodes describe here return a useful estimate
+
+If there is enough gas, the gas amount specified will be added to the gas spent up to that point. If that amount is bigger than minimalGas it replaces it. In other words:
+
+```minimalGas = max(minimalGas, X + )```
+where X is the value passed to REQUIRE_GAS
+
+As mentioned the result of an `eth_estimateGas` is now
+
+```max(, minimalGas)```
+
### Rationale
Currently the gas specified as part of these opcodes is simply a maximum value. And due to the behavior of [EIP-150](http://eips.ethereum.org/EIPS/eip-150) it is possible for an external call to be given less gas than intended (less than the gas specified as part of the CALL) while the rest of the current call is given enough to continue and succeed. Indeed since with EIP-150, the external call is given at max ```G - Math.floor(G/64)``` where G is the gasleft() at the point of the CALL, the rest of the current call is given ```Math.floor(G/64)``` which can be plenty enough for the transaction to succeed. For example, when G = 6,400,000 the rest of the transaction will be given 100,000 gas plenty enough in many case to succeed.
diff --git a/EIPS/eip-2027.md b/EIPS/eip-2027.md
new file mode 100644
index 0000000000000..eb7b4ced6bd71
--- /dev/null
+++ b/EIPS/eip-2027.md
@@ -0,0 +1,74 @@
+---
+eip: 2027
+title: State Rent C - Net contract size accounting
+author: Alexey Akhunov (@AlexeyAkhunov)
+discussions-to: https://ethereum-magicians.org/t/eip-2027-net-contract-size-accounting-change-c-from-state-rent-v3-proposal/3275
+status: Draft
+type: Standards Track
+category: Core
+created: 2019-05-14
+---
+
+
+
+## Simple Summary
+
+Ethereum starts counting the number of storage slots filled and emptied in the contracts. Since the number of pre-existing slots is not currently accounted
+in the state, effectively, only net change in the number of slots is tracked. In the subsequent change, called *Gross contract size accounting*, the total
+number of storage slots starts being tracked.
+
+## Abstract
+
+This is part of the State Rent roadmap. This particular change introduces initial, net accounting of the number of the contract storage slots. Though not very
+useful on its own, it makes it possible to introduce gross accounting of the number of storage slots, which is useful for number of things:
+1. Gas cost of operations suchs as `SLOAD` and `SSTORE` will need to be increased to compensate for extra bandwidth consumed by the block proofs. Although in
+the beginning the cost would be fixed, it will later be automatically calibrated depending on the size of the contract `SLOAD` and `SSTORE` operate on.
+2. Snapshot sync protocols, like *fast sync*, *warp sync*, *firehose*, *red queen*, and perhaps others, will benefit from having the correct size of the
+contract storage present in the state (and therefore being provable via Merkle proofs).
+
+## Motivation
+
+Ethereum currently does not track the number of contract storage slots at all, and producing such number given the downloaded state cannot be done in
+constant *O(1)* time.
+
+## Specification
+
+Each contract (account with `codeHash` field not equal to 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470, which the hash of the empty code) gets a new uint64 field, called `storagesize`. On and after block `C`, the semantics of the operation `SSTORE` (`location`, `value`) changes as follows:
+- If previous value of the [`location`] is 0, and value is not 0, *increment* `storagesize` (semantics of *increment* described below)
+- If previous value of the [`location`] is not 0, and value is 0, *decrement* `storagesize` (semantics of *decrement* described below)
+- As with other state changes, changes of `storagesize` get reverted when the execution frame reverts, i.e. it needs to use the same techniques as storage values, like journalling (in Geth), and substates (in Parity).
+Value of `storagesize` is not observable from contracts at this point.
+
+### Semantics of *increment* `storagesize`
+If `storagesize` is not present, `storagesize` = `HUGE_NUMBER` + 1.
+If `storagesize` is present, `storagesize` = `storagesize` + 1.
+
+### Semantics of *decrement* `storagesize`
+If `storagesize` is not present, `storagesize` = `HUGE_NUMBER` - 1.
+If `storagesize` is present, `storagesize` = `storagesize` - 1.
+
+### Note of `HUGE_NUMBER`
+There is a constant `HUGE_NUMBER`. It needs to be large enough so that no real metrics (contract storage size, number of accounts, number of contracts, total size of code, total size of storage) will never reach that number, and small enough that it fits in an unsigned 64-bit integer.
+Current suggestion is to have `HUGE_NUMBER` = 2^63, which is binary representation is the a single bit in a 64-bit number.
+
+The idea is to make it decidable later whether the storagesize was ever incremented/decremented (presence of the field), and whether it has been converted from net to gross (by value being smaller than `HUGE_NUMBER/2` - because it will not be possible for any contract be larger than 2^62 at the block `C`).
+
+## Rationale
+
+A mechanism for estimation of contract storage size has been proposed [here](https://medium.com/@akhounov/estimation-approximate-of-the-size-of-contracst-in-ethereum-4642fe92d6fe). But it does have a big drawback of introducing a lot of complexity into the consensus
+(in the form of estimation algorithm, which has quite a few edge cases to cater for different sizes of the storage).
+
+## Backwards Compatibility
+
+This change is not backwards compatible and requires hard fork to be activated. Since the newly introduced field is not observable, this change does not impact any operations of the existing smart contracts.
+
+## Test Cases
+
+Tests cases will be generated out of a reference implementation.
+
+## Implementation
+
+There will be proof of concept implementation to refine and clarify the specification.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
diff --git a/EIPS/eip-2031.md b/EIPS/eip-2031.md
new file mode 100644
index 0000000000000..894eb0d9fc032
--- /dev/null
+++ b/EIPS/eip-2031.md
@@ -0,0 +1,61 @@
+---
+eip: 2031
+title: State Rent B - Net transaction counter
+author: Alexey Akhunov (@AlexeyAkhunov)
+discussions-to: https://ethereum-magicians.org/t/eip-2031-net-transaction-counter-change-b-from-state-rent-v3-proposal/3283
+status: Draft
+type: Standards Track
+category: Core
+created: 2019-05-15
+requires: 2029
+---
+
+
+
+## Simple Summary
+
+Ethereum starts to track the number of transactions inside its state (for now, only number of transactions after this change is introduced, therefore
+it is called *Net* transaction count).
+It is done by incrementing a storage slot in the special contract, called *State counter contract* ([EIP-2029](https://eips.ethereum.org/EIPS/eip-2029)).
+
+## Abstract
+
+It is part of the State Rent roadmap. This particular change makes any Ethereum transaction increment the transaction counter, which is a special storage slot
+in the *State counter contract*. This counter will be used to populate the nonces of newly created
+non-contract accounts. This way of populating nonce ensures replay protection for accounts that were evicted and then brought back by sending ether to them.
+
+## Motivation
+
+Ethereum currently does not have a special place in the state for tracking number of transactions.
+
+## Specification
+
+A new field, with the location 0 (that means it resides in the storage slot 0 in the state counter contract, and can
+be read by calling that contract with argument being 32 zero bytes), is added to the state counter contract. It will eventually contain `txCount`, the total number of transactions processed up until that point.
+On an after block B, or after the deployment of the state counter contract (which comes first), the field `txCount` is incremented after each transaction. Updating `txCount` means updating the storage of state counter contract at the location 0. These changes are never reverted.
+
+## Rationale
+
+Two main alternatives were proposed for the replay protection of the accounts that were evicted by subsequently brought back by sending ether to them:
+1. Temporal replay protection. The nonce of the new accounts (and those brought back) is still zero, but a new `valid-until` field is introduced, making
+transactions invalid for inclusion after the time specified in this field. This, however, has unwanted side effected related to the fact that account
+nonces are not only used for replay protection, but also for computing the addresses of the deployed contracts (except those created by `CREATE2`).
+2. Setting nonce of new accounts (and those brought back) to something depending on the current block number. This approach requires coming up with
+an arbitrary parameter, which is the maximum number of transaction in the block, so that the new nonces never clash with the existing nonces.
+This is mostly a concern for private networks at the moment, because they will potentially have significantly more transactions in a block.
+
+## Backwards Compatibility
+
+This change is not backwards compatible and requires hard fork to be activated.
+
+## Test Cases
+
+Tests cases will be generated out of a reference implementation.
+
+## Implementation
+
+There will be proof of concept implementation to refine and clarify the specification.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
diff --git a/EIPS/eip-2035.md b/EIPS/eip-2035.md
new file mode 100644
index 0000000000000..6b0eac7f5866a
--- /dev/null
+++ b/EIPS/eip-2035.md
@@ -0,0 +1,81 @@
+---
+eip: 2035
+title: Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs
+author: Alexey Akhunov (@AlexeyAkhunov)
+discussions-to: https://ethereum-magicians.org/t/eip-2035-stateless-clients-repricing-sload-and-sstore-to-pay-for-block-proofs/3284
+status: Draft
+type: Standards Track
+category: Core
+created: 2019-05-16
+---
+
+
+
+## Simple Summary
+
+The gas cost of EVM opcodes `SLOAD` and `SSTORE` increases in order to accommodate extra bandwidth required to propagate block proof together with the block
+headers and block bodies, as explained [here](https://medium.com/@akhounov/data-from-the-ethereum-stateless-prototype-8c69479c8abc).
+
+## Abstract
+
+It is part of the State Rent roadmap. This particular change prepares Ethereum for introduction of the block proofs (current understanding is that they
+can be introuced without a hard fork). The introduction of the block proofs allows any Ethereum node that wishes to receive them, to process transactions
+in the blocks without needing to access the Ethereum state. All necessary information for the execution (and the proof of validity) is continued in the
+block proofs. In most Ethereum nodes, it will speed up the block processing and reduce the memory footprint of such processing. For mining nodes, however,
+there will be more work to do to construct and transmit the block proofs. Therefore, the extra charge (payable to the miners) is introduced. In the first
+phase, only contract storage will be covered by the block proofs. It means that the Ethereum nodes will still need access to the accounts in the state,
+but block proofs will make it optional to have access to contract storage for executing transactions. Therefore, only `SSTORE` and `SLOAD` opcodes are
+affected.
+
+## Motivation
+
+There is [empirical analysis](https://github.com/holiman/vmstats/blob/master/README.md) showing that `SLOAD` opcode is currently underpriced in terms
+of execution latency it adds to the block processing. The hypothesis is that it is due to the latency of the database accesses. In the same
+analysis, `SSTORE` is not considered, because its effect on the database accesses can be (and are in many implementations) delayed until the end of
+the block. Stateless clients approach to the contract storage will largely negate that latency because no database accesses will be required.
+Instead, bandwidth consumption goes up. There is emprical analysis (unpublished, but will be) suggesting that 1 uncached `SSTORE` or `SLOAD` adds
+at most 1 kB to the block proofs. At the current cost of data transmission (68 gas per byte), this translates to the increase of gas cost of both
+operations by 69k gas. However, in light of proposal in [EIP-2028](https://eips.ethereum.org/EIPS/eip-2028), the increase can be made much smaller.
+
+## Specification
+
+Not very formal at the moment, but will be formalised with more research and prototyping. Gas of operations `SLOAD` and `SSTORE` increases by `X` gas when the storage slots accessed (read by `SLOAD` or written by `SSTORE`) were not previously accessed (by another `SLOAD` or `SSTORE`) during the same transaction.
+
+Future variant (will be possible after the implementation of the *Gross contract size acccounting*) is researched, where the increase is varied
+depending on the size of the contract storage, i.e. `SLOAD` and `SSTORE` for smaller contracts will be cheaper.
+
+## Rationale
+
+[EIP-1884](https://eips.ethereum.org/EIPS/eip-1884) seeks to increase the gas cost of `SLOAD` but using a different justification
+(latency of the execution as described in the Motivation). This EIP is likely to increase the cost of `SLOAD` by a larger amount, therefore partially
+(because EIP-1884 also proposed other increases) supersedes EIP-1884.
+
+[EIP-2028](https://eips.ethereum.org/EIPS/eip-2028) describes the model that can be used for deciding the gas cost of data transmission. It is relevant
+because in the stateless client regime `SSTORE` and `SLOAD` operations add more data to be transmitted (as well as computation to verify the proofs).
+
+The main alternate design is the rent proportional to the size of the contract storage, which unfortunately introduces a serious griefing
+vulnerability problem, and so far the solution seems to be in redesigning and rewriting smart contracts in a way, which makes them not vulnerable.
+However, this approach is likely to be very expensive on the non-technical (ecosystem) level.
+
+## Backwards Compatibility
+
+This change is not backwards compatible and requires hard fork to be activated.
+There might also be an adverse effect of this change on the already deployed contract. It is expected that after this EIP and
+[EIP-2026](https://eips.ethereum.org/EIPS/eip-2026) (rent prepayment for accounts), the recommendation will be made to raise the gas limit. This can somewhat dampen the
+adverse effect of EIP. The most problematic cases would be with the contracts that assume certain gas costs of `SLOAD`
+and `SSTORE` and hard-code them in their internal gas computations. For others, the cost of interacting with the contract
+storage will rise and may make some dApps based on such interactions, non-viable. This is a trade off to avoid even bigger
+adverse effect of the rent proportional to the contract storage size. However, more research is needed to more fully
+analyse the potentially impacted contracts.
+
+## Test Cases
+
+Tests cases will be generated out of a reference implementation.
+
+## Implementation
+
+There will be proof of concept implementation to refine and clarify the specification.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+