Zkeys fail to be verified right after generations with custom R1CS and witness

[Zekt]

We are developing a DSL called Keelung and want it to be Snarkjs-compatible, we've been able to successfully generate a R1CS file quad.r1cs and a witness quad.wtns, which we can check that they are valid by r1cs info and wtns check:

$ snarkjs r1cs info quad.r1cs
[INFO]  snarkJS: Curve: bn-128
[INFO]  snarkJS: # of Wires: 7
[INFO]  snarkJS: # of Constraints: 4
[INFO]  snarkJS: # of Private Inputs: 1
[INFO]  snarkJS: # of Public Inputs: 3
[INFO]  snarkJS: # of Labels: 7
[INFO]  snarkJS: # of Outputs: 0
$ snarkjs wtns check quad.r1cs quad.wtns
[INFO]  snarkJS: WITNESS CHECKING STARTED
[INFO]  snarkJS: > Reading r1cs file
[INFO]  snarkJS: > Reading witness file
[INFO]  snarkJS: ----------------------------
[INFO]  snarkJS:   WITNESS CHECK
[INFO]  snarkJS:   Curve:          bn128
[INFO]  snarkJS:   Vars (wires):   7
[INFO]  snarkJS:   Ouputs:         0
[INFO]  snarkJS:   Public Inputs:  3
[INFO]  snarkJS:   Private Inputs: 1
[INFO]  snarkJS:   Labels:         7
[INFO]  snarkJS:   Constraints:    4
[INFO]  snarkJS:   Custom Gates:   false
[INFO]  snarkJS: ----------------------------
[INFO]  snarkJS: > Checking witness correctness
[INFO]  snarkJS: WITNESS IS CORRECT
[INFO]  snarkJS: WITNESS CHECKING FINISHED SUCCESSFULLY

But right after generating a zkey with groth16 setup, zkey verify fails:

$ snarkjs groth16 setup quad.r1cs pot12_final.ptau circuit_0000.zkey
$ snarkjs zkey verify quad.r1cs pot12_final.ptau circuit_0000.zkey
[INFO]  snarkJS: Reading r1cs
[INFO]  snarkJS: Reading tauG1
[INFO]  snarkJS: Reading tauG2
[INFO]  snarkJS: Reading alphatauG1
[INFO]  snarkJS: Reading betatauG1
[INFO]  snarkJS: Circuit hash: 
                de188864 150e1d25 067cb227 05def0ab
                68632774 2fe3c97f 529600b0 f8e85762
                b764a73e 04979cbb 15023fd3 e8ab47c1
                333601b6 2cd85e05 992cbde4 fdf88bd2
[ERROR] snarkJS: INVALID:  Invalid L section size

R1CS and witness generated with Circom in the README on the other hand generates a zkey that can be verified successfully. It seems to me that verifying after generating a new zkey should always work because verifying in this case seems to be comparing two identical zkeys (https://github.com/iden3/snarkjs/blob/master/src/zkey_verify_fromr1cs.js#L23). I assume there's a bug when generating or reading the zkey files.

This is our quad.r1cs in hex:

00000000: 7231 6373 0100 0000 0300 0000 0100 0000  r1cs............
00000010: 4000 0000 0000 0000 2000 0000 0100 00f0  @....... .......
00000020: 93f5 e143 9170 b979 48e8 3328 5d58 8181  ...C.p.yH.3(]X..
00000030: b645 50b8 29a0 31e1 724e 6430 0700 0000  .EP.).1.rNd0....
00000040: 0000 0000 0300 0000 0100 0000 0700 0000  ................
00000050: 0000 0000 0400 0000 0200 0000 0402 0000  ................
00000060: 0000 0000 0100 0000 0000 0000 0100 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0300 0000  ................
00000090: 0300 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0600 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0700 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0100 0000 0100 0000 0000 0000 0000 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0100 0000 0400 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0100 0000 0500 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000170: 0000 0000 0000 0000 0100 0000 0500 0000  ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001a0: 0100 0000 0400 0000 0000 0000 0000 0000  ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001c0: 0000 0000 0000 0000 0100 0000 0600 0000  ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0100 0000 0200 0000 0000 0000 0000 0000  ................
00000200: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000210: 0000 0000 0000 0000 0100 0000 0400 0000  ................
00000220: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000230: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000240: 0100 0000 0700 0000 0000 0000 0000 0000  ................
00000250: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000260: 0000 0000 0000 0000 0300 0000 4000 0000  ............@...
00000270: 0000 0000 0000 0000 0000 0000 0100 0000  ................
00000280: 0000 0000 0200 0000 0000 0000 0300 0000  ................
00000290: 0000 0000 0400 0000 0000 0000 0500 0000  ................
000002a0: 0000 0000 0600 0000 0000 0000 0700 0000  ................
000002b0: 0000 0000 0a                             .....

And quad.wtns in hex:

00000000: 7774 6e73 0200 0000 0200 0000 0100 0000  wtns............
00000010: 2800 0000 0000 0000 2000 0000 0100 00f0  (....... .......
00000020: 93f5 e143 9170 b979 48e8 3328 5d58 8181  ...C.p.yH.3(]X..
00000030: b645 50b8 29a0 31e1 724e 6430 0700 0000  .EP.).1.rNd0....
00000040: 0200 0000 0001 0000 0000 0000 0100 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0100 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0200 0000  ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 1600 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0100 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0100 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0100 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0000 0000 0700 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0a         .............

For more info, they are generated from our example quad in Quad.hs.

[Zekt]

Closing as we found it's the problem that keys of the coeffs should start at 1 (cause 0 is reserved for ONE signal).