✨ feat(tests): zkEVM - Add parametrized opcodes and gas limits

[raxhvl]

🗒️ Description

The PR extends #1456 to add dynamic gas_limits and opcodes.

🔗 Related Issues

#1453

How it works

execution-spec-tests/tests/zkevm/test_proof_size.py

Lines 2 to 9 in 9668583

	A series of stress tests that assess the ability of a specific
	opcode or precompile to process large proofs in a block.
	Large proofs are created by deploying contracts with
	maximum allowed bytecode.
	Then, a pacman contract (ᗧ•••) consumes the maximum possible number of
	proofs in a block with a given gas limit using an opcode or precompile.

Configuring gas limits

execution-spec-tests/tests/zkevm/test_proof_size.py

Line 37 in 858af44

GAS_LIMITS = [30_000_000, 60_000_000, 100_000_000, 300_000_000]

Configuring opcodes

execution-spec-tests/tests/zkevm/test_proof_size.py

Lines 80 to 91 in 9668583

	CONSUMERS = [
	Consumer(
	opcode=Op.EXTCODEHASH,
	gas_cost=2603, # PUSH20[3] + EXTCODEHASH[2600]
	generate_bytecode=lambda proof: Op.EXTCODEHASH(proof),
	),
	Consumer(
	opcode=Op.EXTCODESIZE,
	gas_cost=2603, # PUSH20[3] + EXTCODESIZE[2600]
	generate_bytecode=lambda proof: Op.EXTCODESIZE(proof),
	),
	]

What's pending

As described in #1456, the pre state size is huge. To solve that, I experimented deploying contracts in the same block, it had the following issues:

1. The code for deploying large contracts gets messy quickly, and it consumes large amounts gas due to high memory usage.
2. I adjusted gas limit to offset the contract deployment costs, but I think it skews the benchmark a bit if we do it in the same block.

I was wondering if there is a way to persist data between blocks in the test.

If this approach sounds okay, then I can extend this to include precompiles.

Even after deploying contracts in a separate blocks, communicating the deployed addresses to be consumed would need more work.

cc: @jsign

Output

tests/zkevm/test_proof_size.py::test_via_opcode[fork_Cancun-blockchain_test-EXTCODEHASH-gas_limit_30000000] FILLED                                               [ 1/16]
tests/zkevm/test_proof_size.py::test_via_opcode[fork_Cancun-blockchain_test-EXTCODEHASH-gas_limit_60000000] FILLED                                               [ 2/16]
tests/zkevm/test_proof_size.py::test_via_opcode[fork_Cancun-blockchain_test-EXTCODEHASH-gas_limit_100000000] FILLED                                              [ 3/16]
tests/zkevm/test_proof_size.py::test_via_opcode[fork_Cancun-blockchain_test-EXTCODEHASH-gas_limit_300000000] FILLED                                              [ 4/16]
tests/zkevm/test_proof_size.py::test_via_opcode[fork_Cancun-blockchain_test-EXTCODESIZE-gas_limit_30000000] FILLED                                               [ 5/16]
tests/zkevm/test_proof_size.py::test_via_opcode[fork_Cancun-blockchain_test-EXTCODESIZE-gas_limit_60000000] FILLED                                               [ 6/16]
tests/zkevm/test_proof_size.py::test_via_opcode[fork_Cancun-blockchain_test-EXTCODESIZE-gas_limit_100000000] FILLED                                              [ 7/16]
tests/zkevm/test_proof_size.py::test_via_opcode[fork_Cancun-blockchain_test-EXTCODESIZE-gas_limit_300000000] FILLED                                              [ 8/16]

✅ Checklist

• All: Set appropriate labels for the changes.
• All: Considered squashing commits to improve commit history.

[kevaundray]

opcodes/precompiles wouldn't process proofs.

These tests to be added should be seen as regular blockchain tests that so happen to be edge cases that we want to test in a zkEVM. In that sense, they should not be any different than other blockchain tests

[raxhvl]

Agreed. These tests are no different. By "process" I mean making these opcode / precompile to take the bytecode as input, nothing more.

[kevaundray]

The code for deploying large contracts gets messy quickly, and it consumes large amounts gas due to high memory usage.

I think we want to just deploy N distinct contracts over as many blocks as needed, where N is the amount of EXTCODEHASH opcodes that I can fit into a block.

Then in the subsequent blocks, we want to call 1 EXTCODEHASH. Then in the next block, we want to call 2 EXTCODEHASH, all the way upto N EXTCODEHASH.

I adjusted gas limit to offset the contract deployment costs, but I think it skews the benchmark a bit if we do it in the same block.

We would be ignoring those blocks that are used to deploy contracts, because we only care about the blocks that are calling the EXTCODEHASH. But from the perspective of the execution spec tests, its just a blockchain test where we deploy N contracts and then call EXTCODEHASH/SIZE in subsequent blocks.

ie nothing to do with proofs should be mentioned here and these tests can be used in a normal client too

[kevaundray]

EXTCODEHASH requires a "setup" phase.

This may not be the case for all opcodes/precompiles we want to test.

For the Add opcode for example, we can have block 1, do as many Adds as possible to fill up the block.

[raxhvl]

Makes sense. The code can be tweaked slightly to skip setup phase.

[jsign]

Uhm, my take is that we should:

• Rename the testing file to tests_worst_cases.py
• Leave the original test_worst_bytecode as it is (maybe generalizing only gas limit and related, but not the opcode generalization)
• Create a separate new test test_repeated_execution with this new cases of repeated opcodes or precompiles.

My argument on separating tests in the second and third bullets is exactly because the second requires some complicated setup, compared to opcode/precompile repetition being mostly stateless. While you could make that conditional, feels a bit complex and can be confusing (i.e., technically you can create a single test with all the tests in the repo and make it conditional :P ).

To generalize the setup to avoid big pre-alloc @marioevz suggested and idea here.

cc @kevaundray @raxhvl

[raxhvl]

Thanks @jsign :) I misunderstood bullets (1) and (2) to be the same test.