EIP-7791: GAS2ETH opcode

Introduces a new opcode, `GAS2ETH`, to convert gas to ETH

Metadata

Status: DraftStandards Track: CoreCreated: 2024-08-13

Authors

Charles Cooper (@charles-cooper), pcaversaccio (@pcaversaccio)

Requires

EIP-2929

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This EIP introduces a new GAS2ETH opcode that enables the direct conversion of gas into ether (ETH).

Motivation

This EIP is based on the premise that smart contract authors, compiler teams, and public goods projects in general should be compensated for their contributions. Moreover, their compensation should scale with the usage of their contracts. A widely used and popular contract offers significant value to its users through its functionality and to the network by driving demand for blockspace — Ethereum's raison d'être. This increased demand also benefits miners and validators, who are rewarded for executing these contracts.

Monetizing smart contracts in a scalable manner remains challenging at the time of this writing. This difficulty is evident from existence of many different monetization strategies employed across various smart contracts — ranging from fee structures to the issuance of tokens with "tokenomics" of varying levels of complexity. Additionally, many public goods projects struggle to secure funding.

Introducing the GAS2ETH opcode offers contract authors, as well as the tools they use, a new way to achieve their monetization objectives. By charging gas, they integrate with an established user experience that is both familiar and understood by users. The proposed instruction ensures that existing transaction creation and processing tools remain unchanged. Moreover, by charging gas, contract authors align economically with network activity; they benefit from higher compensation during periods of intense network usage and receive less when activity is low. This helps align the incentives of smart contract authors, validators, and the broader network.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

A new opcode, GAS2ETH (0xFC), is introduced to enable direct conversion of gas into ETH within the EVM. This opcode operates under a new budgeting mechanism: each transaction maintains a global GAS2ETH budget initialized to the transaction gas limit (tx.gas_limit), and each call frame derives a local allowance from the gas forwarded to it. These budgets cap the total amount of gas that can be converted into ETH, both per call frame and across the entire transaction.

Execution Semantics

The GAS2ETH (0xFC) opcode executes according to the following rules:

Pops two values from the stack: addr then gas_amount. If there are fewer than two values on the stack, the calling context MUST fail with stack underflow.
Deducts gas_amount from both the current call frame's local GAS2ETH allowance and the transaction-global GAS2ETH budget.
- If gas_amount is greater than the current call frame's local GAS2ETH allowance or the remaining transaction-global GAS2ETH budget, set gas_amount to min(gas_amount, remaining_local_allowance, remaining_global_GAS2ETH_budget).
Computes wei_val by multiplying gas_amount by the current transaction context's gas_price (EELS).
Endows the address addr with wei_val wei.
Pushes wei_val onto the stack.

On reverts (e.g., through the REVERT opcode or any exceptional halt), any gas paid out via GAS2ETH MUST be refunded to both the transaction-global and the parent call frame's budgets.

Note that the transfer of wei_val to the target account cannot fail. In particular, the destination account code (if any) is not executed, or, if the account does not exist, the balance is still added to the given address addr.

Gas consumed by GAS2ETH does not affect the base fee, burn, block gasUsed, or the transaction fee. Instead, the ETH transfer represents a direct payment from the transaction signer (i.e. tx.origin) to the recipient address, outside the block reward and fee accounting mechanisms. This ensures no duplication of ETH between the COINBASE reward and the amount transferred via GAS2ETH.

`GAS2ETH` Budgeting Model

A transaction maintains a single global GAS2ETH budget initialized to the transaction gas limit (tx.gas_limit). Each call frame also maintains a local allowance, derived automatically from the gas forwarded to it:

On CALL, CALLCODE, or STATICCALL: allowance = min(forwarded_gas, remaining_global_GAS2ETH_budget).
On DELEGATECALL: the callee shares the caller's allowance.
On revert: all GAS2ETH deductions within that call frame are refunded to both the transaction-global and parent frame's budgets.
On normal return: any unused local allowance is returned to the transaction-global GAS2ETH budget.

