Create EIP 2542 - TXGASLIMIT, CALLGASLIMIT, TXGASREFUND opcodes

Author: forshtat

EIPS/eip-2542.md

@@ -0,0 +1,72 @@
+---
+eip: 2542
+title: New opcodes TXGASLIMIT, CALLGASLIMIT, TXGASREFUND
+author: Alex Forshtat <[email protected]>
+discussions-to: https://github.com/ethereum/EIPs/pull/2542
+status: Draft
+type: Standards Track
+category: Core
+created: 2020-02-29
+---
+
+<!--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.-->
+A mechanism to allow smart contracts to access information on gas limits and gas refunds for the current transaction and execution frame.
+
+## Abstract
+<!--A short (~200 word) description of the technical issue being addressed.-->
+Currently, there is an existing opcode `0x45 GASLIMIT` that provides access to the block gas limit. While this information may be useful in some cases, it is probably not a value that smart contract developers may be concerned about. The opcode `0x5a GAS` provides the remaining gas, not the initial one. Also it is worth noting how existing `0x32 ORIGIN`, `0x33 CALLER`,`0x34 CALLVALUE` and `0x3a	GASPRICE` opcodes set a pattern of having access to both the transacition and current execution frame state.
+TBD: as 0x30 opcode range is exhausted, the proposed opcodes can be added to 0x50 range, or a new range can be added.
+
+## 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.-->
+As concepts of relaying, meta-transactions, gas fees and account abstraction gain popularity, it becomes critical for some contracts to be able to track gas expenditure with absolute precision. Without access to this data on an EVM level, such contracts resort to approximation, mimicking EVM logic on chain, and some use-cases even become infeasible.
+
+## 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)).-->
+
+If block.number >= TBD, add three new opcodes:
+
+TXGASLIMIT: 0x5c
+
+Pushes the gas limit of the entire transaction onto the stack. Gas costs: 2 (same as `GASLIMIT`)
+
+CALLGASLIMIT: 0x5d
+
+Pushes the gas limit of the current execution frame onto the stack. Gas costs: 2 (same as `GASLIMIT`)
+
+TXGASREFUND: 0x5e
+
+Pushes the value of the gas refund counter of the entire transaction onto the stack. Gas costs: 2 (same as `GASLIMIT`)
+
+Also, consider renaming `0x45 GASLIMIT` to `BLOCKGASLIMIT` to avoid confusion.
+
+## Rationale
+<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+Consider a solidity smart contract that wants to emit an event like that: 
+```
+event MyEvent(gasUsed, gasRefunded);
+```
+
+It is absolutely not possible with the current EVM. With a proposed changes, using a pseudo-Solidity syntax, this information would be easily available:
+```
+function keepTrackOfGas(string memory message, uint256 number) public {
+	uint256 initRefundCounter = tx.gasRefund;
+	this.storageNumber = number;
+	emit MyEvent(tx.gasLimit - gasleft(), initRefundCounter - tx.gasRefund);
+}
+```
+The state-of-the-art solution, at least for the `gasUsed` problem, is to access 'gasleft()' as the first line of your smart contract, but it can only provide some part of the expenses. Note how variable transaction input size means the gas used by the transaction depends on number of zero and non-zero bytes of input, as well `GTXDATANONZERO`. Another issue is that Solidity handles `public` methods by loading the entire input from `calldata` to `memory`, spending an unpredictable amount of gas. And, obviously, gas refund counter is completely unavailble.
+
+## Backwards Compatibility
+<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
+This proposal introduces three new opcodes and renames an existing one, but stays fully backwards compatible apart from that.
+
+## 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.-->
+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/).