From 50335e2be28356c7e8484378bd58539b4cb968c4 Mon Sep 17 00:00:00 2001 From: cdetrio Date: Fri, 17 May 2019 16:21:28 -0400 Subject: [PATCH 01/12] add EIP for fractional gas costs --- EIPS/eip-fractional_gas_costs.md | 113 +++++++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) create mode 100644 EIPS/eip-fractional_gas_costs.md diff --git a/EIPS/eip-fractional_gas_costs.md b/EIPS/eip-fractional_gas_costs.md new file mode 100644 index 0000000000000..d064414e17193 --- /dev/null +++ b/EIPS/eip-fractional_gas_costs.md @@ -0,0 +1,113 @@ +--- +eip: +title: Fractional gas costs for EVM opcodes +author: Casey Detrio (@cdetrio) +discussions-to: +status: Draft +type: Standards Track +category Core +created: 2019-05-17 +--- + +## Abstract +According to recent benchmarks, EVM opcodes for computation (ADD, SUB, MUL, etc.) are generally overpriced relative to opcodes for storage I/O (SLOAD, SSTORE, etc.). Currently the minimum gas cost is 1 (i.e. one unit of gas), and most computational opcodes have a cost near to 1 (e.g. 3, 5, or 8), so the range in possible cost reduction is limited. A new minimum unit of gas, called a "particle", which is a fraction of 1 gas, would expand the range of gas costs and thus enable reductions below the current minimum. + +## Motivation +The transaction capacity of an Ethereum block is determined by the gas cost of transactions relative to the block gas limit. One way to boost the transaction capacity is to raise the block gas limit. Unfortunately, raising the block gas limit would also increase the rate of state growth, unless the costs of state-expanding storage opcodes (SSTORE, CREATE, etc.) are simultaneously increased to the same proportion. Increasing the cost of storage opcodes may have adverse side effects, such as shifting the economic assumptions around gas fees of deployed contracts, or possibly breaking invariants in current contract executions (as mentioned in EIP-2035 [REF/LINK HERE], more research is needed on the potential effects of increasing the cost of storage opcodes). + +Another way to boost the transaction capacity of a block is to reduce the gas cost of transactions. Reducing the gas costs of computational opcodes while keeping the cost of storage opcodes the same, is effectively equivalent to raising the block gas limit and simultaneously increasing the cost of storage opcodes. However, reducing the cost of computational opcodes might avoid the adverse side effects of an increase in cost of storage opcodes (again, more research is needed on this topic). + +Currently, computational opcode costs are already too close to the minimum unit of 1 gas to achieve the large degree of cost reductions that recent benchmarks indicate would be needed to tune opcode gas costs to the performance of optimized EVM implementations. [TODO: REF/LINK TO EVM BENCHMARKS]. A smaller minimum unit called a "particle", which is a fraction of 1 gas, enables large cost reductions. + +## Specification + + +A new gas counter `particlesUsed` is added to the EVM, in addition to the existing gas counter `gasUsed`. The unit 1 gas is equal to 10000 particles (`PARTICLES_PER_GAS`). The `particlesUsed` counter is only increased for opcodes priced in particles (i.e. opcodes that cost less than 1 gas). If `particlesUsed` exceeds 1 gas, then 1 gas is added to `gasUsed` (and deducted from `particlesUsed`). + +Where the current gas logic looks like this: +``` +def vm_execute(ext, msg, code): + # Initialize stack, memory, program counter, etc + compustate = Compustate(gas=msg.gas) + codelen = len(code) + + while compustate.pc < codelen: + opcode = code[compustate.pc] + compustate.pc += 1 + + compustate.gasUsed += opcode.gas_fee + + # out of gas error + if compustate.gasUsed > compustate.gasLimit: + return vm_exception('OUT OF GAS') + + if op == 'STOP': + return peaceful_exit() + elif op == 'ADD': + stk.append(stk.pop() + stk.pop()) + elif op == 'SUB': + stk.append(stk.pop() - stk.pop()) + elif op == 'MUL': + stk.append(stk.pop() * stk.pop()) + +..... +``` + +The new gas logic using particles might look like this: +``` +PARTICLES_PER_GAS = 10000 + +def vm_execute(ext, msg, code): + # Initialize stack, memory, program counter, etc + compustate = Compustate(gas=msg.gas) + codelen = len(code) + + while compustate.pc < codelen: + opcode = code[compustate.pc] + compustate.pc += 1 + + if opcode.gas_fee: + compustate.gasUsed += opcode.gas_fee + elif opcode.particle_fee: + compustate.particlesUsed += opcode.particle_fee + if compustate.particlesUsed >= PARTICLES_PER_GAS: + # particlesUsed will be between 1 and 2 gas (over 10000 but under 20000) + compustate.gasUsed += 1 + # remainder stays in particle counter + compustate.particlesUsed = compustate.particlesUsed % PARTICLES_PER_GAS + + # out of gas error + if compustate.gasUsed > compustate.gasLimit: + return vm_exception('OUT OF GAS') + + if op == 'STOP': + return peaceful_exit() + elif op == 'ADD': + stk.append(stk.pop() + stk.pop()) + elif op == 'SUB': + stk.append(stk.pop() - stk.pop()) + elif op == 'MUL': + stk.append(stk.pop() * stk.pop()) + +..... +``` + +The above pseudocode is written for clarity. A more performant implementation might instead keep a single `gasUsed` counter, multiply opcode costs by 10000 and the `gasLimit` by 10000, and only compare the higher-order bits when checking if `gasUsed` is less than `gasLimit`. It may also be more performant to use a `PARTICLES_PER_GAS` ratio that is a power of 2 (such as 8192 or 16384) instead of 10000; the spec above is a draft and updates in response to feedback are expected. + +#### Opcode cost changes +Many computational opcodes will undergo a cost reduction, with new costs suggested by benchmark analyses. For example, the cost of DUP and SWAP are reduced from 3 gas to 3000 particles. The cost of `ADD` and `SUB` are reduced from 3 gas to 6000 particles. The cost of `MUL` is reduced from 5 gas to 5000 particles. + +## Rationale +Adoption of fractional gas costs should only be an implementation detail inside the EVM, and not alter the current user experience around transaction gas limits and block gas limits. The concept of `particles` need not be exposed to Ethereum users nor most contract authors, but only to EVM implementers and contract authors concerned with optimized gas usage. Furthermore, only the EVM logic for charging gas per opcode executed should be affected by this change. All other contexts dealing with gas and gas limits, such as block headers and transaction formats, should be unaffected. + +## Backwards Compatibility +This change is not backwards compatible and requires a hard fork to be activated. + +## Test Cases +TODO + +## Implementation +TODO + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 68b2d9eb44259adac189217f1abd3a943688bf5d Mon Sep 17 00:00:00 2001 From: cdetrio Date: Thu, 23 May 2019 20:56:40 -0400 Subject: [PATCH 02/12] use EIP number 2045, add references, discussion-to --- EIPS/eip-fractional_gas_costs.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-fractional_gas_costs.md b/EIPS/eip-fractional_gas_costs.md index d064414e17193..cae2d1d90c159 100644 --- a/EIPS/eip-fractional_gas_costs.md +++ b/EIPS/eip-fractional_gas_costs.md @@ -1,8 +1,8 @@ --- -eip: +eip: 2045 title: Fractional gas costs for EVM opcodes author: Casey Detrio (@cdetrio) -discussions-to: +discussions-to: https://ethereum-magicians.org/t/eip-2045-fractional-gas-costs/3311 status: Draft type: Standards Track category Core @@ -17,7 +17,7 @@ The transaction capacity of an Ethereum block is determined by the gas cost of t Another way to boost the transaction capacity of a block is to reduce the gas cost of transactions. Reducing the gas costs of computational opcodes while keeping the cost of storage opcodes the same, is effectively equivalent to raising the block gas limit and simultaneously increasing the cost of storage opcodes. However, reducing the cost of computational opcodes might avoid the adverse side effects of an increase in cost of storage opcodes (again, more research is needed on this topic). -Currently, computational opcode costs are already too close to the minimum unit of 1 gas to achieve the large degree of cost reductions that recent benchmarks indicate would be needed to tune opcode gas costs to the performance of optimized EVM implementations. [TODO: REF/LINK TO EVM BENCHMARKS]. A smaller minimum unit called a "particle", which is a fraction of 1 gas, enables large cost reductions. +Currently, computational opcode costs are already too close to the minimum unit of 1 gas to achieve the large degree of cost reductions that recent benchmarks[1](#evmbenchmarks) indicate would be needed to tune opcode gas costs to the performance of optimized EVM implementations. A smaller minimum unit called a "particle"[2](#particle), which is a fraction of 1 gas, would enable large cost reductions. ## Specification @@ -98,7 +98,7 @@ The above pseudocode is written for clarity. A more performant implementation mi Many computational opcodes will undergo a cost reduction, with new costs suggested by benchmark analyses. For example, the cost of DUP and SWAP are reduced from 3 gas to 3000 particles. The cost of `ADD` and `SUB` are reduced from 3 gas to 6000 particles. The cost of `MUL` is reduced from 5 gas to 5000 particles. ## Rationale -Adoption of fractional gas costs should only be an implementation detail inside the EVM, and not alter the current user experience around transaction gas limits and block gas limits. The concept of `particles` need not be exposed to Ethereum users nor most contract authors, but only to EVM implementers and contract authors concerned with optimized gas usage. Furthermore, only the EVM logic for charging gas per opcode executed should be affected by this change. All other contexts dealing with gas and gas limits, such as block headers and transaction formats, should be unaffected. +Adoption of fractional gas costs should only be an implementation detail inside the EVM, and not alter the current user experience around transaction gas limits and block gas limits. The concept of `particles` need not be exposed to Ethereum users nor most contract authors, but only to EVM implementers and contract developers concerned with optimized gas usage. Furthermore, only the EVM logic for charging gas per opcode executed should be affected by this change. All other contexts dealing with gas and gas limits, such as block headers and transaction formats, should be unaffected. ## Backwards Compatibility This change is not backwards compatible and requires a hard fork to be activated. @@ -109,5 +109,11 @@ TODO ## Implementation TODO +## References +1. https://github.com/ewasm/benchmarking + +2. The term "particle" was inspired by a proposal for [Ewasm gas costs](https://github.com/ewasm/design/blob/e77d8e3de42784f40a803a23f58ef06881142d9f/determining_wasm_gas_costs.md). + + ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 5dff82f4c1c216faabe440aa01d095ac9708817d Mon Sep 17 00:00:00 2001 From: cdetrio Date: Thu, 23 May 2019 21:03:44 -0400 Subject: [PATCH 03/12] add EIP-2045 to Istanbul --- EIPS/eip-1679.md | 1 + EIPS/{eip-fractional_gas_costs.md => eip-2045.md} | 0 2 files changed, 1 insertion(+) rename EIPS/{eip-fractional_gas_costs.md => eip-2045.md} (100%) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index c7e99985869ec..a0f31ac5ff74b 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -63,6 +63,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - 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-2045](https://eips.ethereum.org/EIPS/eip-2045): Fractional gas costs for EVM opcodes - [EIP-2046](https://eips.ethereum.org/EIPS/eip-2046): Reduced gas cost for static calls made to precompiles ## Timeline diff --git a/EIPS/eip-fractional_gas_costs.md b/EIPS/eip-2045.md similarity index 100% rename from EIPS/eip-fractional_gas_costs.md rename to EIPS/eip-2045.md From 5ad6b935aecc619e3ada0d53273b3443ef2540ad Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 24 May 2019 02:17:05 +0100 Subject: [PATCH 04/12] Formatting --- EIPS/eip-2045.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-2045.md b/EIPS/eip-2045.md index cae2d1d90c159..8542ba866e44a 100644 --- a/EIPS/eip-2045.md +++ b/EIPS/eip-2045.md @@ -10,10 +10,10 @@ created: 2019-05-17 --- ## Abstract -According to recent benchmarks, EVM opcodes for computation (ADD, SUB, MUL, etc.) are generally overpriced relative to opcodes for storage I/O (SLOAD, SSTORE, etc.). Currently the minimum gas cost is 1 (i.e. one unit of gas), and most computational opcodes have a cost near to 1 (e.g. 3, 5, or 8), so the range in possible cost reduction is limited. A new minimum unit of gas, called a "particle", which is a fraction of 1 gas, would expand the range of gas costs and thus enable reductions below the current minimum. +According to recent benchmarks, EVM opcodes for computation (`ADD`, `SUB`, `MUL`, etc.) are generally overpriced relative to opcodes for storage I/O (`SLOAD`, `SSTORE`, etc.). Currently the minimum gas cost is 1 (i.e. one unit of gas), and most computational opcodes have a cost near to 1 (e.g. 3, 5, or 8), so the range in possible cost reduction is limited. A new minimum unit of gas, called a "particle", which is a fraction of 1 gas, would expand the range of gas costs and thus enable reductions below the current minimum. ## Motivation -The transaction capacity of an Ethereum block is determined by the gas cost of transactions relative to the block gas limit. One way to boost the transaction capacity is to raise the block gas limit. Unfortunately, raising the block gas limit would also increase the rate of state growth, unless the costs of state-expanding storage opcodes (SSTORE, CREATE, etc.) are simultaneously increased to the same proportion. Increasing the cost of storage opcodes may have adverse side effects, such as shifting the economic assumptions around gas fees of deployed contracts, or possibly breaking invariants in current contract executions (as mentioned in EIP-2035 [REF/LINK HERE], more research is needed on the potential effects of increasing the cost of storage opcodes). +The transaction capacity of an Ethereum block is determined by the gas cost of transactions relative to the block gas limit. One way to boost the transaction capacity is to raise the block gas limit. Unfortunately, raising the block gas limit would also increase the rate of state growth, unless the costs of state-expanding storage opcodes (`SSTORE`, `CREATE`, etc.) are simultaneously increased to the same proportion. Increasing the cost of storage opcodes may have adverse side effects, such as shifting the economic assumptions around gas fees of deployed contracts, or possibly breaking invariants in current contract executions (as mentioned in EIP-2035 [REF/LINK HERE], more research is needed on the potential effects of increasing the cost of storage opcodes). Another way to boost the transaction capacity of a block is to reduce the gas cost of transactions. Reducing the gas costs of computational opcodes while keeping the cost of storage opcodes the same, is effectively equivalent to raising the block gas limit and simultaneously increasing the cost of storage opcodes. However, reducing the cost of computational opcodes might avoid the adverse side effects of an increase in cost of storage opcodes (again, more research is needed on this topic). From b97a1105d1f62faa0c8194a75cd4d547f0502ebd Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 24 May 2019 02:24:34 +0100 Subject: [PATCH 05/12] Add ewasm to rationale --- EIPS/eip-2045.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/EIPS/eip-2045.md b/EIPS/eip-2045.md index 8542ba866e44a..437e6e6b261c3 100644 --- a/EIPS/eip-2045.md +++ b/EIPS/eip-2045.md @@ -100,6 +100,10 @@ Many computational opcodes will undergo a cost reduction, with new costs suggest ## Rationale Adoption of fractional gas costs should only be an implementation detail inside the EVM, and not alter the current user experience around transaction gas limits and block gas limits. The concept of `particles` need not be exposed to Ethereum users nor most contract authors, but only to EVM implementers and contract developers concerned with optimized gas usage. Furthermore, only the EVM logic for charging gas per opcode executed should be affected by this change. All other contexts dealing with gas and gas limits, such as block headers and transaction formats, should be unaffected. +### Ewasm + +Particles were first introduced for Ewasm, motivated by keeping compatibility with the EVM, while accounting for the lower cost of the instructions. With particles, state querying or changing operations (e.g. `SSTORE`, `SLOAD`, `BALANCE`, etc.) can keep the same gas costs. Interoperability between Ewasm and EVM contracts is simple, as the particles are hidden from EVM. + ## Backwards Compatibility This change is not backwards compatible and requires a hard fork to be activated. From 9b81a449990636469b267f63b7e5484762ec6e11 Mon Sep 17 00:00:00 2001 From: cdetrio Date: Fri, 24 May 2019 08:38:09 -0400 Subject: [PATCH 06/12] link to eip-2035, edit for clarity --- EIPS/eip-2045.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-2045.md b/EIPS/eip-2045.md index 437e6e6b261c3..37422ae159e17 100644 --- a/EIPS/eip-2045.md +++ b/EIPS/eip-2045.md @@ -13,15 +13,13 @@ created: 2019-05-17 According to recent benchmarks, EVM opcodes for computation (`ADD`, `SUB`, `MUL`, etc.) are generally overpriced relative to opcodes for storage I/O (`SLOAD`, `SSTORE`, etc.). Currently the minimum gas cost is 1 (i.e. one unit of gas), and most computational opcodes have a cost near to 1 (e.g. 3, 5, or 8), so the range in possible cost reduction is limited. A new minimum unit of gas, called a "particle", which is a fraction of 1 gas, would expand the range of gas costs and thus enable reductions below the current minimum. ## Motivation -The transaction capacity of an Ethereum block is determined by the gas cost of transactions relative to the block gas limit. One way to boost the transaction capacity is to raise the block gas limit. Unfortunately, raising the block gas limit would also increase the rate of state growth, unless the costs of state-expanding storage opcodes (`SSTORE`, `CREATE`, etc.) are simultaneously increased to the same proportion. Increasing the cost of storage opcodes may have adverse side effects, such as shifting the economic assumptions around gas fees of deployed contracts, or possibly breaking invariants in current contract executions (as mentioned in EIP-2035 [REF/LINK HERE], more research is needed on the potential effects of increasing the cost of storage opcodes). +The transaction capacity of an Ethereum block is determined by the gas cost of transactions relative to the block gas limit. One way to boost the transaction capacity is to raise the block gas limit. Unfortunately, raising the block gas limit would also increase the rate of state growth, unless the costs of state-expanding storage opcodes (`SSTORE`, `CREATE`, etc.) are simultaneously increased to the same proportion. Increasing the cost of storage opcodes may have adverse side effects, such as shifting the economic assumptions around gas fees of deployed contracts, or possibly breaking invariants in current contract executions (as mentioned in [EIP-2035](https://eips.ethereum.org/EIPS/eip-2035), more research is needed on the potential effects of increasing the cost of storage opcodes). Another way to boost the transaction capacity of a block is to reduce the gas cost of transactions. Reducing the gas costs of computational opcodes while keeping the cost of storage opcodes the same, is effectively equivalent to raising the block gas limit and simultaneously increasing the cost of storage opcodes. However, reducing the cost of computational opcodes might avoid the adverse side effects of an increase in cost of storage opcodes (again, more research is needed on this topic). Currently, computational opcode costs are already too close to the minimum unit of 1 gas to achieve the large degree of cost reductions that recent benchmarks[1](#evmbenchmarks) indicate would be needed to tune opcode gas costs to the performance of optimized EVM implementations. A smaller minimum unit called a "particle"[2](#particle), which is a fraction of 1 gas, would enable large cost reductions. ## Specification - - A new gas counter `particlesUsed` is added to the EVM, in addition to the existing gas counter `gasUsed`. The unit 1 gas is equal to 10000 particles (`PARTICLES_PER_GAS`). The `particlesUsed` counter is only increased for opcodes priced in particles (i.e. opcodes that cost less than 1 gas). If `particlesUsed` exceeds 1 gas, then 1 gas is added to `gasUsed` (and deducted from `particlesUsed`). Where the current gas logic looks like this: @@ -92,7 +90,7 @@ def vm_execute(ext, msg, code): ..... ``` -The above pseudocode is written for clarity. A more performant implementation might instead keep a single `gasUsed` counter, multiply opcode costs by 10000 and the `gasLimit` by 10000, and only compare the higher-order bits when checking if `gasUsed` is less than `gasLimit`. It may also be more performant to use a `PARTICLES_PER_GAS` ratio that is a power of 2 (such as 8192 or 16384) instead of 10000; the spec above is a draft and updates in response to feedback are expected. +The above pseudocode is written for clarity. A more performant implementation might instead keep a single `particlesUsed` counter by multiplying opcode gas costs by 10000 and the `gasLimit` by 10000, and convert particles back to gas with `ceil(particlesUsed / PARTICLES_PER_GAS)` at the end of execution. It may also be more performant to use a `PARTICLES_PER_GAS` ratio that is a power of 2 (such as 8192 or 16384) instead of 10000; the spec above is a draft and updates in response to feedback are expected. #### Opcode cost changes Many computational opcodes will undergo a cost reduction, with new costs suggested by benchmark analyses. For example, the cost of DUP and SWAP are reduced from 3 gas to 3000 particles. The cost of `ADD` and `SUB` are reduced from 3 gas to 6000 particles. The cost of `MUL` is reduced from 5 gas to 5000 particles. From cc69be90de91a7cf8c7328dcc385d9ed96233932 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 24 May 2019 02:41:05 +0100 Subject: [PATCH 07/12] Clarify cost reduction examples --- EIPS/eip-2045.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2045.md b/EIPS/eip-2045.md index 37422ae159e17..aab1ba0992394 100644 --- a/EIPS/eip-2045.md +++ b/EIPS/eip-2045.md @@ -93,7 +93,7 @@ def vm_execute(ext, msg, code): The above pseudocode is written for clarity. A more performant implementation might instead keep a single `particlesUsed` counter by multiplying opcode gas costs by 10000 and the `gasLimit` by 10000, and convert particles back to gas with `ceil(particlesUsed / PARTICLES_PER_GAS)` at the end of execution. It may also be more performant to use a `PARTICLES_PER_GAS` ratio that is a power of 2 (such as 8192 or 16384) instead of 10000; the spec above is a draft and updates in response to feedback are expected. #### Opcode cost changes -Many computational opcodes will undergo a cost reduction, with new costs suggested by benchmark analyses. For example, the cost of DUP and SWAP are reduced from 3 gas to 3000 particles. The cost of `ADD` and `SUB` are reduced from 3 gas to 6000 particles. The cost of `MUL` is reduced from 5 gas to 5000 particles. +Many computational opcodes will undergo a cost reduction, with new costs suggested by benchmark analyses. For example, the cost of `DUP` and `SWAP` are reduced from 3 gas to 3000 particles (i.e. 0.3 gas). The cost of `ADD` and `SUB` are reduced from 3 gas to 6000 particles. The cost of `MUL` is reduced from 5 gas to 5000 particles (i.e. 0.5 gas). ## Rationale Adoption of fractional gas costs should only be an implementation detail inside the EVM, and not alter the current user experience around transaction gas limits and block gas limits. The concept of `particles` need not be exposed to Ethereum users nor most contract authors, but only to EVM implementers and contract developers concerned with optimized gas usage. Furthermore, only the EVM logic for charging gas per opcode executed should be affected by this change. All other contexts dealing with gas and gas limits, such as block headers and transaction formats, should be unaffected. From a59fb8a96f21d5b0cf427e7ef1d4d2ebcd22c1ae Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Fri, 24 May 2019 02:50:52 +0100 Subject: [PATCH 08/12] Clarify the increase of particles --- EIPS/eip-2045.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2045.md b/EIPS/eip-2045.md index aab1ba0992394..7cfca2b2ad495 100644 --- a/EIPS/eip-2045.md +++ b/EIPS/eip-2045.md @@ -20,7 +20,7 @@ Another way to boost the transaction capacity of a block is to reduce the gas co Currently, computational opcode costs are already too close to the minimum unit of 1 gas to achieve the large degree of cost reductions that recent benchmarks[1](#evmbenchmarks) indicate would be needed to tune opcode gas costs to the performance of optimized EVM implementations. A smaller minimum unit called a "particle"[2](#particle), which is a fraction of 1 gas, would enable large cost reductions. ## Specification -A new gas counter `particlesUsed` is added to the EVM, in addition to the existing gas counter `gasUsed`. The unit 1 gas is equal to 10000 particles (`PARTICLES_PER_GAS`). The `particlesUsed` counter is only increased for opcodes priced in particles (i.e. opcodes that cost less than 1 gas). If `particlesUsed` exceeds 1 gas, then 1 gas is added to `gasUsed` (and deducted from `particlesUsed`). +A new gas counter `particlesUsed` is added to the EVM, in addition to the existing gas counter `gasUsed`. The unit 1 gas is equal to 10000 particles (`PARTICLES_PER_GAS`). The `particlesUsed` counter is only increased for opcodes priced in particles (i.e. opcodes that cost less than 1 gas). If increasing `particlesUsed` results in an excess of 1 gas, then 1 gas is added to `gasUsed` (and deducted from `particlesUsed`). Where the current gas logic looks like this: ``` From 6b2307b521ee6fefee5ce7f95beca0db81f766a4 Mon Sep 17 00:00:00 2001 From: cdetrio Date: Fri, 24 May 2019 08:48:24 -0400 Subject: [PATCH 09/12] add reference to eip-2035 --- EIPS/eip-2045.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-2045.md b/EIPS/eip-2045.md index 7cfca2b2ad495..fc73b84d8a3bd 100644 --- a/EIPS/eip-2045.md +++ b/EIPS/eip-2045.md @@ -13,11 +13,11 @@ created: 2019-05-17 According to recent benchmarks, EVM opcodes for computation (`ADD`, `SUB`, `MUL`, etc.) are generally overpriced relative to opcodes for storage I/O (`SLOAD`, `SSTORE`, etc.). Currently the minimum gas cost is 1 (i.e. one unit of gas), and most computational opcodes have a cost near to 1 (e.g. 3, 5, or 8), so the range in possible cost reduction is limited. A new minimum unit of gas, called a "particle", which is a fraction of 1 gas, would expand the range of gas costs and thus enable reductions below the current minimum. ## Motivation -The transaction capacity of an Ethereum block is determined by the gas cost of transactions relative to the block gas limit. One way to boost the transaction capacity is to raise the block gas limit. Unfortunately, raising the block gas limit would also increase the rate of state growth, unless the costs of state-expanding storage opcodes (`SSTORE`, `CREATE`, etc.) are simultaneously increased to the same proportion. Increasing the cost of storage opcodes may have adverse side effects, such as shifting the economic assumptions around gas fees of deployed contracts, or possibly breaking invariants in current contract executions (as mentioned in [EIP-2035](https://eips.ethereum.org/EIPS/eip-2035), more research is needed on the potential effects of increasing the cost of storage opcodes). +The transaction capacity of an Ethereum block is determined by the gas cost of transactions relative to the block gas limit. One way to boost the transaction capacity is to raise the block gas limit. Unfortunately, raising the block gas limit would also increase the rate of state growth, unless the costs of state-expanding storage opcodes (`SSTORE`, `CREATE`, etc.) are simultaneously increased to the same proportion. Increasing the cost of storage opcodes may have adverse side effects, such as shifting the economic assumptions around gas fees of deployed contracts, or possibly breaking invariants in current contract executions (as mentioned in [EIP-2035](https://eips.ethereum.org/EIPS/eip-2035)[1](#eip2035), more research is needed on the potential effects of increasing the cost of storage opcodes). Another way to boost the transaction capacity of a block is to reduce the gas cost of transactions. Reducing the gas costs of computational opcodes while keeping the cost of storage opcodes the same, is effectively equivalent to raising the block gas limit and simultaneously increasing the cost of storage opcodes. However, reducing the cost of computational opcodes might avoid the adverse side effects of an increase in cost of storage opcodes (again, more research is needed on this topic). -Currently, computational opcode costs are already too close to the minimum unit of 1 gas to achieve the large degree of cost reductions that recent benchmarks[1](#evmbenchmarks) indicate would be needed to tune opcode gas costs to the performance of optimized EVM implementations. A smaller minimum unit called a "particle"[2](#particle), which is a fraction of 1 gas, would enable large cost reductions. +Currently, computational opcode costs are already too close to the minimum unit of 1 gas to achieve the large degree of cost reductions that recent benchmarks[2](#evmbenchmarks) indicate would be needed to tune opcode gas costs to the performance of optimized EVM implementations. A smaller minimum unit called a "particle", which is a fraction of 1 gas, would enable large cost reductions. ## Specification A new gas counter `particlesUsed` is added to the EVM, in addition to the existing gas counter `gasUsed`. The unit 1 gas is equal to 10000 particles (`PARTICLES_PER_GAS`). The `particlesUsed` counter is only increased for opcodes priced in particles (i.e. opcodes that cost less than 1 gas). If increasing `particlesUsed` results in an excess of 1 gas, then 1 gas is added to `gasUsed` (and deducted from `particlesUsed`). @@ -100,7 +100,7 @@ Adoption of fractional gas costs should only be an implementation detail inside ### Ewasm -Particles were first introduced for Ewasm, motivated by keeping compatibility with the EVM, while accounting for the lower cost of the instructions. With particles, state querying or changing operations (e.g. `SSTORE`, `SLOAD`, `BALANCE`, etc.) can keep the same gas costs. Interoperability between Ewasm and EVM contracts is simple, as the particles are hidden from EVM. +Particles were first introduced for Ewasm[3](#particle), motivated by keeping compatibility with the EVM, while accounting for the lower cost of the instructions. With particles, state querying or changing operations (e.g. `SSTORE`, `SLOAD`, `BALANCE`, etc.) can keep the same gas costs. Interoperability between Ewasm and EVM contracts is simple, as the particles are hidden from EVM. ## Backwards Compatibility This change is not backwards compatible and requires a hard fork to be activated. @@ -112,10 +112,11 @@ TODO TODO ## References -1. https://github.com/ewasm/benchmarking +1. [EIP-2035](https://eips.ethereum.org/EIPS/eip-2035): Stateless Clients - Repricing SLOAD and SSTORE to pay for block proofs -2. The term "particle" was inspired by a proposal for [Ewasm gas costs](https://github.com/ewasm/design/blob/e77d8e3de42784f40a803a23f58ef06881142d9f/determining_wasm_gas_costs.md). +2. https://github.com/ewasm/benchmarking +3. The term "particle" was inspired by a proposal for [Ewasm gas costs](https://github.com/ewasm/design/blob/e77d8e3de42784f40a803a23f58ef06881142d9f/determining_wasm_gas_costs.md). ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 7cea392d593d6e9aa0649b301ff510ccdf9279ad Mon Sep 17 00:00:00 2001 From: cdetrio Date: Fri, 24 May 2019 08:49:09 -0400 Subject: [PATCH 10/12] add axic as author --- EIPS/eip-2045.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2045.md b/EIPS/eip-2045.md index fc73b84d8a3bd..04d6c1117b71b 100644 --- a/EIPS/eip-2045.md +++ b/EIPS/eip-2045.md @@ -1,7 +1,7 @@ --- eip: 2045 title: Fractional gas costs for EVM opcodes -author: Casey Detrio (@cdetrio) +author: Casey Detrio (@cdetrio), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2045-fractional-gas-costs/3311 status: Draft type: Standards Track From c28074bca0d0c2dbdbb0101b79316b8c0841ef88 Mon Sep 17 00:00:00 2001 From: cdetrio Date: Wed, 29 May 2019 09:47:37 -0400 Subject: [PATCH 11/12] rename title to "particle gas costs", edit ewasm section --- EIPS/eip-1679.md | 2 +- EIPS/eip-2045.md | 7 +++---- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-1679.md b/EIPS/eip-1679.md index a0f31ac5ff74b..83d97df28b700 100644 --- a/EIPS/eip-1679.md +++ b/EIPS/eip-1679.md @@ -63,7 +63,7 @@ This meta-EIP specifies the changes included in the Ethereum hardfork named Ista - 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-2045](https://eips.ethereum.org/EIPS/eip-2045): Fractional gas costs for EVM opcodes +- [EIP-2045](https://eips.ethereum.org/EIPS/eip-2045): Particle gas costs for EVM opcodes - [EIP-2046](https://eips.ethereum.org/EIPS/eip-2046): Reduced gas cost for static calls made to precompiles ## Timeline diff --git a/EIPS/eip-2045.md b/EIPS/eip-2045.md index 04d6c1117b71b..77858f5f16e22 100644 --- a/EIPS/eip-2045.md +++ b/EIPS/eip-2045.md @@ -1,6 +1,6 @@ --- eip: 2045 -title: Fractional gas costs for EVM opcodes +title: Particle gas costs for EVM opcodes author: Casey Detrio (@cdetrio), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2045-fractional-gas-costs/3311 status: Draft @@ -17,7 +17,7 @@ The transaction capacity of an Ethereum block is determined by the gas cost of t Another way to boost the transaction capacity of a block is to reduce the gas cost of transactions. Reducing the gas costs of computational opcodes while keeping the cost of storage opcodes the same, is effectively equivalent to raising the block gas limit and simultaneously increasing the cost of storage opcodes. However, reducing the cost of computational opcodes might avoid the adverse side effects of an increase in cost of storage opcodes (again, more research is needed on this topic). -Currently, computational opcode costs are already too close to the minimum unit of 1 gas to achieve the large degree of cost reductions that recent benchmarks[2](#evmbenchmarks) indicate would be needed to tune opcode gas costs to the performance of optimized EVM implementations. A smaller minimum unit called a "particle", which is a fraction of 1 gas, would enable large cost reductions. +Currently, computational opcode costs are already too close to the minimum unit of 1 gas to achieve the large degree of cost reductions that recent benchmarks[2](#evmbenchmarks) indicate would be needed to tune opcode gas costs to the performance of optimized EVM implementations. A smaller minimum unit called a "particle", which is a fraction (or subdivision) of 1 gas, would enable large cost reductions. ## Specification A new gas counter `particlesUsed` is added to the EVM, in addition to the existing gas counter `gasUsed`. The unit 1 gas is equal to 10000 particles (`PARTICLES_PER_GAS`). The `particlesUsed` counter is only increased for opcodes priced in particles (i.e. opcodes that cost less than 1 gas). If increasing `particlesUsed` results in an excess of 1 gas, then 1 gas is added to `gasUsed` (and deducted from `particlesUsed`). @@ -99,8 +99,7 @@ Many computational opcodes will undergo a cost reduction, with new costs suggest Adoption of fractional gas costs should only be an implementation detail inside the EVM, and not alter the current user experience around transaction gas limits and block gas limits. The concept of `particles` need not be exposed to Ethereum users nor most contract authors, but only to EVM implementers and contract developers concerned with optimized gas usage. Furthermore, only the EVM logic for charging gas per opcode executed should be affected by this change. All other contexts dealing with gas and gas limits, such as block headers and transaction formats, should be unaffected. ### Ewasm - -Particles were first introduced for Ewasm[3](#particle), motivated by keeping compatibility with the EVM, while accounting for the lower cost of the instructions. With particles, state querying or changing operations (e.g. `SSTORE`, `SLOAD`, `BALANCE`, etc.) can keep the same gas costs. Interoperability between Ewasm and EVM contracts is simple, as the particles are hidden from EVM. +The term "particles" was first introduced for Ewasm[3](#particle) to enable gas accounting for low cost wasm instructions, while remaining compatible with EVM gas costs. This EIP proposes introducing particles as a new minimum gas unit for EVM opcodes, and is not related to Ewasm. ## Backwards Compatibility This change is not backwards compatible and requires a hard fork to be activated. From 967f59271655d07dcbc9c94369eab9db16ea02e6 Mon Sep 17 00:00:00 2001 From: cdetrio Date: Thu, 30 May 2019 11:04:50 -0400 Subject: [PATCH 12/12] fix header --- EIPS/eip-2045.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2045.md b/EIPS/eip-2045.md index 77858f5f16e22..9836b9dbbaa61 100644 --- a/EIPS/eip-2045.md +++ b/EIPS/eip-2045.md @@ -5,7 +5,7 @@ author: Casey Detrio (@cdetrio), Alex Beregszaszi (@axic) discussions-to: https://ethereum-magicians.org/t/eip-2045-fractional-gas-costs/3311 status: Draft type: Standards Track -category Core +category: Core created: 2019-05-17 ---