feat(benchmark): add clz opcode test case

[LouisTsai-Csie]

🗒️ Description

Add benchmark test for CLZ opcode.

🔗 Related Issues or PRs

Issue #1795

✅ Checklist

• All: Ran fast tox checks to avoid unnecessary CI fails, see also Code Standards and Enabling Pre-commit Checks:

  uvx --with=tox-uv tox -e lint,typecheck,spellcheck,markdownlint

• All: PR title adheres to the repo standard - it will be used as the squash commit message and should start type(scope):.
• All: Considered adding an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• All: Set appropriate labels for the changes (only maintainers can apply labels).
• Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.
• Tests: For PRs implementing a missed test case, update the post-mortem document to add an entry the list.
• Ported Tests: All converted JSON/YML tests from ethereum/tests or tests/static have been assigned @ported_from marker.

[LouisTsai-Csie]

This if-statement is for EIP-7852 for transaction limit cap, more details could be found in this issue.

We should have a wrapper for all the benchmark test cases, but i will leave it in a separate PR.

[LouisTsai-Csie]

In the second test case, I aim to add some randomness. Using a simple range from 1 to iteration results in many values being too similar.

[jochem-brouwer]

I get the idea but I would set this up differently. We have code_prefix and code_suffix so we know that we can add at most max_code_size - len(code_prefix) - len(code_suffix) bytes. I'd keep incrementing some number here and then let CLZ work on 2^256 - 1 >> i % 256. This i increments each round and will thus right shift the values such that CLZ yields a different value. Note that for each CLZ you add you should check Op.CLZ(value) + Op.POP if this length does not exceed the max size (else break). This length is not constant because it will depend on how many bytes we are pushing (to push 2^256-1 need PUSH32, and for 1 need PUSH1)

[jochem-brouwer]

Some comments 😄 👍

Need to also think on how to use these benchmarks, i.e. how to test these against clients and how to interpret the results. The end goal could be to determine the gas price of the opcode. For that we also need a baseline in order to interpret the results and thus also to price the opcode. This is non-trivial because these benchmarks use other opcodes as well, and we thus have to find a way to measure the costs for CLZ only (and not the cost of the other opcodes). Food for thought!

Left a comment on one of the tests. The 248 trick is beautiful 😄 👍

[jochem-brouwer]

This will deploy a contract too large. Could you add the sanity check?

Suggested change

	code_address = pre.deploy_contract(code=code_prefix + code_seq + code_suffix)
	code_address = pre.deploy_contract(code=code_prefix + code_seq + code_suffix)
	if len(attack_code) > max_contract_size:
	raise ValueError(
	f"Code size {len(attack_code)} exceeds maximum code size {max_contract_size}"
	)

[LouisTsai-Csie]

I might go with the following approach for consistency now, since the remaining benchmarks use it as well.

However, we could add this refactoring for all the assertions later in this issue

 assert len(attack_code) <= max_code_size

[jochem-brouwer]

I get the idea but I would set this up differently. We have code_prefix and code_suffix so we know that we can add at most max_code_size - len(code_prefix) - len(code_suffix) bytes. I'd keep incrementing some number here and then let CLZ work on 2^256 - 1 >> i % 256. This i increments each round and will thus right shift the values such that CLZ yields a different value. Note that for each CLZ you add you should check Op.CLZ(value) + Op.POP if this length does not exceed the max size (else break). This length is not constant because it will depend on how many bytes we are pushing (to push 2^256-1 need PUSH32, and for 1 need PUSH1)

[LouisTsai-Csie]

@jochem-brouwer Thanks for your review, I've updated accordingly! Please let me know if the change is good to you.

[marioevz]

Amazing implementation, thanks!

[marioevz]

I think this needs a careful rebase since I tried rebasing locally and the merge messed up the test, @LouisTsai-Csie could you try rebasing to latest main and see that it works? thanks!

[LouisTsai-Csie]

@marioevz I did not see any conflict from my side, but I still rebase to the latest changes. Let's see if this works.