feat(benchmark): add log opcode worst case

[LouisTsai-Csie]

🗒️ Description

Create Benchmark for LOG Opcode

This PR introduces a benchmark for the LOG opcode in the EVM. The LOG operation includes multiple fields: offset, size, and up to N topics depending on the variant (LOG0 through LOG4).

Gas Cost Calculation

Using LOG0 as an example, the gas cost for the LOG operation is computed as:

• Static gas: 375
• Dynamic gas:dynamic_gas = 375 * topic_count + 8 * size + memory_expansion_cost

To minimize gas costs:

• Use zero size to avoid dynamic gas from memory access.
• Use PUSH0 (which costs 2 bytes) for pushing values to the stack, as it’s cheaper than other operation like PUSH1 (3 bytes with an immediate) or DUP1 (3 bytes).

Using PUSH0 is also more space-efficient, since it avoids including immediate values and reduces bytecode size.

Benchmark Bytecode Pattern

A minimal loopable pattern for benchmarking LOGN looks like this:

JUMPDEST
PUSH0      ; offset
PUSH0      ; size
...        ; PUSH0 repeated N times for each topic
LOGN
...        ; repeatable pattern
PUSH0
JUMP

Using PUSH0 is also more space-efficient, since it avoids including immediate values and reduces bytecode size. This makes it preferable over DUP1 for setting up the stack for topics or memory offset/size.

🔗 Related Issues

Issue #1689

✅ Checklist

• All: Set appropriate labels for the changes.
• All: Considered squashing commits to improve commit history.
• All: Considered updating the online docs in the ./docs/ directory.
• Tests: Included the type and version of evm t8n tool used to locally execute test cases: e.g., ref with commit hash or geth 1.13.1-stable-3f40e65.
• Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.

[jochem-brouwer]

This test looks fine to me, it tests all LOG opcodes and runs those all as much as possible. However, I think we should also add these situations:

• Log data length is nonzero
• Log data length + data is nonzero (here we have to initialize the memory to something non-zero)
• The topics are nonzero

I am not sure because I am not deep into zkEVM, is calculating the logsBloom part of the scope of the EVM (and would thus add extra logic/cycles) @jsign? If this is indeed part of it (either logsBloom or calculating receiptTrie or both) then those tests should be added for zkEVM (can be done in a different PR).

Those tests are also nice benchmark tests for non-zkEVM also 😄 👍

Will not explicitly approve for now.

[LouisTsai-Csie]

Thanks for comment, I do not know logsBloom and receiptTrie before, i will review some documentation for them

[jsign]

This test looks fine to me, it tests all LOG opcodes and runs those all as much as possible. However, I think we should also add these situations:

• Log data length is nonzero
• Log data length + data is nonzero (here we have to initialize the memory to something non-zero)
• The topics are nonzero

I am not sure because I am not deep into zkEVM, is calculating the logsBloom part of the scope of the EVM (and would thus add extra logic/cycles) @jsign? If this is indeed part of it (either logsBloom or calculating receiptTrie or both) then those tests should be added for zkEVM (can be done in a different PR).

Those tests are also nice benchmark tests for non-zkEVM also 😄 👍

Will not explicitly approve for now.

Yep, calculating logsBloom/receipts is part of proving -- so I agree that it is useful to cover the cases you mentioned.

[jsign]

Looking good! Reg @jochem-brouwer suggestion to cover non-zero scenarios (which I agree are useful), I'll let you decide if those might be worked in this PR or in a separate one -- for now leaving an approval if it is the latter.

Just left one comment for your consideration.

[marioevz]

LGTM, just one suggestion that is in line with the comments from previous reviewers, thanks!

[marioevz]

For the mypy error, I think if you rebase to main it should be gone, I just fixed that in another PR.

[LouisTsai-Csie]

@jsign @jochem-brouwer I’ve updated the test case and added the following scenarios:

• Topics are zero and non-zero
• Log data has a non-zero length

Could you please help me review again? And i am asking why the CI is failing

[marioevz]

Thanks! Just some minor comments.

I think we can move this new test function into a new file, perhaps tests/zkevm/test_worst_opcode.py ?

We can start by moving only this new function for now in this PR, I have an idea on how to fix the coverage script and we can move the rest once that's fixed.

[LouisTsai-Csie]

@marioevz Thanks for review. My original problem for evmone coverage report is that the CI never ends, but after I rebase again, the issue changed.

After checking the coverage report, the root cause is from BLS signature, which has nothing to do with this benchmark. I move the test case to tests/zkevm/test_worst_opcode.py, let's see if this fix the CI issue

@jsign @jochem-brouwer could you please also review this benchmark, let me know if I miss any cases!

[jsign]

Looks good, I left some comments for your consideration.

[marioevz]

The coverage script was broken and I created a PR to fix it: #1817

I pushed commit 1510245 on top of your branch to verify the fix, and we can remove it once we merge #1817 to main and rebase this branch.

[marioevz]

Fixed the coverage issue by rebasing on top of main again, so we can address @jsign comments and then proceed to merge.

[jsign]

LGTM, I think there's only one easy detail left but leaving it approved.

[marioevz]

LGTM, thanks!

Just some minor nit-picks.

[LouisTsai-Csie]

Thanks @marioevz