Repair U32Table's Permutation Arguments about triton-vm

[jan-ferdinand]

I currently believe the issue to be due to the difference of updating the running products between the processor and the u32 coprocessor.

In the Processor Table, the running product of any u32 instruction – say, and – is updated if and only if the current instruction ci matches that instruction. If ci equals some other u32 instruction – say, lt – then the running product for and is not updated.

However, the U32 Table has no knowledge about the instruction thas was executed by the processor. All 5 running products are being updated whenever the indicator idc is 1. Naturally, this creates a discrepancy.

It is not a viable solution to simply update all running sums in the Processor Table whenever ci corresponds to any u32 instruction, since a malicious prover could swap the legitimate result of the instruction with that of some other u32 instruction, e.g., replace and(10, 11) = 10 with 01 = xor(10, 11).

It might be necessary to carry the current instruction over to the U32 Table.

Relates to #8 somewhat less loosely now.

[jan-ferdinand]

Additionally, if the processor never executes any u32 instruction, the running product of any of the 5 Permutation Aguments will equal the respective (prover-chosen) initial in the Processor Table, whereas the U32 Table will have no rows. #10 fixes this.

[jan-ferdinand]

Closing in anticipation of #10.