Alert Source Discuss
⚠️ Draft Standards Track: Core

EIP-7791: GAS2ETH opcode

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

Authors Charles Cooper (@charles-cooper), Pascal Caversaccio (@pcaversaccio)
Created 2024-08-13
Discussion Link https://ethereum-magicians.org/t/eip-7791-gas2eth-opcode/21418
Requires EIP-2929

Table of Contents

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 quantity is added to the calling and transaction context, the gas2eth limit. It is analogous to the gas counter, but is transaction-global and is maintained separately from the gas limit. At the beginning of the transaction, it is initialized to the same value as the transaction gas limit.

A new opcode is introduced, GAS2ETH (0xFC), which:

  • Pops two values from the stack: addr then gas_amount. If there are fewer than two values on the stack, the calling context should fail with stack underflow.
  • Deducts gas_amount from the current calling context’s gas2eth limit.
  • Computes wei_val by multiplying gas_amount by the current transaction context’s gas_price (EELS).
  • Endows the address addr with wei_val wei.
  • If gas_amount is strictly greater than the remaining gas2eth limit, the calling context should fail with “out-of-gas” and any state changes reverted.
  • Pushes wei_val onto the stack.

On reverts (e.g., through the REVERT opcode or any exceptional halt), any gas paid out via GAS2ETH should be returned to the gas2eth budget.

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 or burn.

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 limit: Having a separate limit 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.
  • Limit 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 limit.

Backwards Compatibility

No backward compatibility issues found.

Test Cases

TBD

Reference Implementation

TBD

Security Considerations

Needs discussion.

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Charles Cooper (@charles-cooper), Pascal Caversaccio (@pcaversaccio), "EIP-7791: GAS2ETH opcode [DRAFT]," Ethereum Improvement Proposals, no. 7791, August 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7791.