EIP-7791 - GAS2ETH opcode

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 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.
• 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 the gas cost of this opcode + gas_amount is greater than the available gas in the current calling context, the calling context should fail with "out-of-gas" and any state changes reverted.
• Pushes wei_val onto the stack.

Note that the transfer of wei_val to the given 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 cost

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

Constants

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.

Backwards Compatibility

No backward compatibility issues found.

Test Cases

TBD

Reference Implementation

TBD

Security Considerations

Needs discussion.

Copyright

Copyright and related rights waived via CC0.