crates.io release checklist

[Pratyush]

algebra:

• Move curve specific modules to their own crates. (Reduces compilation time)
• Investigate how to make ToBytes and FromBytes no_std compatible (WIP in no_std for algebra and r1cs-core #76).
• Possibly replace identity functions in Field, Group, and {Projective,Affine}Curve traits with One/Zero traits from num_traits. (Done in Convert identity functions in Field, Group, and {Projective,Affine}Curve traits with One/Zero traits from num_traits. #54)
• Possibly add impl Add<Self> for Self (besides just impl Add<&Self> for Self>). (Done in Add impl Add<Self> for Self, impl Mul<Self> for Self for field mo… #53)
• Add a generic trait for Point Compression for AffineCurve elements (See Add point compression + canonical serialization for AffineCurve elements #51; done in Adds serialization #73).

bench-utils:

• Check whether it can be replaced/integrated with tracing.
• Move into algebra behind a trace feature?

r1cs-core:

• Refactor ConstraintSystem, ConstraintVar, LinearCombination, and Variable APIs as per Refactor ConstraintSystem API #34 and Improve Gadget naming and infrastructure. #43
• Rename ConstraintSystem to R1CS.
• Prefer ConstraintSystem::enter_ns and ConstraintSystem::leave_ns to ConstraintSystem::ns. Additionally, refactor Namespace struct to be just a guard struct which automatically decrements the scope when dropped.

r1cs-std:

• Make FieldVar, GroupVar, and other variable structs generic over CS: ConstraintSystem<F> as well. This enables getting rid of cs: CS arguments to various functions like add, mul, etc. In turn, this allows impl Add<Self> for FieldVar<...> impls.
• impl new impl {Add, Mul}<Self::Constant> for FieldVar<...>, impls with the constants. (This might not be possible due to coherence rules, might have to use enum-based approach)
• standardize UInt{8, 16, 32, 64}.
• Make derive macros so that traits like EqGadget, ToBytesGadget are less of a pain to implement.
• Add support for non-native FpGadgets.

groth16 + gm17:

• Adopt similar code organization as marlin
• Implement proving key, verification key, and proof serialization (blocked on Add point compression + canonical serialization for AffineCurve elements #51).

crypto-primitives:

• Make gadget APIs consistent with above conventions.

[kobigurk]

We should probably add serialization for proving/verification keys and proofs :)

[Pratyush]

Yes, though that's gated on serialization for field and group elements =)

[burdges]

About ToBytes and FromBytes without std

There is discussion on making all the std::io traits work without std or even alloc at rust-lang/rust#48331 so if you think crypto crates just need Read and Write like traits then one could pursue that approach.

I think const generics have progressed far enough for this to work on nightly, but when they land nobody knows.

#![feature(const_generics)]

#[cfg(feature = "std")]
use std::io;

pub trait ToFromBytes: Sized {
    const LENGTH : usize;
    fn to_bytes(&self) -> [u8; Self::LENGTH];
    fn from_bytes(bytes: [u8; Self::LENGTH]) -> Self;

    /// Reads `Self` from `reader`.
    #[cfg(feature = "std")]
    fn read<R: io::Read>(reader: R) -> io::Result<Self> {
        let buf = [0u8; Self::LENGTH];
        reader.read_exact(Self::LENGTH,&mut buf) ?;
        Ok(Self::from_bytes(buf))
    }

    /// Serializes `self` into `writer`.
    #[cfg(feature = "std")]
    fn write<W: io::Write>(&self, writer: W) -> io::Result<()> {
        let buf = self.to_bytes();
        writer.write_all(&buf)
    }
}

Also serde works without std or even alloc it appears: https://serde.rs/no-std.html

[Pratyush]

I think a simpler method might be to just add our own Read and Write traits algebra::bytes::Error enum and in algebra::bytes, and use those in no_std mode. In std mode we would just make these be re-exports for the std types.

If in the future std is decomposed into smaller sub-crates, then we can just do re-exports unconditionally.

[burdges]

Cool. I'd suspect some crate supplying no_std Read and Write traits would appear outside libcore once std::*::Error gets a no_std version outside libcore. I'd think libcore would be cautious about such techniques, both for breakage and because so many error reforms failed. You could plan to be an early adopter of such an effort, even if you need your own Read and Write traits in the short term.

[Pratyush]

Most of the things on this list are done; I'll try to put things online on crates.io soon.