Update EIP-8037: Add access-list based deduplication and success/failure cases

[CPerezz]

Adding 2 important fixes/clarifications to EIP-8037:

1. Success/Failure Gas Accounting: Properly distinguishes between successful and failed contract deployments. Post-execution costs (ACCOUNT_CREATION_COST, HASH_GAS, CODE_DEPOSIT_GAS) are now only charged on success, aligning with Ethereum's principle that gas should reflect actual resource consumption.

2. Access-List CodeHash Deduplication: Replaces database lookup mechanism with an access-list based approach to solve consensus divergence between different sync modes (full-sync vs snap-sync). Approximately 27,869 orphaned bytecodes exist in full-sync nodes with no live account links, making DB lookups non-deterministic.

Changes include:

• Explicit success/failure gas formulas with detailed rationale
• AccessTuple extension with checkCodeHash field
• Comprehensive rationale explaining sync-mode divergence problem
• Developer-facing specification with Go struct and JSON example
• Updated gas cost examples for all scenarios
• LaTeX formatting for mathematical notation

[eth-bot]

✅ All reviewers have approved.

[misilva73]

Aren't we missing the case where the initcode reverts but the account is still created? I remember this being an edge-case that Guillaume pointed out

[CPerezz]

@gballet is this the case?

Aren't all clients creating the account after or before? They do as they want?

@misilva73 my idea here was that if we fail, we won't create the account. Note that without selfdestruct, it should not be possible to create the account if initcode reverts.
Nevertheless, happy to change.

[gballet]

so it's a bit tricky, but yes there is some edge case: if there isn't enough gas to save the entire code, then its nonce will be set to 1 and the account will be saved to the state.

To be clear, it's only in case of an OOG during the storage part. If the init code reverts, or runs out of gas, no account will be created.

