zkevm: keccak worst-case

[jsign]

This PR adds a test that builds a block to maximize the number of keccak permutations for a given gas limit (considering the max contract size).

There are two main aspects of the test design.

Find the optimal input size

The metric we care about is gas per permutation, not simply max opcode calls. Although the dynamic cost of KECCAK256 is linear in input length, memory expansion is quadratic, so there is a sweet spot for minimal cost per permutation.

Instead of baking magic numbers, the test does a scan for the optimal cost and then does the attack with it. This is much more transparent on how this optimal length is found, plus it sounds also more future-proof.

Another way of understanding the above is by looking at this chart I created from that same script, with a more detailed output:

The “attack” loop

Once the optimal length is known, I create a loop that drives as many permutations as the block gas limit allows. The loop shouldn't be a tight loop, but quite the opposite -- run as many calls as possible within the max contract size, so the "JUMP"-like gas overhead is amortized as much as possible.

The general structure is:

JUMPDEST
 (PUSH+PUSH+KECCAK256+POP)
 ...
PUSH0
JUMP

Note that for 36M you can fit the (....) without a loop since the max you can add fits within 24KiB contract limit. But for bigger gas limits, you run short with 24KiB and need the loop!

Max permutations per gas limit

The test runs with different gas limits. Here are the numbers of permutations generated for each limit:

• 30M -> 1_408_440 perms
• 60M -> 2_348_622 perms
• 100M -> 3_915_972 perms
• 300M -> 11_754_358 perms

Note: The input now is 0x00s, but it could be different. I think ideal test filling should be deterministic, so if any implementation wants to overoptimize, it can always do it. We can wait and adjust if necessary.

---

zkVM cycles:

• 36m gas -> 623 million cycles
• 60m gas -> 1 billion cycles
• 100m gas -> 1.7 billion cycles
• 300m gas -> 5.2 billion cycles

[jsign]

To clarify a bit more here. When doing Op.SHA3(0, ..) the generated opcodes include a PUSH1 0 which could save 1 gas if used PUSH0.

Note a huge deal, but just noticed that.