EIP-7791: GAS2ETH opcode

EIPs EIPs core
21

@jochem-brouwer suggested offline having a separate limit for GAS2ETH – in other words, it does not deduct from the regular “execution” gas counter, but from its own, gas2eth-specific counter. That way it cannot interfere with gas available to execution.

3 Likes
22

I’ve proposed this change in Update EIP-7791: update gas2eth - add separate gas2eth limit by charles-cooper · Pull Request #10129 · ethereum/EIPs · GitHub.

1 Like
23

At first I really liked the idea but after thinking about it more, I’m not sure how I feel.

As an app developer, having a semi-constant value per tx is more appealing than something that fluctuates based on gas price. This opcode is therefore not super impactful as there may not be consistent revenue to anticipate and I’m better off finding other revenue mechanics.

Bundling this into the gas cost may feel cleaner for smart contract devs but I think it requires that users know more about the blockchain and the pricing breakdown isn’t very clear for the end user. I think this could lead to user confusion and different marketing tactics from similar protocols where the end result is people not using this opcode. Perhaps that doesn’t matter as much to you all, but user experience is important imo.

How does this work on L2s where gas price is meant to be near zero? This opcode breaks that premise for L2s, especially if trying to drive revenue of $0.10+ per tx.

Based on reading the comments, there will be some limit to keep this opcode to marginal amounts of ETH where it doesn’t impact gas price of the network and doesn’t introduce new griefing vectors If that’s the case, as an app, I’m forced to weight the marginal benefits of using this versus figuring out other monetization paths that may provide more consistent and substantial value per tx.

Please let me know if you think I’m thinking about this wrong.

1 Like
24

Reading the gas calculation part of the specs, I think we should do

Gas calculation

  • Is addr in accessed_addresses?
    • If yes, WARM_STORAGE_READ_COST;
    • Otherwise, COLD_ACCOUNT_ACCESS_COST and add addr to the accessed_addresses. ← THIS
  • 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.
25

I’m confused: who pays for the value being transferred ? In other words, how does the gas2eth counter affect how much gas is re-converted to Wei at transaction end / paid out to the coinbase ? I’m not understanding what prevents a transaction to e.g. return gas2eth to tx.origin at the start and then proceed with the remainder of the transaction, thereby creating Eth for the transaction originator ?

26

Computes wei_val by multiplying gas_amount by the current transaction context’s gas_price

Gas consumed by gas2eth does not affect the base fee or burn.

This spec duplicates ether by paying it both to the COINBASE and also minting it for the transaction. Should say that the ethergas doesn’t count toward the block gasUsed and the transaction fee: that it is paid from the signer to the address.

Should also mention in Security Considerations that this is a new way, like beacon withdrawals and the PAY opcode, for a non-payable account to receive ether.

1 Like
27

noted – this is a good point

28

good catch - addressed via Update EIP-7791: Fix `GAS2ETH` ETH Flow and Amend Security Considations by pcaversaccio · Pull Request #10501 · ethereum/EIPs · GitHub.

29

this EIP was presented at ACDE today – a link to a discussion group was requested, i’ve created one in chat format to complement the discussion here: Telegram: View @gas2eth

30

As a smart contract & tooling developer I wanted to signal my support for this proposal.

I think the main advantage of this proposal is the UX benefit. Fees can already be charged in all kinds of ways but the gas fee is a fee that every transaction must already pay. Adding to that therefore poses little to no additional UX cost for the user.

The gas cost to perform a GAS2ETH execution in practice seems quite high though. Assuming the address is already warm it’ll cost 9100 gas. If we take the typical user interaction to be 100k-200k gas that’s 4.5-9% of the tx cost just to have a GAS2ETH in the first place.

This is not necessarily a GAS2ETH specific problem, I have a general belief that value carrying calls are overpriced currently (I mean it’s effectively just a state trie update but it costs almost >3x the added SSTORE cost of changing a non-zero value).

4 Likes
31

As someone who has built open source smart contract protocols on Ethereum for years, I wanted to strongly signal my personal support for this proposal.

