David Wong
David Wong
sounds like a better path indeed! Yeah I discussed this with @imeckler as well and it seems to be a bad idea, at least because of the verifier circuit.
Abstract out the `LookupContext` logic in prover as a couple of generic functions that can be reused
Note that I don't think the `LookupContext` struct is necessarily the best approach we can take. It's cleaner than the previous approach for sure, but I think it might make...
I think this is not going to work out of the box, need to spend more time understanding how to get rid of kinds_map and table_kinds
there's a lot more machinery that can be moved to the gate that are making use of lookup (what's in `lookup_kinds`, for example). I think I'm going to spend some...
do you wanna create an issue on the existing selectors part? I'm not sure I understand at this point
Interestingly, I expected being able to create a proof that has prev_challenges of random length (at least as long as it's smaller than our SRS size, why would there be...
have some start here: https://github.com/o1-labs/proof-systems/pull/680/commits/4a95a2d39cbe85cf75cb8bdae7bbfc5ebe21b303. I'm missing some of useful implementations here that we should implement, also I chose a different name to differentiate absorption between different sponges
I think what would be even more useful: * on the prover side you can't put STUFF in a proof if you haven't absorbed it first (so absorb could return...
Note that for the `VerifierIndex`, we end up creating our own version for the OCaml binding: ```rust #[derive(ocaml::IntoValue, ocaml::FromValue, OcamlGen)] pub struct CamlPlonkDomain { pub log_size_of_group: ocaml::Int, pub group_gen: Fr,...
Chunked types is another one that I think should see some refactors. Basically some types are generic and either contain single field elements, or vectors of field elements (chunked evaluations).