Add ZK opcodes definition

[AurelienFT]

#615

VM PR : FuelLabs/fuel-vm#870

Before requesting review

• I have reviewed the code myself

After merging, notify other teams

[Add or remove entries as needed]

• Rust SDK
• Sway compiler
• Platform documentation (for out-of-organization contributors, the person merging the PR will do this)
• Someone else?

[AurelienFT]

@rymnc thank you for pointing incoherences :)

[rymnc]

LGTM, small nit

[Dentosal]

Panic conditions must be described as well. The operations panic at least in cases where mode-selection arguments are not from the list of available modes. Also outputs to memory require that memory to be writeable. Likely there are also cases where the argument values etc. can also be incorrect, in which case the operation should fail. Consider allowing the use of $err in those cases.

[AurelienFT]

@Dentosal I have added panic cases. However, I don't make use of $err because I don't really understand in which cases it's better to use that than just make the call fail.
Following the docs here and a comment on the VM, it seems to be used only on ALU and for me on these opcodes there is no use case for that.

[Dentosal]

Following the docs here and a comment on the VM, it seems to be used only on ALU and for me on these opcodes there is no use case for that.

Not only for ALU, see $err usage here: https://github.com/FuelLabs/fuel-specs/blob/master/src/fuel-vm/instruction-set.md#eck1-secp256k1-signature-recovery

The use case here would be doing operations on user-provided, possibly invalid EC points without panicing (e.g. InvalidEllipticCurvePoint). If you think this is not a relalistic use case, I'm fine with only panicking modes being available.

[AurelienFT]

I don't think it's expected and I don't see any logic of modifying the input to retry directly designed in code. Also if the point isn't corrected created in the VM implementation then the addition can't be tried and the code will be more difficult and I think users whould except a panic and this will help them debugging with an explicit reason.