You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
16
-
A mechanism to allow smart contracts to access information on gas limits and gas refunds for the current transaction and execution frame.
16
+
A mechanism to allow smart contracts to access information on gas limits for the current transaction and execution frame.
17
17
18
18
## Abstract
19
19
<!--A short (~200 word) description of the technical issue being addressed.-->
@@ -31,38 +31,63 @@ If block.number >= TBD, add three new opcodes:
31
31
32
32
TXGASLIMIT: 0x5c
33
33
34
-
Pushes the gas limit of the entire transaction onto the stack. Gas costs: 2 (same as `GASLIMIT`)
34
+
Pushes the gas limit of the entire transaction onto the stack. This is a value of 'startgas' parameter signed by the externally owned account.
35
+
Gas costs: 2 (same as `GASLIMIT`)
35
36
36
37
CALLGASLIMIT: 0x5d
37
38
38
-
Pushes the gas limit of the current execution frame onto the stack. Gas costs: 2 (same as `GASLIMIT`)
39
-
40
-
TXGASREFUND: 0x5e
41
-
42
-
Pushes the value of the gas refund counter of the entire transaction onto the stack. Gas costs: 2 (same as `GASLIMIT`)
39
+
Pushes the gas limit of the current execution frame onto the stack. This is the 'callGas' value that was obtained after application of the EIP-150 “all but one 64th” rule.
40
+
Gas costs: 2 (same as `GASLIMIT`)
43
41
44
42
Also, consider renaming `0x45 GASLIMIT` to `BLOCKGASLIMIT` to avoid confusion.
45
43
46
44
## Rationale
47
45
<!--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.-->
48
-
Consider a solidity smart contract that wants to emit an event like that:
46
+
Consider a solidity smart contract that wants know how much gas the entire transaction or a part of it had consumed. It is not entirely possible with the current EVM. With a proposed changes, using a pseudo-Solidity syntax, this information would be easily available:
49
47
```
50
-
event MyEvent(gasUsed, gasRefunded);
48
+
function keepTrackOfGas(string memory message, uint256 number) public {
49
+
...
50
+
uint gasUsed = msg.gasLimit - gasleft();
51
+
}
51
52
```
53
+
This is an extremely common use case, and multiple implementations suffer from not taking the non-accessible expenses in consideration. The state-of-the-art solution for the `gasUsed` problem is to access 'gasleft()' as the first line of your smart contract.
54
+
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.
55
+
56
+
Another application is for a method to have a requirement for a gas limit given to it. This situation arises quite commonly in a context of meta-transactions, where the msg.sender's account holder may not be too interested in inner transaction's success. An exaggerated pseudocode:
52
57
53
-
It is absolutely not possible with the current EVM. With a proposed changes, using a pseudo-Solidity syntax, this information would be easily available:
54
58
```
55
-
function keepTrackOfGas(string memory message, uint256 number) public {
function verifyGasLimit(uint256 desiredGasLimit, bytes memory signature, address signer, bytes memory someOtherData) public {
60
+
require(ecrecover(abi.encodePacked(desiredGasLimit, someOtherData), signature) == signer, "Signature does not match");
61
+
require(tx.gasLimit == desiredGasLimit, "Transaction limit does not match the signed value. The signer did not authorize that.");
62
+
...
59
63
}
60
-
```
61
-
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.
64
+
```
65
+
In this situation it is not possible to rely on 'gasleft()' value, because it is dynamic, depends on opcode and calldata pricing, and cannot be signed.
66
+
62
67
63
68
## Backwards Compatibility
64
69
<!--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.-->
65
-
This proposal introduces three new opcodes and renames an existing one, but stays fully backwards compatible apart from that.
70
+
This proposal introduces two new opcodes and renames an existing one, but stays fully backwards compatible apart from that.
71
+
72
+
## Forwards Compatibility
73
+
A major consideration for this proposal is its alignment with one or many possible future modifications to the EVM:
74
+
75
+
1. EIP-2489 Deprecate the GAS opcode (a.k.a. 39-UNGAS proposal)
76
+
There is a sentiment that the ability of smart contracts to perform "gas introspection" leads to the contracts being dependant on current opcode pricing.
77
+
While criticizing said misconception is beyond the scope of this EIP, in case there is a need to make a breaking change to the behavior of the existing `0x5a GAS` opcode, the same considerations will apply to the proposed opcodes. This means this EIP does not add any new restrains on EMV evolution.
78
+
79
+
2. Stateless Ethereum
80
+
The UNGAS proposal is said to be related to the ongoing project of Stateless Ethereum. It’s not strictly necessary for stateless Ethereum, but it is an idea for how to make future breaking changes to gas schedules easier.
81
+
As long as the concept of 'gas limit' is part of the EVM, author sees no reason proposed opcodes would be in conflict with Stateless Ethereum. Gas schedules are not exposed by this proposal.
82
+
83
+
3. Comparison with other controversial opcodes
84
+
There are opcodes that are not proposed for deprecation but face criticism. Examples include `0x32 ORIGIN` being misused by smart contract developers, or `0x46 CHAINID` making some smart-contracts 'unforkable'.
85
+
This EIP neither encourages nor enables any bad security practices, and does not introduce any concepts that are new for EVM either.
86
+
87
+
## Security considerations
88
+
89
+
Existing smart contracts are not affected by this change.
90
+
Smart contracts that will use proposed opcodes must not use them for core of any security features, but only as a source of information about their execution environment.
66
91
67
92
## Implementation
68
93
<!--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.-->
0 commit comments