This model ensures that untrusted callees cannot consume more GAS2ETH than the gas explicitly forwarded to them, while keeping total GAS2ETH creation bounded by the transaction's gas limit.

Gas cost

The proposed cost of this opcode is identical to the recently proposed PAY opcode.

Constants

Constant	Definition
`WARM_STORAGE_READ_COST`	EIP-2929
`COLD_ACCOUNT_ACCESS_COST`	EIP-2929
`GAS_NEW_ACCOUNT`	EELS
`GAS_CALL_VALUE`	EELS

Gas calculation

Is addr in accessed_addresses?
- If yes, WARM_STORAGE_READ_COST;
- Otherwise, COLD_ACCOUNT_ACCESS_COST.
Does addr exist or is val zero?
- If yes to either, zero;
- Otherwise, GAS_NEW_ACCOUNT.
Is val zero?
- If yes, zero;
- Otherwise, GAS_CALL_VALUE.

Rationale

GAS2ETH vs. pro-rata: The pro-rata model incentivizes inflating contract gas usage to artificially increase fees. In contrast, this proposal allows contract authors to charge their desired amount directly, eliminating the need for unnecessary gas consumption.
Target address vs. simply increasing balance of the currently executing contract: Using a target address is more flexible, enabling contract authors to write more modular code and separate the concerns of fee collection from contract functionality. For instance, the contract may want to designate a specific recipient for fees without necessarily granting them direct withdrawal access.
Charging gas instead of ETH: Charging ETH directly complicates the user experience and prevents contract authors from participating in fluctuations in gas demand directly.
For the value of gas_price, use the same gas price as which is used to calculate the tx cost in ETH. This leads to the most consistent computation between GAS2ETH and the user's experience when creating a transaction.
Separate budget: Having a separate budget prevents certain types of DoS attacks where usage of GAS2ETH can interfere with the actual budget needed for execution of the contract. (For example, a target contract can "waste" gas with GAS2ETH, resulting in the caller not having enough gas to finish execution). This also results in GAS2ETH usage not affecting the burn rate. The intuition is that, since it doesn't actually use computational resources (which gas normally "accounts" for), it shouldn't affect blockspace computations or the base fee.
Budget being 100% of the gas limit: 100% of the gas limit is a "natural" bound on the gas used and provides some protection to the user from unbounded GAS2ETH spending. In the future, a new EIP-2718-based transaction type could be added which includes an explicitly user-specified GAS2ETH budget.
No exceptional halt when gas_amount exceeds the remaining budgets, both the current call frame's local GAS2ETH allowance and the transaction-global GAS2ETH budget. Since these budgets are not introspectable, the contract would otherwise have no way to gracefully avoid an exceptional halt.
Bounding by execution gas ensures that untrusted callees cannot consume more GAS2ETH than the gas explicitly forwarded to them.

Backwards Compatibility

No backward compatibility issues found.

Test Cases

TBD

Reference Implementation

TBD

Security Considerations

Like the PAY opcode and beacon withdrawals, GAS2ETH enables ETH transfers that occur without code execution in the recipient account. To prevent denial-of-service (DoS) attacks from untrusted callees, each call frame receives a local GAS2ETH allowance automatically derived from the gas forwarded to it, while a transaction-global GAS2ETH budget enforces an overall cap equal to the transaction's gas limit. This ensures that:

Callees cannot deplete the sender's GAS2ETH budget beyond the gas explicitly forwarded to them.
Contracts calling into untrusted code remain robust, as the callee's GAS2ETH spending capacity is naturally limited by its gas stipend.
The total ETH that can be created via GAS2ETH in a transaction is strictly bounded.

It's important to note that GAS2ETH introduces an economic incentive for malicious contracts to consume as much of their allowance as possible, converting previously non-profitable griefing vectors into potentially profitable ones. Contract authors SHOULD minimize forwarded gas and GAS2ETH exposure when interacting with untrusted code, similar to existing best practices for limiting gas stipends or ETH transfers.