Update EIP-7778: Block Gas Accounting without Refunds and Route Refunds

[Helkomine]

• Keep the title Block Gas Accounting without Refunds.
• The previously established rules remain unchanged, only a rule has been added to adjust the destination of the refunds.

[eth-bot]

File EIPS/eip-7778.md

Requires 1 more review from Authors: @benaadams, @nerolation

File EIPS/eip-8038.md

Requires 1 more review from Authors: @adietrichs, @misilva73, @weiihann

[benaadams]

• Rename the file to Remove the Refund Mechanism.
• Officially removing transaction-level refund (which also impacts block-level) aims to simplify the implementation but does not significantly affect users.

It isn't removing the refund mechanism?

[Helkomine]

Yes, my intention is to remove the old refund counter (from EIP-3529) because it is creating too much complexity in the EIP-8038 implementation. The idea is to eliminate out-of-transaction refund sources (e.g., slot clearing) to optimize for internal refund accounting (e.g., ACCOUNT_WRITE refunds in EIP-8038). In terms of impact, I think this won't be too significant because transaction costs will become cheaper after Glamsterdam, and internal optimizations could make transactions even cheaper.

[Helkomine]

I changed the phrase to "remove old refund" to emphasize that only the old refund mechanism since EIP-3529 is being removed, while the new refund accounting models (e.g., the state_gas_reservoir of EIP-8037) are perfectly effective and are not within the scope of regulation.

[nerolation]

Yeah I see the simplification argument, and I really like the pr for that. This has been discussed in an ACD when 7778 got cfi'd and by that time we decided to keep the refund as clearing state, in times when state is increasingly becoming a problem, is something we may want to keep.
I personally don't have a strong opinion but would also lean towards keeping it. With increasing state-access costs (EIP-8037, EIP-8038), the refund should increase too, and with state growth increasingly becoming a problem, refunds could be further incentiviced.

[Helkomine]

Actually, I didn't want to remove this refund feature, but I had to in order to add optimizations to the 8038. The 8038 contains complex processing when handling refunds for the 3529, and I want to replace it with a more efficient model similar to the 8037. I was concerned that adding too many refund mechanisms at once would slow down client workflows, so I decided to remove it to make way for more efficient refund accounting.

[Helkomine]

@benaadams,@nerolation These are the corresponding changes to EIP-8038 after removing the old refund counter, please merge this PR first for the changes to take effect.

[nerolation]

I see. So the refund is removed here and introduced similarly in 8038?

[Helkomine]

Yes, the old refund counter will be removed and replaced with a new one called state_access_gas_reservoir

[nerolation]

Right now I'd be hesitant in making bigger changes (e.g. removing the 20% refund cap).
It reallocates complexity, instead of simplifying, at least from looking at the specs.
Might be worth bringing up on ACD.

[Helkomine]

My idea is to remove the old refund mechanism to focus development efforts on EIP-8038. If that's too complicated, perhaps it's better to keep it as is and just update EIP-8038 with the new parameters.

[nerolation]

Would this necessarily come with dropping the 20% cap?
The refund mechanism has been quite stable and hasn't been touched in a while. I'd prefer not changing 7778 at this stage (it's been included in early devnets and has been fine for months now).

[Helkomine]

Yes, it might not be necessary. However, considering that EIP-8038 is handling complex cases related to slot deletion refunds, and it was recently discovered to have a bug in its SSTORE accounting method, I'm reconsidering removing the refund mechanism of EIP-3529. Perhaps we should keep this EIP and simply remove the SSTORE slot clearing refund; the refund counter will still exist, but it will no longer be meaningful. I will keep this PR until EIP-8038 is fully resolved.

[Helkomine]

Another option is to force the redirection of all internal refunds to a new counter. Refunds such as the STORAGE_CLEAR_REFUND of EIP-8038 will still continue to be entered into the refund counter.

[Helkomine]

To avoid affecting the stability of this EIP, I reverted it to its original parameters and only added a refund routing rule. This rule only affects related EIPs such as EIP-8037 and EIP-8038 and does not affect the current EIP. What are your thoughts? @benaadams,@nerolation

[nerolation]

I'd default to not changing anything.
The EIP has been SFI'd and quite stable since the very early devnets, I don't see material improvements or bug fixes at this point.

[Helkomine]

Yes, I'm keeping it as you requested. The added rule only affects target EIPs like EIP-8038 and doesn't change the work already done for this EIP

[Helkomine]

I've kept the original draft of this EIP, the added cases (refund routing) have no impact on the testing process of this EIP. Are there any other issues to consider?

[nerolation]

I'm not a fan of changing big parts of the EIP's text, not logic, at this point.

[nerolation]

E.g. changing the title also means updating it everywhere where it's mentioned (the meta eip, eips that reference it with name, blog posts, etc.). I'd say its bad practice to change the title late in the process. If it's clearly better, go for it but here I don't think we should proceed.

[Helkomine]

I've reverted to the old title for compatibility reasons, perhaps the added minor detail shouldn't affect the original title.