From 0f98e038fd346ac91708c4ad5fc78713bcab9a5b Mon Sep 17 00:00:00 2001 From: econoar Date: Mon, 29 Apr 2019 01:20:21 -0500 Subject: [PATCH 01/13] EIP-1559: Fee market change for ETH 1.0 chain (#1943) --- EIPS/eip-1559.md | 74 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 EIPS/eip-1559.md diff --git a/EIPS/eip-1559.md b/EIPS/eip-1559.md new file mode 100644 index 0000000000000..c91120dcfc998 --- /dev/null +++ b/EIPS/eip-1559.md @@ -0,0 +1,74 @@ +--- +eip: 1559 +title: Fee market change for ETH 1.0 chain +authors: 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: Standard +category: Core +created: 2019-04-13 +--- + + + +## Simple Summary + +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 + +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 + +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 + +**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 + + + +## Implementation + + + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 4d8e8fa46edc0841ede1681c6f589f929c2a221e Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Mon, 29 Apr 2019 07:36:55 +0100 Subject: [PATCH 02/13] Automatically merged updates to draft EIP(s) 1884 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 --- EIPS/eip-1884.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-1884.md b/EIPS/eip-1884.md index 1a1f64dae9a9e..19faa3578d7cd 100644 --- a/EIPS/eip-1884.md +++ b/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. From 31a12ca4ccdec35f2c6ea72c012ca7bd9e52829b Mon Sep 17 00:00:00 2001 From: Nick Savers Date: Mon, 29 Apr 2019 08:41:58 +0200 Subject: [PATCH 03/13] Fix authors and type-fields in eip-1559.md (#1974) --- EIPS/eip-1559.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-1559.md b/EIPS/eip-1559.md index c91120dcfc998..4dec83e889355 100644 --- a/EIPS/eip-1559.md +++ b/EIPS/eip-1559.md @@ -1,10 +1,10 @@ --- eip: 1559 title: Fee market change for ETH 1.0 chain -authors: Vitalik Buterin (@vbuterin), Eric Conner (@econoar) +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: Standard +type: Standards Track category: Core created: 2019-04-13 --- From c3e063c8ffb4b1c3ba5737f898aea70aad47c183 Mon Sep 17 00:00:00 2001 From: Martin Holst Swende Date: Mon, 29 Apr 2019 09:49:36 +0200 Subject: [PATCH 04/13] Automatically merged updates to draft EIP(s) 1679 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 --- EIPS/eip-1679.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index f363c13a9b725..52e4f8967fdb7 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -31,6 +31,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [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-1702](https://eips.ethereum.org/EIPS/eip-1702): Generalized account versioning scheme +- [EIP-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes ## Timeline From e1ed3eb66f4ff9e519b3904d8c29fde0d180ce75 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pawe=C5=82=20Bylica?= Date: Mon, 29 Apr 2019 15:42:41 +0200 Subject: [PATCH 05/13] Automatically merged updates to draft EIP(s) 1344 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 --- EIPS/eip-1344.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-1344.md b/EIPS/eip-1344.md index 57f89c653434b..1bea3780d6b3c 100644 --- a/EIPS/eip-1344.md +++ b/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. From 86a1620c4abea3012787b7b45070d0eb2f106441 Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Mon, 29 Apr 2019 09:38:22 -0600 Subject: [PATCH 06/13] Automatically merged updates to draft EIP(s) 1679 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 --- EIPS/eip-1679.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index 52e4f8967fdb7..7e27d6490a492 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -28,6 +28,12 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista ### Proposed EIPs +- [EIP-1057](https://eips.ethereum.org/EIPS/eip-1344): 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-1702](https://eips.ethereum.org/EIPS/eip-1702): Generalized account versioning scheme From 09e56171a8f64ac21c5a11c1a764332e693d96bb Mon Sep 17 00:00:00 2001 From: Jacques Dafflon Date: Mon, 29 Apr 2019 23:52:54 +0200 Subject: [PATCH 07/13] Automatically merged updates to draft EIP(s) 777 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 --- EIPS/eip-777.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-777.md b/EIPS/eip-777.md index c4d54cdc01243..460482f2c61b6 100644 --- a/EIPS/eip-777.md +++ b/EIPS/eip-777.md @@ -4,7 +4,7 @@ title: ERC777 Token Standard author: Jacques Dafflon , Jordi Baylina , Thomas Shababi 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 From 72fa017d2f43b586fe029b8f54eb79778a26a292 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 30 Apr 2019 09:45:06 +0100 Subject: [PATCH 08/13] Automatically merged updates to draft EIP(s) 1679 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 --- EIPS/eip-1679.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index 7e27d6490a492..a6f9bd680e882 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -28,7 +28,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista ### Proposed EIPs -- [EIP-1057](https://eips.ethereum.org/EIPS/eip-1344): ProgPoW, a Programmatic +- [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), From 132ef7be628e4eb73c16f95e23f211f000e1449b Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 30 Apr 2019 10:27:35 +0100 Subject: [PATCH 09/13] Automatically merged updates to draft EIP(s) 1679 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 --- EIPS/eip-1679.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index a6f9bd680e882..f29042ca3697f 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -36,6 +36,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista 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-1884](https://eips.ethereum.org/EIPS/eip-1884): Repricing for trie-size-dependent opcodes From 71fdaa7828be5c0c14f27e3af6839a7f98f658d2 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 30 Apr 2019 21:46:14 +0100 Subject: [PATCH 10/13] Remove obsolete layer field (#1978) --- EIPS/eip-4.md | 1 - EIPS/eip-6.md | 1 - 2 files changed, 2 deletions(-) diff --git a/EIPS/eip-4.md b/EIPS/eip-4.md index 7527271265a52..666436bc8caba 100644 --- a/EIPS/eip-4.md +++ b/EIPS/eip-4.md @@ -1,6 +1,5 @@ --- eip: 4 -layer: Process title: EIP Classification author: Joseph Chow status: Draft diff --git a/EIPS/eip-6.md b/EIPS/eip-6.md index ea1b1032d5946..3e097521d4d3f 100644 --- a/EIPS/eip-6.md +++ b/EIPS/eip-6.md @@ -5,7 +5,6 @@ author: Hudson Jameson status: Final type: Standards Track category: Interface -layer: Applications created: 2015-11-22 --- From f4cdc2313c4ee031efa6bddf21387d92a6b5629b Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 30 Apr 2019 21:46:40 +0100 Subject: [PATCH 11/13] Document eip_validator and eip-automerger (#1977) --- README.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/README.md b/README.md index c313bcde2265c..03278d567ae9d 100644 --- a/README.md +++ b/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 +``` + +# 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. From c36b30176e37c55ab845b10bc7c9523f9e04d1e7 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 30 Apr 2019 21:54:20 +0100 Subject: [PATCH 12/13] EIP-1803: Rename opcodes for clarity (#1803) --- EIPS/eip-1803.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 EIPS/eip-1803.md diff --git a/EIPS/eip-1803.md b/EIPS/eip-1803.md new file mode 100644 index 0000000000000..45e19a2ae0141 --- /dev/null +++ b/EIPS/eip-1803.md @@ -0,0 +1,40 @@ +--- +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 + +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/). From bda2a4f723080b68503fe6ecf318551999ac6818 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Tue, 30 Apr 2019 22:25:25 +0100 Subject: [PATCH 13/13] Automatically merged updates to draft EIP(s) 1679, 1803 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 --- EIPS/eip-1679.md | 1 + EIPS/eip-1803.md | 1 + 2 files changed, 2 insertions(+) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index f29042ca3697f..dee8b7949aa26 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -38,6 +38,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - [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 diff --git a/EIPS/eip-1803.md b/EIPS/eip-1803.md index 45e19a2ae0141..303879c30725e 100644 --- a/EIPS/eip-1803.md +++ b/EIPS/eip-1803.md @@ -33,6 +33,7 @@ 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