EIP-3322: Efficient Gas Storage

Right, I misread the EIP. It does not add another stack.

1 Like

Copied from a Github issue:

Adding 3 new opcodes and a 5th item to track with every account is too much for London. If it were to target Shanghai we could discuss the merits, but the timeframe makes this a non-starter because of complexity.

1 Like

@shemnon

  • Modifications to refunds are being considered for London due to relatively urgent concerns about 4x elasticity with EIP-1559, and gas token storage.
  • Any of my engineers should be able to implement and test this EIP in 2-5 days. If core developers are short on resources, we can help with implementations.
  • As aforementioned, if the nullable account gas counter is a major concern, we could instead go with a gas token ERC20 precompile, though that would reduce extensibility and limit future innovation.

I disagree with this. The greatest cost component of gas is the long-term cost, which is why gas limit discussions among miners focus on state growth rather than validation time. We are not close to being bound by short-term costs, so this proposal achieves what you describe later in your argument: shifting bandwidth from low-demand to high-demand periods. This proposal achieves that while still bounding the short-term overhead via the 2x refund limit.

As proof we are not bounded by short-term validation costs, as miners colluded to raise the gas limit from 10m to 12.5m, the uncle rate declined. If miners were even close to their validation limits, the uncle rate would have increased or perhaps stayed the same.

These are not mutually exclusive proposals. Just because phasing out gas refunds goes in for London does not preclude this from being added to Shanghai or later. If this is desirable and has net positive value it can very easily go in then.

I think that obscures the true cost. First the PRs would need to be reviewed by the client teams. My experience has been that this can be 50% to 100% as much effort as simply writing a PR from a client team member. There are many distant side effects in each client that needs to be considered. Second, the reference tests need to be written and accepted by the EF’s testing team. Even if provided externally they have very specific desires that are not always well documented and will also add to the gaant chart.

There are also the coordination costs relating to getting this tested on a YOLO network prior to production testnets. And the slowdown that invariable happens when interpretations of sections vary slightly or are mis-read.

There’s also the implicit safety concern of having one team implement a feature in all of the mainnet capable clients. Do you have a financial interest in seeing this passed? If so would you be willing to post a grant to allow at least one of the client teams to implement it themselves or via bounty?

That would have a worse effect on state storage IMHO, there would need to be two reads down the account trie (but the ERC-20 trie would be smaller). If kept it should be part of the account record.

The downstream impact on other specs like Binary tries are my concern here. They have 4 items enshrined fairly deeply in the details of the implementation (by overwriting two bits of an account hash). This would either need to be rethought (with separate data forks down the trie) or the bit space increased to three.

However my deepest concern is that this will enshrine arbitrage as a core feature of the protocol, whereas before it was an emergent behavior. I think some deep thought needs to go in to the follow on effects of such a movement before it is put into effect. For one this will have a negative impact on miners and block producers (post-PoW) in that the gas fee for the tip will be reduced during spike times and replaced with lower fee gas consumption. They may start playing MEV games like excluding accounts with high gas storage during high tip periods. Moving it into account data rather than in the various gas tokens make it easier for the MEV miners to identify such transactions, at least for the transaction issuer.

When I say “too complex for London” its this kind of secondary effect that I am referring to. I don’t think there is nearly enough time to think out the impacts of this between now and when we have to stop adding to the EIP candidate in 2-4 weeks.

2 Likes

So-long as the refunds are not counted against the gas target, such behavior is unprofitable. The proposal is in many ways a continuation of the status quo so I do not anticipate secondary-order effects besides supplanting storage-based gas tokens.

This is unintuitive for me; I would expect the ERC20 approach to use less space, but I don’t work on the trie.

That would also be acceptable.

Boo-hoo. Think about the users, not the service providers. We can smooth peak congestion by amortizing its costs, and we should.

‘Boo-hoo’ to the miners is not a constructive response. That’s what’s causing the EIP-1559 mess.

The important difference between what you are advocating and 1559 is that refunds are the status quo. From a miner’s perspective the marginal difference is that the elasticity costs less storage.

But what is not different is the dismissiveness shown to miners. There is also the consideration of block producers for Eth 2, their marginal reward will be lower so there is a greater incentive to ensure that they get the most tippable gas out of the transaction.

The status quo is that gas arbitrage is an emergent behavior, not a deliberate design choice. I have concerns about regulatory capture if we make it explicit in the protocol.

What do you mean by regulatory capture?

Your post makes me think that you’d want to enable a futures market for gas.

1 Like

Having used the GAS and GASPRICE opcodes, and planning to use the BASEFEE opcode, I disagree. Gas is the best feature of the EVM; it’s how we meter the use of shared resources and prevent DoS.

