Jack Grigg

> This could change if we had an opaque `Value` type We now have this in #598.

I've figured out the problem. `ViewingKey::read` reads two components from the encoding (commitments to fixed columns, and the permutation verifying key), and reconstructs the `ConstraintSystem` from the provided `Params`: https://github.com/zcash/halo2/blob/9617336d46a18f3949260731d02bd711fba9d863/halo2_proofs/src/plonk.rs#L64-L70...

In a pairing, @ebfull and I decided that for `halo2_proofs 0.1.0` we will remove the `VerifyingKey::write` and `VerifyingKey::read` APIs as we do not have time to fix this before then....

I currently believe that addressing this issue would resolve the performance problem noted in https://github.com/zcash/halo2/issues/418#issuecomment-989568648.

Actually, having looked more closely at https://github.com/zcash/halo2/issues/418#issuecomment-989568648, I think it's being caused by the fact that we don't cache rotated polynomials, so if the same (polynomial, rotation) pair is used...

Yep (though I think it's actually `(m-1)*n` IIRC - there's an off-by-one in there of which I always forget the origin). The idea for this issue is to break down...

Could you run a `cargo clean` and then re-run the failed tests with `cargo test --release --doc`?

@narodnik could you retest this on both current master and #334, to see if it is affected by any of the dependency updates since this issue was opened?

This pinned format might also end up being how other implementations of Halo 2 interoperate (e.g. some other frontend that can produce Halo 2 circuits could pass that data to...

I had started working on this change (which is #406) a month and a half ago, but had to put it aside while doing other NU5 work, and forgot to...