Monetizing protocols has historically been extremely challenging for devs, and has caused a continuous exodus from Ethereum due to an inability to build sustainable projects without relying on public goods funding/grants.

I recently wrote about how the dapp ecosystem in Ethereum is floundering, and I think one of the main reasons why is the inability to easily monetize dapps which generate value for users. Full post here: https://m.mirror.xyz/PjtJM7JzimTOe21qm_ORexT4pEdb2zmUVdCSCrmNj_E

This EIP significantly improves the business model opportunities for dapp builders on Ethereum, and will encourage developers to understand the upside potential from building atop the world’s biggest and most decentralized turing-complete blockchain.

2 Likes
32

Based on my current understanding of this EIP, the callee contract (or target addr of a given call context) will be compensated in wei, by gas_amount * effective_gas_price from the transaction initiator tx.origin’s balance, as long as gas_amount is less than the GAS2ETH limit specified in this call context. (Please correct me if I am wrong)

My question is would this EIP allow setting a percentage of wei compensated to the callee. (E.g. a contract author may want to charge a fee based on percentage of the gas consumed). I get that the default behavior allows the contract to fully absorb gas_price * gas_amount, but imo being able to control how much fee a contract is getting is a nice bonus. Plus, having the ability to set a lower percentage would attract users, since they would pay lesser fees.

33

I think the proposal introduces some interesting ideas, but the current specification feels a bit too rigid. It might make sense to remove the gas_price component from the opcode entirely and allow contracts to define how the wei amount is computed.

On a related note, the name GAS2ETH feels somewhat misleading. Aside from referencing gas_price, it doesn’t really interact with the rest of the gas accounting system. A name like TAX might be clearer. In that case, PAY could handle sending ETH to an arbitrary address, while TAX would handle charging ETH from the transaction sender.

I’m also uncertain how this would interact with Type 4 transactions (EIP-7702), particularly for sponsored transactions. In those cases, should the charge apply to the sponsor or the authority?

34

have you done any efficacy analysis (benefits or second order effects) of similar implementations in other ecosystems like Near? see the docs about Gas as a developer incentive

see multiverseX (fka Elrond) as “developer rewards”

this was also proposed 2y ago as “contract secured revenue”, and i had the same question for

35

I think the main idea behind this EIP is to really integrate the proposed fee mechanism into the native gas. So, using gas_price is super important to ensure it keeps up with the base fee as it changes. And about the GAS2ETH name, it’s all about turning the gas users spend into ETH, playing off the concept that this payment is from ‘gas’.

36

I strongly support this proposal, as it sets up the perfect incentive for protocols be aligned with ethereum validators. Plus, it opens the door for more non-financial infrastructure, like Safe, to make money in a more natural way, without needing to rely on tokenomics.

Quick question:

  • Will this have a big impact on the current estimateGas RPC call? From what I’m seeing, separating the execution gas limit from the gas2eth gas limit seems necessary (for the reasons mentioned above), but should we have “estimateGas” return the total of executionGas and gas2ethGas? Otherwise, a lot of existing packages might run into issues if the extra gas2eth gas causes transactions to revert on-chain.
37

I am drafting an EIP to address this by the way – Add EIP: Warm Account Write Metering by charles-cooper · Pull Request #9900 · ethereum/EIPs · GitHub. Let me know if you would like to contribute

1 Like
38

In regard to consumption limit per-call has anyone considered imposing a 63/64 gas rule kind of like EIP-150. The harmonization of gas consumption rules may be useful for simplicity purposes.

39

As a quick heads-up for anyone following the progress here, we have updated the EIP to address a potential DoS attack vector for contracts calling into untrusted code: Update EIP-7791: Patch DoS Attack.

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.

2 Likes
40

I personally like the above suggestion, but should we add a reverse directive (ETH2GAS) to allocate more gas in case the caller doesn’t have enough gas (for example tx.sender only has enough eth left to provide maximum 100000 gas units, but actually requires 200000. By cleverly putting the context execution on an address (contract or eoa using eip7702) with ether and resolving them with ETH2GAS, we can add the missing fuel to the execution)