Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign up`crates.io` release checklist #50
Comments
…dels Contributes to scipr-lab#50.
…ine}Curve traits with One/Zero traits from num_traits. - contributes to scipr-lab#50, - depends on scipr-lab#53 and builds on it, - due to coherence & requirements of `num_traits::{Zero, One}` to implement `std::ops::Add<Self, ..>` and (resp.) `std::ops::Mul<Self, ..>`, I've had to replace the afferent `impl<'a, P: ..> (Add|Mul)<&'a Self> for Group(Affine|Projective)<P>` by direct implementations on `Self`, - I did not have to fight the borrow checker for this conversion => I think this hints arithmetic operations are called in contexts where the operand is owned, - hence should this end up on a merge track, we may want to open an issue to convert the `impl<'a, P:..> (Neg|Sub|..)<&'a Self> for ..<P>` trait usage to direct `impl<P:..> (Neg|Sub|..)<Self> for ..<P>` - the `impl AddAssign for GroupAffine<P>` in curves/models/short_weierstrass_jacobian.rs is provided to fit trait bounds, and without any guarantee of suitability for any particular purpose - and that, even though I don't think it's used.
…ine}Curve traits with One/Zero traits from num_traits. - contributes to scipr-lab#50, - depends on scipr-lab#53 and builds on it, - due to coherence & requirements of `num_traits::{Zero, One}` to implement `std::ops::Add<Self, ..>` and (resp.) `std::ops::Mul<Self, ..>`, I've had to replace the afferent `impl<'a, P: ..> (Add|Mul)<&'a Self> for Group(Affine|Projective)<P>` by direct implementations on `Self`, - I did not have to fight the borrow checker for this conversion => I think this hints arithmetic operations are called in contexts where the operand is owned, - hence should this end up on a merge track, we may want to open an issue to convert the `impl<'a, P:..> (Neg|Sub|..)<&'a Self> for ..<P>` trait usage to direct `impl<P:..> (Neg|Sub|..)<Self> for ..<P>` - the `impl AddAssign for GroupAffine<P>` in curves/models/short_weierstrass_jacobian.rs is provided to fit trait bounds, and without any guarantee of suitability for any particular purpose - and that, even though I don't think it's used.
…ine}Curve traits with One/Zero traits from num_traits. - contributes to scipr-lab#50, - depends on scipr-lab#53 and builds on it, - due to coherence & requirements of `num_traits::{Zero, One}` to implement `std::ops::Add<Self, ..>` and (resp.) `std::ops::Mul<Self, ..>`, I've had to replace the afferent `impl<'a, P: ..> (Add|Mul)<&'a Self> for Group(Affine|Projective)<P>` by direct implementations on `Self`, - I did not have to fight the borrow checker for this conversion => I think this hints arithmetic operations are called in contexts where the operand is owned, - hence should this end up on a merge track, we may want to open an issue to convert the `impl<'a, P:..> (Neg|Sub|..)<&'a Self> for ..<P>` trait usage to direct `impl<P:..> (Neg|Sub|..)<Self> for ..<P>` - the `impl AddAssign for GroupAffine<P>` in curves/models/short_weierstrass_jacobian.rs is provided to fit trait bounds, and without any guarantee of suitability for any particular purpose - and that, even though I don't think it's used.
…dels Contributes to scipr-lab#50.
…ine}Curve traits with One/Zero traits from num_traits. - contributes to scipr-lab#50, - depends on scipr-lab#53 and builds on it, - due to coherence & requirements of `num_traits::{Zero, One}` to implement `std::ops::Add<Self, ..>` and (resp.) `std::ops::Mul<Self, ..>`, I've had to replace the afferent `impl<'a, P: ..> (Add|Mul)<&'a Self> for Group(Affine|Projective)<P>` by direct implementations on `Self`, - I did not have to fight the borrow checker for this conversion => I think this hints arithmetic operations are called in contexts where the operand is owned, - hence should this end up on a merge track, we may want to open an issue to convert the `impl<'a, P:..> (Neg|Sub|..)<&'a Self> for ..<P>` trait usage to direct `impl<P:..> (Neg|Sub|..)<Self> for ..<P>` - the `impl AddAssign for GroupAffine<P>` in curves/models/short_weierstrass_jacobian.rs is provided to fit trait bounds, and without any guarantee of suitability for any particular purpose - and that, even though I don't think it's used.
…ine}Curve traits with One/Zero traits from num_traits. - contributes to scipr-lab#50, - depends on scipr-lab#53 and builds on it, - due to coherence & requirements of `num_traits::{Zero, One}` to implement `std::ops::Add<Self, ..>` and (resp.) `std::ops::Mul<Self, ..>`, I've had to replace the afferent `impl<'a, P: ..> (Add|Mul)<&'a Self> for Group(Affine|Projective)<P>` by direct implementations on `Self`, - I did not have to fight the borrow checker for this conversion => I think this hints arithmetic operations are called in contexts where the operand is owned, - hence should this end up on a merge track, we may want to open an issue to convert the `impl<'a, P:..> (Neg|Sub|..)<&'a Self> for ..<P>` trait usage to direct `impl<P:..> (Neg|Sub|..)<Self> for ..<P>` - the `impl AddAssign for GroupAffine<P>` in curves/models/short_weierstrass_jacobian.rs is provided to fit trait bounds, and without any guarantee of suitability for any particular purpose - and that, even though I don't think it's used.
…ine}Curve traits with One/Zero traits from num_traits. - contributes to scipr-lab#50, - depends on scipr-lab#53 and builds on it, - due to coherence & requirements of `num_traits::{Zero, One}` to implement `std::ops::Add<Self, ..>` and (resp.) `std::ops::Mul<Self, ..>`, I've had to replace the afferent `impl<'a, P: ..> (Add|Mul)<&'a Self> for Group(Affine|Projective)<P>` by direct implementations on `Self`, - I did not have to fight the borrow checker for this conversion => I think this hints arithmetic operations are called in contexts where the operand is owned, - hence should this end up on a merge track, we may want to open an issue to convert the `impl<'a, P:..> (Neg|Sub|..)<&'a Self> for ..<P>` trait usage to direct `impl<P:..> (Neg|Sub|..)<Self> for ..<P>` - the `impl AddAssign for GroupAffine<P>` in curves/models/short_weierstrass_jacobian.rs is provided to fit trait bounds, and without any guarantee of suitability for any particular purpose - and that, even though I don't think it's used.
…ine}Curve traits with One/Zero traits from num_traits. - contributes to scipr-lab#50, - depends on scipr-lab#53 and builds on it, - due to coherence & requirements of `num_traits::{Zero, One}` to implement `std::ops::Add<Self, ..>` and (resp.) `std::ops::Mul<Self, ..>`, I've had to replace the afferent `impl<'a, P: ..> (Add|Mul)<&'a Self> for Group(Affine|Projective)<P>` by direct implementations on `Self`, - I did not have to fight the borrow checker for this conversion => I think this hints arithmetic operations are called in contexts where the operand is owned, - hence should this end up on a merge track, we may want to open an issue to convert the `impl<'a, P:..> (Neg|Sub|..)<&'a Self> for ..<P>` trait usage to direct `impl<P:..> (Neg|Sub|..)<Self> for ..<P>` - the `impl AddAssign for GroupAffine<P>` in curves/models/short_weierstrass_jacobian.rs is provided to fit trait bounds, and without any guarantee of suitability for any particular purpose - and that, even though I don't think it's used.
…ine}Curve traits with One/Zero traits from num_traits. - contributes to scipr-lab#50, - depends on scipr-lab#53 and builds on it, - due to coherence & requirements of `num_traits::{Zero, One}` to implement `std::ops::Add<Self, ..>` and (resp.) `std::ops::Mul<Self, ..>`, I've had to replace the afferent `impl<'a, P: ..> (Add|Mul)<&'a Self> for Group(Affine|Projective)<P>` by direct implementations on `Self`, - I did not have to fight the borrow checker for this conversion => I think this hints arithmetic operations are called in contexts where the operand is owned, - hence should this end up on a merge track, we may want to open an issue to convert the `impl<'a, P:..> (Neg|Sub|..)<&'a Self> for ..<P>` trait usage to direct `impl<P:..> (Neg|Sub|..)<Self> for ..<P>` - the `impl AddAssign for GroupAffine<P>` in curves/models/short_weierstrass_jacobian.rs is provided to fit trait bounds, and without any guarantee of suitability for any particular purpose - and that, even though I don't think it's used.
…ine}Curve traits with One/Zero traits from num_traits. - contributes to #50, - depends on #53 and builds on it, - due to coherence & requirements of `num_traits::{Zero, One}` to implement `std::ops::Add<Self, ..>` and (resp.) `std::ops::Mul<Self, ..>`, I've had to replace the afferent `impl<'a, P: ..> (Add|Mul)<&'a Self> for Group(Affine|Projective)<P>` by direct implementations on `Self`, - I did not have to fight the borrow checker for this conversion => I think this hints arithmetic operations are called in contexts where the operand is owned, - hence should this end up on a merge track, we may want to open an issue to convert the `impl<'a, P:..> (Neg|Sub|..)<&'a Self> for ..<P>` trait usage to direct `impl<P:..> (Neg|Sub|..)<Self> for ..<P>` - the `impl AddAssign for GroupAffine<P>` in curves/models/short_weierstrass_jacobian.rs is provided to fit trait bounds, and without any guarantee of suitability for any particular purpose - and that, even though I don't think it's used.
This comment has been minimized.
This comment has been minimized.
|
We should probably add serialization for proving/verification keys and proofs :) |
This comment has been minimized.
This comment has been minimized.
|
Yes, though that's gated on serialization for field and group elements =) |
This comment has been minimized.
This comment has been minimized.
|
About There is discussion on making all the I think const generics have progressed far enough for this to work on nightly, but when they land nobody knows.
Also serde works without std or even alloc it appears: https://serde.rs/no-std.html |
This comment has been minimized.
This comment has been minimized.
|
I think a simpler method might be to just add our own If in the future |
This comment has been minimized.
This comment has been minimized.
|
Cool. I'd suspect some crate supplying no_std |
algebra:ToBytesandFromBytesno_stdcompatible (WIP in #76).Field,Group, and{Projective,Affine}Curvetraits withOne/Zerotraits fromnum_traits. (Done in #54)impl Add<Self> for Self(besides justimpl Add<&Self> for Self>). (Done in #53)AffineCurveelements (See #51; done in #73).bench-utils:tracing.algebrabehind atracefeature?r1cs-core:ConstraintSystem,ConstraintVar,LinearCombination, andVariableAPIs as per #34 and #43ConstraintSystemtoR1CS.ConstraintSystem::enter_nsandConstraintSystem::leave_nstoConstraintSystem::ns. Additionally, refactorNamespacestruct to be just a guard struct which automatically decrements the scope when dropped.r1cs-std:FieldVar,GroupVar, and other variable structs generic overCS: ConstraintSystem<F>as well. This enables getting rid ofcs: CSarguments to various functions likeadd,mul, etc. In turn, this allowsimpl Add<Self> for FieldVar<...>impls.impl {Add, Mul}<Self::Constant> for FieldVar<...>, impls with the constants. (This might not be possible due to coherence rules, might have to useenum-based approach)UInt{8, 16, 32, 64}.EqGadget,ToBytesGadgetare less of a pain to implement.FpGadgets.groth16+gm17:marlincrypto-primitives: