Mega "simple exceptions testing" issue

[OlivierBBB]

Main point

We should create tests that trigger, for every single opcode, every single possible exception (including aborting conditions, failure conditions for CREATE's, issues with precompiles.)

Details

• make tables with one row per opcode and one column per exception and mark a cell iff that opcode can trigger that exception
• write tests that trigger the relevant exception for every such cross

List of ZKEVM exceptions

SUX
SOX
MXPX
OOGX
RDCX
JUMPX
STATICX
SSTOREX
ICPX
MAXCSX
OPCX

Accessing delta and alpha

  public void bla(OpCode opCode) {
    opCode.getData().stackSettings.delta(); // number of items that we pop, ∈ {0, 1, ..., 16 or 17}
    opCode.getData().stackSettings.alpha(); // number of items that we add to the stack; the only thing that matter is whether $\alpha > \delta$ ? Also $\alpha - \delta \leq 1$
  }

stackUnderflowException

If an instruction removes $\delta$ many items from the stack there should be $\delta$ many tests where you initially do $0, 1, \dots, \delta - 1$ initial pushes before triggering the opcode.

PUSH1 01
PUSH1 02
PUSH1 03
PUSH1 04
SOME_OPCODE

You can access $\delta$ through the OpCodeData. As suggested by @lorenzo.gentile you can batch these considering the set of all instructions with $\delta = \delta_0$ and go through all positive values of $\delta_0$. We can also include the final one (which won't raise an exception.)

ArgumentStream1 streamOfDeltas  = List.of(0, 1, ...);
ArgumentStream1 streamOfOpCodes = [just walk through all the opcodes and keep those opcodes that have this delta];

stackOverflowException

You just have to do something like

for (i = 0; i < 1024; i++) {
	program.push(i);
}
program.op(OpCode.BLA);

Almost unique instructions

Those two should essentially be already done (though checking it won't hurt):

• RDCX: can only be triggered by RETURNDATACOPY (OOB)
• JUMPX: can only be triggered by JUMP and JUMPI (OOB)

Those would be new:

• STATICX: can only be triggered by CALL, SSTORE, SELFDESTRUCT, LOG's, CREATE(2),
• SSTOREX: can only be triggered by SSTORE
• ICPX: can only be triggered by RETURN during a deployment
• MAXCSX: can only be triggered by RETURN during a deployment (we may already have stuff in place for this in OOB)
• OPCX: can only be triggered by INVALID and any byte that isn't an opcode.

[lorenzogentile404]

Note: go through instruction handling of the HUB section of the spec. Some OpCode have specific exceptions, while others are shared (about 11 in total and 6 shared). The tests should be the minimal ones such that they trigger the relevant exception. CALL, RETURN and CREATE may be tricky.

[lorenzogentile404]

• SUX
• SOX
• MXPX
• OOGX
• RDCX
• JUMPX
• STATICX
• SSTOREX
• ICPX
• MAXCSX
• OPCX

[letypequividelespoubelles]

Do we want tests that trigger several exception, to be sure we trigger the right tracedException one ?

[lorenzogentile404]

@letypequividelespoubelles that seems a good idea, as a second step. @OlivierBBB what do you think?