David Wong
David Wong
No because poly-commitment is a dependency of kimchi, and so you'd get a dependency cycle if you would do that. I guess there's two solutions: 1. Moving the `KimchiCurve` trait...
We can't do it in a few lines of code for the endo gate because it doesn't place the result in the first three columns. We have to change the...
not super nice to implement it for poseidon as well: https://github.com/o1-labs/proof-systems/pull/632 because if it queues the gate then it will mess up the permutation that links the last zero/generic gate...
also this `eval` function should really be called `linearization`
perhaps something like this: ```rust struct ChunkedPolynomial(Vec); impl ChunkedPolynomial { fn linearize(&self, chunk_size: usize, x: F) -> DensePolynomial } ``` with a function to convert a polynomial into a chunked...
playing with it here: https://github.com/o1-labs/proof-systems/commit/a3f9537f87f90781d7af1fd9e2ebff7886d4463d
I think I narrowed the issue: ``` other: [Fp256(BigInteger256([0, 0, 0, 0]))] [Fp256(BigInteger256([0, 0, 0, 0]))] orign: [] [] ``` the PCS doesn't like it when I pass [0] instead...
closes https://github.com/o1-labs/proof-systems/issues/231
added an `AbsorbableScalarField` trait in the last commit (for lack of a better name)
sounds like I can't get consensus on this PR. I still believe it's the best route, but at the very least I'll leave this open for when I have time...