feat(zk): impl CanonicalSerialize/Deserialize

[tmontaigu]

This is to allow specifying whether data should be compressed as compression and validation adds a very signigicant overhead especially in wasm where deserialization goes from 6 min to 450ms

[tmontaigu]

@kc1212 @dd23 Given this, I wonder if we remove the serde serialization for ZkPok entities since, it would be better sur rely on ark's canonical serialize/deserialize to pass the Compress and Validate options explicitely and if one want to use serde in a struct that embeds a zk pok think he could use something like #[serde(deserialize_with = "deser_function")] and specify its own default values for Compress/Validate in there

[kc1212]

Is it possible to use #[serde(deserialize_with = "deser_function")] on G1, G2, etc when tfhe-zk-pok is used as a library? Or we'll have to write wrapper types?

[tmontaigu]

Yes this should be possible

#[derive(serde::Deserialize, serde::Serialize)]
struct MyStruct<C: zk-pok::Curve> {
 #[serde(deserialize_with = "deser_function")]
 g1: C::G1
}

[tmontaigu]

The places where a left the serde things are because it makes our life a bit easier by still allowing to use #[derive(serde)] on types that uses them (e.g the proofs which are embeded in compact ciphertext list, without this we would have to impl serde manually to call CannonicalSerialize::serialize_with_mode on each proof.

If we think its better to only have Cannonical serialize for zk primitive then this could be a backlog issue

I benched the serialization/deserialization of compact ciphertext list in wasm (which uses the derived serde, thus Compress::Yes, Validate::Yes) and I get 2ms to serialize and 14ms to deserialize, which is acceptable so keeping this easy solution is possible

[IceTDrinker]

The places where a left the serde things are because it makes our life a bit easier by still allowing to use #[derive(serde)] on types that uses them (e.g the proofs which are embeded in compact ciphertext list, without this we would have to impl serde manually to call CannonicalSerialize::serialize_with_mode on each proof.

If we think its better to only have Cannonical serialize for zk primitive then this could be a backlog issue

I benched the serialization/deserialization of compact ciphertext list in wasm (which uses the derived serde, thus Compress::Yes, Validate::Yes) and I get 2ms to serialize and 14ms to deserialize, which is acceptable so keeping this easy solution is possible

Ok let's keep it that way for now and yes please for the backlog issue

[IceTDrinker]

go for merge @tmontaigu