eth/tracers: fix testcase 7702_delegate

[allformless]

case 7702_delegate is used to test the trace result of processing a 7702 tx
but IsPrague is not enabled when running, so the code 0xef0100b684710e6d5914ad6e64493de2a3c424cc43e970 is run, and view '0xef' as an invalid opcode.

this PR is to fix it.

[jwasinger]

Wish I knew what the test is actually doing so that I can verify the updated expected result.

The changes to util.go were unecessary. We can just modify the test case to use a premerged genesis configuration.

[allformless]

Wish I knew what the test is actually doing so that I can verify the updated expected result.

The changes to util.go were unecessary. We can just modify the test case to use a premerged genesis configuration.

The logic in util.go follows this reference, so I think it’s already clear.

With your changes, new test cases will need to handle this and update the chainconfig as you did here. Hopefully, others will follow your pattern — which is fine.

However, with my original commit, they can simply ignore this and use a configuration closer to mainnet.

[s1na]

view '0xef' as an invalid opcode.

How do you exactly reproduce this error? The test passes for me locally. I can also verify that a delegation is in fact invoked (from 0x17816E9A858b161c3E37016D139cf618056CaCD4 to 0xb684710e6d5914aD6e64493dE2a3c424CC43e970) and the prestate result includes the delegated code.

[jwasinger]

Weird. I thought I had witnessed it failing locally, but indeed it does not..

[allformless]

view '0xef' as an invalid opcode.

How do you exactly reproduce this error? The test passes for me locally. I can also verify that a delegation is in fact invoked (from 0x17816E9A858b161c3E37016D139cf618056CaCD4 to 0xb684710e6d5914aD6e64493dE2a3c424CC43e970) and the prestate result includes the delegated code.

7702_delegate.json is designed to test whether tracing of 7702-type transactions works correctly. It defines both the input and the expected output.
Although this test case currently passes, it does not actually fulfill its purpose. For example, the expected output should include the delegate contract’s code and storage, but these are missing from the current JSON file.

The root cause is that IsPrague is set to false, which means execution of 7702-type transactions is not supported at all, preventing the test from achieving its goal.
The commit I submitted fixes this issue.

[s1na]

Although this test case currently passes, it does not actually fulfill its purpose. For example, the expected output should include the delegate contract’s code and storage, but these are missing from the current JSON file.

Please share which is the delegate contract that is missing. I saw one delegation and that was included.

The root cause is that IsPrague is set to false

Where is it set to false?

[allformless]

this PR have 3 commits now, I recommend only keep the first commit, check the first commit, you can see

without this PR, context.Rondom=nil
testPrestateTracer-->NewEVM, then
https://github.com/ethereum/go-ethereum/blob/master/core/vm/evm.go#L145

chainRules:  chainConfig.Rules(blockCtx.BlockNumber, blockCtx.Random != nil, blockCtx.Time),

then IsPrague will be set to false!

so when IsPrague is false, the test case to test 7702-tx is meaning less.

---

to be simple, can you just run the case eth/tracers/internal/tracetest/testdata/prestate_tracer/7702_delegate.json
and print the value of IsPrague? @s1na
then you know the issue

[s1na]

@allformless I can confirm it now thank you. The reason for my confusion was that the tracer was in prague because it used chainConfig.IsPrague logic. However as you pointed out its the EVM that's not in prague.

Please revert the last 2 commits. But instead of changing toBlockContext logic in the test, let's set the testcase's genesis.Config.TerminalTotalDifficulty to 0.

[jwasinger]

But instead of changing toBlockContext logic in the test, let's set the testcase's genesis.Config.TerminalTotalDifficulty to 0.

This is exactly what my last two commits do.

It's weird that this test-case is meant to test 7702 behavior, yet passes regardless of whether 7702 is enabled. That seems to indicate that the test is not sufficient.

[s1na]

This is exactly what my last two commits do.

Ok I see pardon I was confused by the change in fork blocks. Yeah I ran it and it seems to work. I think the fix is good.

It's weird that this test-case is meant to test 7702 behavior, yet passes regardless of whether 7702 is enabled. That seems to indicate that the test is not sufficient.

What was happening is: the tracer was correctly capturing the delegation because that happens right at the start of the tx (in fact tx is sent directly to a delegated account). However the EVM fails to correctly perform the delegation because it thinks it's still not in Prague so tx stops abruptly. Now with these changes it will finish processing the tx and so it captures more prestate.

We just need to fix the merge conflict.

[s1na]

LGTM