feat(tests): additional test cases for eip-7939

[spencer-tb]

Extra Test Cases EIP-7939

Count leading zeros (CLZ) opcode

Initcode Context

• From CODECOPY / EXTCODECOPY - feat(tests): add codecopy and extcodecopy for clz opcode #1858
• Contract creation transaction - feat(tests): add initcode context extra test for clz opcode #1831
• Contract creation via CREATE & CREATE2 - feat(tests): add initcode context extra test for clz opcode #1831

Execution Context

• CALL, STATICCALL, DELEGATECALL, CALLCODE - feat(tests): add call operation test case for CLZ #1829
• setCode transaction (eip-7702) - feat(tests): add eip7702 test case for clz opcode #1853

Gas Cost

• Not enough gas - feat(tests): add test for CLZ opcode with varying gas costs #1859
• Exact gas cost (5 unit) - Implementation
• Extra gas - feat(tests): add test for CLZ opcode with varying gas costs #1859
• Short by N, N = 3 - feat(tests): add test for CLZ opcode with varying gas costs #1859

Benchmark

• ZK- proving time - feat(benchmark): add clz opcode test case #1845
• Execution time for client - feat(benchmark): add clz opcode test case #1845

New Opcode

• Fork transition test - Implementation
• Execution succeed on Osaka but fail on Prague - Implementation

0x1e Opcode

• jump / jumpi into opcode should fail - feat(tests): add jump operation test case for CLZ #1824
• jump / jumpi into the jumpdest in front of the bytecode should work - feat(tests): add jump operation test case for CLZ #1824
• Implement by the wrong byte

Stack Operation

• PUSH1-32 with same value should have same result - feat(tests): extra stack operation test for CLZ opcode #1821

• Overflows is impossible - feat(tests): extra stack operation test for CLZ opcode #1821

• Underflow cases - Implementation

• Value Boundary - Sufficiently covered by test_clz_opcode_scenarios.

  • Input range from 0 - 2^256 - 1
  • Output range from 0 to 256
  • Other case: 2^8, 2^16, 2^32, …
  • 1 << N, N = 1…256 -> Implementation
  • Trailing zero cases

Please comment any additional test cases or edit the issue and add more.

[LouisTsai-Csie]

Some idea for value boundary test cases

In practice, the two categories below cover the same inputs:

1. Powers of two: 2^8, 2^16, 2^32, …
2. Left-shifts: 1 << N for N = 1 … 256

We already exercise this scenario in the existing implementation (see the current test).

Trailing-zero cases

At the Fusaka hardening meeting I proposed adding patterns such as 00011110000 to ensure CLZ doesn’t count trailing zeros. Because the (1 << bits) test case already ends in a long run of zeros, that requirement is effectively satisfied.

Output range 0 … 256

I haven’t found a clean way to test every possible output. For now, we can only assert that the result always lies within 0 ≤ CLZ(x) ≤ 256.

Full input range

Iterating over every 256-bit value is impractical. A better approach would be to sample randomly across the range, but I’m not sure that fully fits the objectives of this test suite.