-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Arith
trait
#162
Refactor Arith
trait
#162
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt a bit about the Dummy
impls. And also about the RUNNING
flag.
The rest seems a really good refactor! Thanks for it!
folding-schemes/src/arith/ccs.rs
Outdated
impl<F: PrimeField> Arith<F> for CCS<F> { | ||
fn eval_relation(&self, z: &[F]) -> Result<Vec<F>, Error> { | ||
impl<F: PrimeField> CCS<F> { | ||
pub fn eval_core(&self, z: &[F]) -> Result<Vec<F>, Error> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May I ask why we changed the name to eval_core
or at least what core
means within this context?
I think if we make the fn pub
would be nice to have some minimal docs where we relate the core
thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about eval_z
(or eval_at_z
)? Will also add the docs!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both work for me. Definitely better than core
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice abstractions! Just left a couple of small suggestions regarding extending the comments to make it faster to understand the abstractions to the reader.
LGTM!
@winderica can we merge this and start merging the cascade of PRs that depends on this one?? |
woah sudden rush @CPerezz hehe. Well, I approved but left a couple of suggestions, and the other PRs will need reviews too. For this one it's missing your approval :P |
Sorry for the delay! The reviews should be addressed now :) |
ahh 😳 no worries, there has been no delay 🙏 |
95aeed3
to
1d03b67
Compare
Are @arnaucube 's suggestions addressed or discussed? Ping once it's done and we can merge! :) |
I understand this as an approve (?) (although the approval check is missing) Regarding my suggestions, they are (greatly) addressed in the last commits, yes ^^ |
f1d8241
As the second part of #145, this PR improves the design of the
Arith
trait with a pair of generic witness and committed instance. TheDummy
trait is also introduced, providing a unified interface for thedummy
method.Specifically, unlike the previous
Arith
that can only handlez
(a vector of field elements) when checking satisfiability, nowArith
andArithGadget
allow for taking the witnessw
and instanceu
as input, wherew
andu
are bounded by generic typesW
andU
:W
andU
are vectors of field elements, the behavior becomes the same as the previous one.W
andU
are Nova or ProtoGalaxy instances,Arith
andArithGadget
are able to replace theRelaxedR1CS
andRelaxedR1CSGadget
.W
andU
are CCS instances, thereby replacing{CCCS, LCCCS}::check_relation
andLCCCSCheckerGadget
.This is useful because in #145, we will build a generic decider circuit that essentially runs IVC.Verify (including
ArithGadget::enforce_relation
and commitment verification) in-circuit without knowing which types of folding scheme, witness, and committed instances are being used.