Update

EIPS/eip-1344.md

@@ -17,10 +17,10 @@ This EIP adds an opcode that returns the current chain's EIP-155 unique identifi
 [EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md) proposes to use the chain ID to prevent replay attacks between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for Layer 2 signature schemes using [EIP-712](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md).
 
 ## Specification
-Adds a new opcode `CHAINID` at 0x46, which uses 0 stack arguments. It will push the current chain ID onto the stack. The operation costs `G_base` to execute.
+Adds a new opcode `CHAINID` at 0x46, which uses 0 stack arguments. It pushes the current chain ID onto the stack. The operation costs `G_base` to execute.
 
 ## Rationale
-The current approach proposed by EIP-712 is to specify the chain ID at compile time. Using this approach will result in problems after a hardfork, as well as human error that may lead to loss of funds or replay attacks on signed messages. 
+The current approach proposed by EIP-712 is to specify the chain ID at compile time. Using this approach will result in problems after a hardfork, as well as human error that may lead to loss of funds or replay attacks on signed messages.
 By adding the proposed opcode it will be possible to access the current chain ID and validate signatures based on that.
 
 Currently, there is no specification for how chain ID is set for a particular network, relying on choices made manually by the client implementers and the chain community. There is a potential scenario where, during a "contentious split" over a divisive issue, a community using a particular value of chain ID will make a decision to split into two such chains. When this scenario occurs, it will be unsafe to maintain chain ID to the same value on both chains, as chain ID is used for replay protection for in-protocol transactions (per EIP-155), as well as for L2 and "meta-transaction" use cases (per EIP-712 as enabled by this proposal). There are two potential resolutions in this scenario under the current process: 1) one chain decides to modify their value of chain ID (while the other keeps it), or 2) both chains decide to modify their value of chain ID.

EIPS/eip-1559.md