This EIP incentivizes users to bulk purchase gas whenever the price is low. These mass buyers would benefit a lot more if we combine this with EIP-1559. The problem is that EIP-1559 does not account for slippage. I have already discussed this point two years ago in here (last paragraph). Users are paying for the burden which the previous users put on the network rather than their own. Hence, if we start hoarding gas by making an otherwise under-used block full, then the users in the next block will have to pay the extra charges while we spend the stored gas gradually. This gets even worse when we realize that EIP-1559 tells us that if we see a usage spike in the current block, then the gas price will go up sharply in the next block. Therefore, rational users are incentivized to pre-purchase gas for the next block, which in turn, makes the current spike even sharper. This is the opposite of what happens if we had considered slippage by simply replacing the gas used in the previous block with the gas used in the current block in the update rule’s formula.

1 Like

It’s cheaper for them to buy it on a DEX than to mint it themselves in this case. Available liquidity is much deeper than the current block.

1 Like

Disclaimer that I haven’t read the discussion above. Posting this here just so that my opinion is documented in the official discussion.

I am strongly opposed to enshrining the concept of “gas tokens” into the protocol.

  • refunds are of questionable usefulness and have not been shown to be an effective measure to mitigate state growth.
  • 1559 already provides elasticity for the “supply”
  • the current plans to mitigate state growth are fully independent from the refund mechanism

These lead me to my opinion that this introduces significant complexity with minimal benefit.

refunds are of questionable usefulness and have not been shown to be an effective measure to mitigate state growth.

Strongly refuted here

1559 already provides elasticity for the “supply”

To handle peak congestion we will need to be able to sustain >1x throughput for much longer than allowed by 1559, while still amortizing the long-term costs, which are not limited to state growth. There is no reason that bandwidth costs should surge 50x when usage increases 3x for a few hours. Grocers don’t raise their prices in the afternoon; they hire part-time workers.

The elasticity of 1559 is unproven on a congested blockchain, and may not come until PoS due to increased uncle risk under PoW. Consider deferring your judgment about the elasticity provided by 1559 when it wasn’t designed to provide it, but instead to pump the ETH price.

the current plans to mitigate state growth are fully independent from the refund mechanism

If you prefer state rent, I encourage you to live with it for 10 years before forcing it on everyone else. You may find it annoying that the ENS handle you had reserved for 100 years is gone now, the few who have the info you need to prove it back into existence are charging you a fortune for the privilege, and the state size has not actually shrunk because of the stubs. It’s unreasonable to plan around a system that nobody has a good design for, never mind an implementation. State rent is a pie-in-the-sky solution to numb you until we realize state growth is not that bad when we let the miners-soon-stakers who pay for it set hard limits on its growth.

These lead me to my opinion that this introduces significant complexity with minimal benefit.

The complexity is 32 bytes per contract account that stores gas. I don’t recommend storing this attribute on every account by default. The benefit is that this uses significantly less storage for more elasticity than provided in the status quo. If you don’t care about storage you must not run a node.

edit: formatting

This refutation isn’t compelling for me. I don’t believe that users would actually do the balance(..) - 1 approach broadly, and beyond this, refunds have not proven to be adequate to provide any meaningful mitigation to state growth. They may slow it down some, and removing refunds might make the problem a little worse… but ultimately, to really provide a meaningful solution for state growth, a more significant change is needed, hence: Resurrection-conflict-minimized state bounding, take 2 - #17 by vbuterin - Execution Layer Research - Ethereum Research

I agree on this. I now understand that 1559 doesn’t provide the type of “supply elasticity” that 3322 proposes. I still don’t see this argument as compelling enough to justify the complexity.

See Resurrection-conflict-minimized state bounding, take 2 - #17 by vbuterin - Execution Layer Research - Ethereum Research

This is the leading model for how we intend to deal with state growth at the protocol level.

The complexity is that it introduces more nuance to how gas is used and accounted for. This will inherently effect many different parts of how the EVM operates. I’m not suggesting that there is anything insurmountable. Just that this isn’t a “small” change, and that I don’t see it being prioritized over the other significant protocol changes that are being worked on.

1 Like

If you prefer state rent, I encourage you to live with it for 10 years before forcing it on everyone else. You may find it annoying that the ENS handle you had reserved for 100 years is gone now, the few who have the info you need to prove it back into existence are charging you a fortune for the privilege

Hi. Could you help me understand why the “few who have info” will necessarily behave as a monopoly (and charge a fortune)? Why won’t one of them undercut the others? Disclosure: I am researching state rent! :slight_smile: Thanks

It would be very costly to maintain a redundant system over time, and few customers willing to pay much of anything, especially at first. Costs are not restricted to hardware; the system must also be maintained by engineers. Due to the cost of maintenance I would rule out altruism after the first several years. The number of providers would be perpetually diminishing; nobody would allow anyone else to copy it cheaply lest they invite competition and ruin the very reason to have preserved the data in the first place. The resulting barrier to entry would result in collusion and monopolistic pricing. Failures to collude would harm all participants, reducing the count until equilibrium allows collusion or an outright monopoly. Mergers are likely collusion strategies in this scenario.

It’s not so much about the users as it is about the protocols. Most end-users do what the UX tells them to, and the protocols with the most users will have earned them at least in part by minimizing their gas costs.

On the contrary, it uses an existing mechanism, the refund counter.

Agreed, especially for this year.