Ivo Kubjas

See the https://pkg.go.dev/github.com/consensys/[email protected]/std/math/uints package which wraps the `frontend.Variable` type to allow byte operations

It would particularly help in https://github.com/Consensys/gnark-crypto/blob/master/ecc/bn254/mpcsetup/mpcsetup.go#L275 as we only read everything to compute a random linear combination. And in Groth16 Phase1 we provide 4 input slices. But I guess there...

I dunno yet how it would look, my first idea was a la: ```go type LazyVector struct { *os.File pointerLoc int } ``` and then have methods `Len()`, `Get(i)`, `Append()`...

Another option is to use arrays instead of slices. Then gnark knows how many variables to expect and everything just works: ```go type Circuit struct { Vals [5]frontend.Variable } func...

Nope, they are different and incompatible circuits. Usually if you want to have a variable-length input, then you have to implement a circuit which has a maximum-length input and then...

In essence I understand your proposal (the MSM is provided precomputed). But I have initial intuition that this is not safe approach in general as it potentially introduces malleability in...

> [@ivokub](https://github.com/ivokub) In my case, I prefer the pre-computation pattern to embedding patterns directly in the circuit, because compilation is slower than MSM. > > To be honest, I still...

> [@ivokub](https://github.com/ivokub) In my case, I prefer the pre-computation pattern to embedding patterns directly in the circuit, because compilation is slower than MSM. But the thing is that circuit compilation...

Indeed - in case of a single verifier which trusts that the MSM was correctly computed, then it should be safe.

Thanks for the proposal - it seems interesting. I don't however recall many real-life implementations using this technique. Are there some more recent results showing the deficiencies of subversion resistant...