@@ -0,0 +1,74 @@
+---
+eip: 1559
+title: Fee market change for ETH 1.0 chain
+author: Vitalik Buterin (@vbuterin), Eric Conner (@econoar)
+discussions-to: https://ethereum-magicians.org/t/eip-1559-fee-market-change-for-eth-1-0-chain/2783
+status: Draft
+type: Standards Track
+category: Core
+created: 2019-04-13
+---
+
+<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
+
+## Simple Summary
+<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
+The current "first price auction" fee model in Ethereum is inefficient and needlessly costly to users. This EIP proposes a way to replace this with a mechanism that adjusts a base network fee based on network demand, creating better fee price efficiency and reducing the complexity of client software needed to avoid paying unnecessarily high fees.
+
+## Abstract
+<!--A short (~200 word) description of the technical issue being addressed.-->
+There is a BASEFEE value in protocol, which can move up or down by a maximum of 1/8 in each block; initially, miners adjust this value to target an average gas usage of 8 million, increasing BASEFEE if usage is higher and decreasing it if usage is lower. Transaction senders specify their fees by providing two values:
+
+* A "premium" gasprice which gets added onto the BASEFEE gasprice, which can either be set to a fairly low value (eg. 1 gwei) to compensate miners for uncle rate risk or to a high value to compete during sudden bursts of activity. The BASEFEE gets burned, the premium is given to the miner.
+
+* A "cap" which represents the maximum total that the transaction sender would be willing to pay to get included.
+
+## Motivation
+<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
+Ethereum currently prices transaction fees using a simple auction mechanism, where users send transactions with bids ("gasprices") and miners choose transactions with the highest bids, and transactions that get included pay the bid that they specify. This leads to several large sources of inefficiency:
+
+* **Mismatch between volatility of transaction fee levels and social cost of transactions**: transaction fees on mature public blockchains, that have enough usage so that blocks are full, tend to be extremely volatile. On Ethereum, minimum fees are typically around 2 gwei (10^9 gwei = 1 ETH), but sometimes go up to 20-50 gwei and have even on one occasion gone up to over 200 gwei: https://etherscan.io/chart/gasprice. This clearly creates many inefficiencies, because it's absurd to suggest that the cost incurred by the network from accepting one more transaction into a block actually is 100x more when gas prices are 200 gwei than when they are 2 gwei; in both cases, it's a difference between 8 million gas and 8.02 million gas.
+* **Needless delays for users**: because of the hard per-block gas limit coupled with natural volatility in transaction volume, transactions often wait for several blocks before getting included, but this is socially unproductive; no one significantly gains from the fact that there is no "slack" mechanism that allows one block to be bigger and the next block to be smaller to meet block-by-block differences in demand.
+* **Inefficiencies of first price auctions**: see https://ethresear.ch/t/first-and-second-price-auctions-and-improved-transaction-fee-markets/2410 for a detailed writeup. In short, the current approach, where transaction senders publish a transaction with a fee, miners choose the highest-paying transactions, and everyone pays what they bid, is well-known in mechanism design literature to be highly inefficient, and so complex fee estimation algorithms are required, and even these algorithms often end up not working very well, leading to frequent fee overpayment. See also https://blog.bitgo.com/the-challenges-of-bitcoin-transaction-fee-estimation-e47a64a61c72 for a Bitcoin core developer's description of the challenges involved in fee estimation in the status quo.
+* **Instability of blockchains with no block reward**: in the long run, blockchains where there is no issuance (including Bitcoin and Zcash) at present intend to switch to rewarding miners entirely through transaction fees. However, there are [known results](http://randomwalker.info/publications/mining_CCS.pdf) showing that this likely leads to a lot of instability, incentivizing mining "sister blocks" that steal transaction fees, opening up much stronger selfish mining attack vectors, and more. There is at present no good mitigation for this.
+
+The proposal in this EIP is to start with a BASEFEE amount which is adjusted up and down by the protocol based on how congested the network is. To accommodate this system, the network capacity would be increased to 16 million gas, so that 50% utilization matches up with our current 8 million gas limit. Then, when the network is at >50% capacity, the BASEFEE increments up slightly and when capacity is at <50%, it decrements down slightly. Because these increments are constrained, the maximum difference in BASEFEE from block to block is predictable. This then allows wallets to auto-set the gas fees for users in a highly reliable fashion. It is expected that most users will not have to manually adjust gas fees, even in periods of high network activity. For most users, the BASEFEE will be automatically set by their wallet, along with the addition of a small fixed amount, called a ‘tip’, to compensate miners (e.g. 0.5 gwei).
+
+An important aspect of this upgraded fee system is that miners only get to keep the tips. The BASEFEE is always burned (i.e. it is destroyed by the protocol). Burning this is important because it prevents miners from manipulating the fee in order to extract more fees from users. It also ensures that only ETH can ever be used to pay for transactions on Ethereum, cementing the economic value of ETH within the Ethereum platform.
+
+
+## Specification
+<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
+**Parameters**
+* `FORK_BLKNUM`: TBD
+* `BASEFEE_MAX_CHANGE_DENOMINATOR`: 8
+* `SLACK_COEFFICIENT`: 3
+* `TARGET_GASUSED`: 8,000,000
+
+
+**Proposal**
+For all blocks where `block.number >= FORK_BLKNUM`:
+
+* Impose a hard in-protocol gas limit of `SLACK_COEFFICIENT * TARGET_GASUSED`, used instead of the gas limit calculated using the previously existing formulas
+* Replace the `GASLIMIT` field in the block header with a BASEFEE field (the same field can be used)
+* Let `PARENT_BASEFEE` be the parent block's `BASEFEE` (or 1 billion wei if `block.number == FORK_BLKNUM`). A valid `BASEFEE` is one such that `abs(BASEFEE - PARENT_BASEFEE) <= max(1, PARENT_BASEFEE // BASEFEE_MAX_CHANGE_DENOMINATOR)`
+* Redefine the way the `tx.gasprice` field is used: define `tx.fee_premium = tx.gasprice // 2**128` and `tx.fee_cap = tx.gasprice % 2**128`
+* During transaction execution, we calculate the cost to the `tx.origin` and the gain to the `block.coinbase` as follows:
+  * Let `gasprice = min(BASEFEE + tx.fee_premium, tx.fee_cap)`. The `tx.origin` initially pays `gasprice * tx.gas`, and gets refunded `gasprice * (tx.gas - gasused)`.
+  * The `block.coinbase` gains `(gasprice - BASEFEE) * gasused`. If `gasprice < BASEFEE` (due to the `fee_cap`), this means that the `block.coinbase` _loses_ funds from this operation; in this case, check that the post-balance is non-negative and throw an exception if it is negative.
+As a default strategy, miners set `BASEFEE` as follows. Let `delta = block.gas_used - TARGET_GASUSED` (possibly negative). Set `BASEFEE = PARENT_BASEFEE + PARENT_BASEFEE * delta // TARGET_GASUSED // BASEFEE_MAX_CHANGE_DENOMINATOR`, clamping this result inside of the allowable bounds if needed (with the parameter setting above clamping will not be required).
+
+## Backwards Compatibility
+Transactions published before this EIP or by wallets that do not support this EIP will be interpreted by the above formulas as having a `fee_premium` of zero and a `fee_cap` of the fee that they submit. Provided that at least some miners are temporarily willing to be altruistic and accept zero-fee-premium transactions for a short period of time after the fork, this should not greatly affect usability. There is an invariant that a `gasprice` constructed "the old way" still constitutes an upper bound on the amount that a user will pay.
+
+
+## Test Cases
+<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
+
+
+## Implementation
+<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
+
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-1679.md

@@ -28,9 +28,18 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista
 
 ### Proposed EIPs
 
+- [EIP-1057](https://eips.ethereum.org/EIPS/eip-1057): ProgPoW, a Programmatic
+  Proof-of-Work
+  - There is a
+    [pending audit](https://medium.com/ethereum-cat-herders/progpow-audit-goals-expectations-75bb902a1f01),
+    above and beyond standard security considerations, that should be evaluated
+    prior to inclusion.
 - [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
+- [EIP-1380](https://eips.ethereum.org/EIPS/eip-1380): Reduced gas cost for call to self
 - [EIP-1702](https://eips.ethereum.org/EIPS/eip-1702): Generalized account versioning scheme
+- [EIP-1803](https://eips.ethereum.org/EIPS/eip-1803): Rename opcodes for clarity
+- [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes
 
 ## Timeline
 

EIPS/eip-1803.md

@@ -0,0 +1,41 @@
+---
+eip: 1803
+title: Rename opcodes for clarity
+author: Alex Beregszaszi (@axic)
+type: Standards Track
+category: Interface
+status: Draft
+created: 2017-07-28
+requires: 141
+---
+
+## Abstract
+
+Rename the `BALANCE`, `SHA3`, `NUMBER`, `GASLIMIT`, `GAS` and `INVALID` opcodes to reflect their true meaning.
+
+## Specification
+
+Rename the opcodes as follows:
+- `BALANCE` (`0x31`) to `EXTBALANCE` to be in line with `EXTCODESIZE`, `EXTCODECOPY` and `EXTCODEHASH`
+- `SHA3` (`0x20`) to `KECCAK256`
+- `NUMBER` (`0x43`) to `BLOCKNUMBER`
+- `GASLIMIT` (`0x45`) to `BLOCKGASLIMIT` to avoid confusion with the gas limit of the transaction
+- `GAS` (`0x5a`) to `GASLEFT` to be clear what it refers to
+- `INVALID` (`0xfe`) to `ABORT` to clearly articulate when someone refers this opcode as opposed to "any invalid opcode"
+
+## Backwards Compatibility
+
+This has no effect on any code. It can influence what mnemonics assemblers will use.
+
+## Implementation
+
+Not applicable.
+
+## References
+
+[EIP-6](https://eips.ethereum.org/EIPS/eip-6) previously renamed `SUICIDE` (`0xff`) to `SELFDESTRUCT`.
+Renaming `SHA3` was previously proposed by [EIP-59](https://github.com/ethereum/EIPs/issues/59).
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

EIPS/eip-1884.md

@@ -7,6 +7,7 @@ category: Core
 discussions-to: https://ethereum-magicians.org/t/opcode-repricing/3024
 status: Draft
 created: 2019-03-28
+requires: 150
 ---
 
 
@@ -33,8 +34,8 @@ If operations are well-balanced, we can maximise the block gaslimit and have a m
 
 At block `N`, 
 
-- The `SLOAD` operation changes from `200` to `800` gas,
-- The `BALANCE` operation changes from `400` to `700` gas,
+- The `SLOAD` (`0x54`) operation changes from `200` to `800` gas,
+- The `BALANCE` (`0x31`) operation changes from `400` to `700` gas,
 - A new opcode, `SELFBALANCE` is introduced at `0x46`. 
   - `SELFBALANCE` pops `0` arguments off the stack, 
   - `SELFBALANCE` pushes the `balance` of the current address to the stack,
@@ -47,7 +48,7 @@ Here are two charts, taken from a full sync using Geth. The execution time was m
 ![bars1](../assets/eip-1884/run3.total-bars-5.png) 
 ![bars2](../assets/eip-1884/run3.total-bars-6.png) 
 
-Note: It can also be seen that the `SLOAD` moves towards the top position. The `GASPRICE` opcode has position one which I believe can be optimized away within the client -- which is not the case with `SLOAD`/`BALANCE`.
+Note: It can also be seen that the `SLOAD` moves towards the top position. The `GASPRICE` (`0x3a`) opcode has position one which I believe can be optimized away within the client -- which is not the case with `SLOAD`/`BALANCE`.
 
 Here is another chart, showing a full sync with Geth. It represents the blocks `0` to `5.7M`, and highlights what the block processing time is spent on.
 

EIPS/eip-4.md

@@ -1,6 +1,5 @@
 ---
 eip: 4
-layer: Process
 title: EIP Classification
 author: Joseph Chow
 status: Draft

EIPS/eip-6.md

@@ -5,7 +5,6 @@ author: Hudson Jameson <hudson@hudsonjameson.com>
 status: Final
 type: Standards Track
 category: Interface
-layer: Applications
 created: 2015-11-22
 ---
 

EIPS/eip-777.md

@@ -4,7 +4,7 @@ title: ERC777 Token Standard
 author: Jacques Dafflon <mail@0xjac.com>, Jordi Baylina <jordi@baylina.cat>, Thomas Shababi <tom@truelevel.io>
 discussions-to: https://github.com/ethereum/EIPs/issues/777
 status: Last Call
-review-period-end: 2019-04-28
+review-period-end: 2019-05-06
 type: Standards Track
 category: ERC
 created: 2017-11-20

README.md

@@ -22,6 +22,7 @@ When you believe your EIP is mature and ready to progress past the draft phase,
  - **For all other EIPs**, open a PR changing the state of your EIP to 'Final'. An editor will review your draft and ask if anyone objects to its being finalised. If the editor decides there is no rough consensus - for instance, because contributors point out significant issues with the EIP - they may close the PR and request that you fix the issues in the draft before trying again.
 
 # EIP Status Terms
+
 * **Draft** - an EIP that is undergoing rapid iteration and changes.
 * **Last Call** - an EIP that is done with its initial iteration and ready for review by a wide audience.
 * **Accepted** - a core EIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an EIP into their clients as part of a hard fork is not part of the EIP process. If such a decision is made, the EIP wil move to final.
@@ -32,3 +33,17 @@ When you believe your EIP is mature and ready to progress past the draft phase,
 # Preferred Citation Format
 
 The canonical URL for a EIP that has achieved draft status at any point is at https://eips.ethereum.org/. For example, the canonical URL for ERC-165 is https://eips.ethereum.org/EIPS/eip-165.
+
+# Validation
+
+EIPs must pass some validation tests.  The EIP repository ensures this by running tests using [html-proofer](https://rubygems.org/gems/html-proofer) and [eip_validator](https://rubygems.org/gems/eip_validator).
+
+It is possible to run the EIP validator locally:
+```
+gem install eip_validator
+eip_validator <INPUT_FILES>
+```
+
+# Automerger
+
+The EIP repository contains an "auto merge" feature to ease the workload for EIP editors.  If a change is made via a PR to a draft EIP, then the authors of the EIP can Github approve the change to have it auto-merged by the [eip-automerger](https://github.com/eip-automerger/automerger) bot.