fix withdrawal bal index tracking

[nerolation]

What was wrong?

I'm not 100% sure how this could have occurred but this should make it bullet-proof.

Related to #23

[cr-gpt]

Seems you are using me but didn't get OPENAI_API_KEY seted in Variables/Secrets for this repo. you could follow readme for more information

[nerolation]

Could it be an issue with the test?

I cannot spot the issue in the specs right now

[raxhvl]

Mapping an array doesn’t change its length each element produces exactly one result, even if decoding fails.

[nerolation]

right, but I cannot see the issue here.

[raxhvl]

I placed an exit(1) after this code and the code path is not getting hit, so the bug is elsewhere. I noticed that amsterdam doesn't call self.fork.process_unchecked_system_transaction like prague and cancun, maybe that has something to do with this?

execution-specs/src/ethereum_spec_tools/evm_tools/t8n/__init__.py

Lines 255 to 271 in 5898499

	if self.fork.is_after_fork("amsterdam"):
	self.fork.set_block_access_index(
	block_env.state.change_tracker, Uint(0)
	)
	if self.fork.is_after_fork("prague"):
	self.fork.process_unchecked_system_transaction(
	block_env=block_env,
	target_address=self.fork.HISTORY_STORAGE_ADDRESS,
	data=block_env.block_hashes[-1], # The parent hash
	)
	if self.fork.is_after_fork("cancun"):
	self.fork.process_unchecked_system_transaction(
	block_env=block_env,
	target_address=self.fork.BEACON_ROOTS_ADDRESS,
	data=block_env.parent_beacon_block_root,
	)

[fselmo]

I noticed that amsterdam doesn't call self.fork.process_unchecked_system_transaction like prague and cancun, maybe that has something to do with this?

Amsterdam is after both Prague and Cancun, all of these lines should be called by Amsterdam.

[fselmo]

The state of things here should be:

• Amsterdam first sets the block access index before any of the system txs
• Prague line should be hit processing history storage contract call
• Cancun line is hit processing beacon roots contract call

[fselmo]

Where is this being discussed? This could be an issue with the rebase after the weld, tbh. I will try filling and see if I notice anything strange but please provide more context here if you can.

[fselmo]

Ah, #26 👍🏼

[fselmo]

Maybe we're missing something else, an exit(1) is not hitting this line though:

execution-specs/src/ethereum/forks/amsterdam/fork.py

Line 799 in 5898499

post_execution_index = ulen(transactions) + Uint(1)

If it's not hitting that line then the transaction is failing, no? Without looking much into it if we never process_transaction appropriately is the only case we wouldn't hit that line? 👀

[raxhvl]

Yeah super weird the transaction goes through and we get a BAL mismatch error:

E   execution_testing.test_types.block_access_list.exceptions.BlockAccessListValidationError: Balance change (2, 10000000000) not found or not in correct order. Actual changes: [(1, 10000000000)]

[fselmo]

I found the culprit. I fixed it in the tests PR #23 @nerolation @raxhvl here: 2617d30. Sorry, seemed easier since I was in there already running the tests and now we can modify both spec and tests in the same repo / PR 🔥

Super quirky / tricky to find haha

[fselmo]

Closing in favor of fix in #23 here (2617d30)