The account will be created before calling the init code (although it's persisted in the state afterwards) but there is a "checkpoint save" before that is done. If there is any other error than running out of gas while storing the code, then it will go back to that checkpoint.

• so L > MAX_CODE_SIZE and REVERT/OOG during initcode should not charge ACCOUNT_CREATION_COST but OOG during code deposit does.
• note that if initcode OOGs, it doesn't matter if you charge the following gas costs: there's just not enough gas to pay for them anyway. So whether you are at -100 or -1000 makes no difference.

The question that remains to be answered is: how do we treat running out of gas for HASH_GAS(L) ? should the account be created? It depends when the hash happens. if it happens after the account creation gas is charged, then I'd say it's only fair that the contract gets created. If it happens before, then it should not. My preference goes to creating it because we paid for it.

[gballet]

ok, I've made a mistake here: this is only true of pre-homestead: post-homestead, the thing is reverted. so we don't have this problem today. That makes sense, you don't want to prevent a further deployment of code at this address.

But the question still remains: if you oog during code hash computation, do you want to create the contract if things still happen? to be consistent with the current behavior, you should not create anything. It's unfair, because you paid for it, but it's simpler.

[gballet]

So one thing to add, mostly as a reference for myself to remember: you don't need to charge the hashing costs, because this happens after the gas cost for contract storage have been paid. so the wording is correct.

[misilva73]

I would be a bit more specific here. My suggestion:

Suggested change

	This proposal fundamentally changes how contract deployment costs are computed to properly account for success and failure paths, ensuring that post-execution costs are only charged when deployment succeeds.
	This proposal introduces a discount for contract deployment of duplicated bytecode. To account for the added work of checking bytecode duplication, it additionally charges a storage access cost and a hashing cost, while properly accounting for success and failure paths and ensuring that post-execution costs are only charged when deployment succeeds.

[gballet]

I don't think that the discount should be the first thing to mention here, because the main point is that it is a more fine-grained accounting of the state gas costs.

[misilva73]

It is only more fine-grained because of the discount. If it was not for the discount, we would not be charging the hashing cost nor the access cost

[misilva73]

If we account for the case where an account is created but code is not deployed, we would need another formula here. To keep things simple, I would suggest not having these formulas. Not a strong opinion, though

[CPerezz]

If this is suposed to be the spec, I think the more info we have, and the clearer we make it, the better. Core devs will appreciate nice and detailed specs IMO.

[misilva73]

The final spec won't look like this, actually. If we are doing the correct spec, we will need to change generic_create, def create and def create2 and the formula will be more complicated than what we currently have.

My understanding is that this is a simplified description of the changes and thus the shorter and simpler, the better. But if you feel strongly about keeping it, I will not be a blocker.

[misilva73]

Wondering if we should add 2930 to the required EIPs field 🤔

[CPerezz]

Hmmm. I thought that this is only done if the EIP required isn't merged.
Happy to add it.

Maybe @jochem-brouwer can bring some advice here.

[misilva73]

I think we should keep the previous variable names. I took them from the execution specs. Is there a reason for using the new ones you propose?

[CPerezz]

Ohh I see. I thought they were better. But not strongly opinionated. So will revert.

[misilva73]

This section shouldn't be under "rationale". We should create a section named "Reference Implementation" . Check EIP-1

[misilva73]

Let's run over an example, as I don't think I am who W is built.
Let's assume we have a block with two transactions:

• $T_A$ deploys a contract with new bytecode
• $T_B$ follows $T_A$ and deploys the same bytecode as $T_A$

With our current design $T_B$ should receive a discount, while $T_A$ pays the full cost. However, the codeHash of both contracts is in W as they are "access-listed addresses where checkCodeHash == true". So, before each transaction execution, the check would yield a duplicated bytecode for both transactions and no code deposit would be charged. Is this correct?

Also, if I understand this correctly:

• If W only contains the codeHash of access-listed addresses, are we saying that only contract deployments that use EIP-2930 get a discount?
• Do clients need to keep an history of all code hashes previously included in an access-list?

[CPerezz]

I added some clarifications. Hope is easier to follow now!

[misilva73]

It looks great now, much clearer 👏

[gballet]

EXECUTION_GAS looks like a constant, I would rather have something like exec_costs(initcode)

[misilva73]

Actually, the full formula in the specs is:

  # GAS
  extend_memory = calculate_gas_extend_memory(
      evm.memory, [(memory_start_position, memory_size)]
  )
  call_data_words = ceil32(Uint(memory_size)) // Uint(32)
  init_code_gas = init_code_cost(Uint(memory_size))
  charge_gas(
      evm,
      GAS_CREATE
      + GAS_KECCAK256_WORD * call_data_words
      + extend_memory.cost
      + init_code_gas,
  )

So, it depends on the initcode in the call data and the memory expansion.

[CPerezz]

Applied the change from @gballet

Also, agree the formula is more complex. But exec_initcode_costs implicitly accounts for mem expansion and call data costs. As this isn't something we are changing.

[gballet]

use CODE_DEPOSIT_GAS instead of 1900

[gballet]

"then link" -> truncated sentence?

[rakita]

Optimisation on duplicated bytecode is something that we can do even now. That change should be contained in its own EIP and discussed separately from the gas cost increase.

[github-actions]

The commit 2d37dcc (as a parent of e5a48e5) contains errors.
Please inspect the Run Summary for details.

[CPerezz]

Optimisation on duplicated bytecode is something that we can do even now. That change should be contained in its own EIP and discussed separately from the gas cost increase.

Asked the rest of EL clients. Once I get answers from the rest will act accordingly. I thought about including it because this is part of the "gas harmonization cost" idea. But, indeed, this is something we can already do now..

[gballet]

it's actually at the time of cancun, not at the time of this eip

[gballet]

are the hashes included in the tx list? my understanding is that the addresses in the list trigger a loading, and therefore the code hashes associated to these addresses are available in the cache.

Unless you want to add a new field, which is fine I guess.

[gballet]

but you would still need to load the account to make sure that the hash is the one you specify in the list

[gballet]

btw one thing of note, is that people were talking about deprecating access lists in favor of BALs. Not sure what happened to that proposal, but that's something that is at odds with this approach if someone is still pushing it.

[gballet]

does that really make sense? the addresses are going to be loaded anyway, so maybe it's enough to just build a hash map with every hash present?