You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As described in #19, currently the Serialize, Deserialize implementations for bn256::{Fr, G1Affine} are using the human-readable (aka to_repr() implementations) format. One should remember that this means you should NOT use Serialize, Deserialize implementations for anything where performance is critical (such as serializing/deserializing proving keys).
Currently we use bincode with the derived Serialize, Deserialize on Snark, but since snark proofs are pretty small it should be inconsequential.
We should add custom derive for rkyv::{Serialize,Deserialize} and possibly also bincode::{Serialize,Deserialize} so we can benchmark/compare different serde strategies for proving keys: axiom-crypto/halo2#7
The text was updated successfully, but these errors were encountered:
As described in #19, currently the
Serialize, Deserialize
implementations forbn256::{Fr, G1Affine}
are using the human-readable (akato_repr()
implementations) format. One should remember that this means you should NOT useSerialize, Deserialize
implementations for anything where performance is critical (such as serializing/deserializing proving keys).Currently we use
bincode
with the derivedSerialize, Deserialize
onSnark
, but since snark proofs are pretty small it should be inconsequential.We should add custom derive for
rkyv::{Serialize,Deserialize}
and possibly alsobincode::{Serialize,Deserialize}
so we can benchmark/compare different serde strategies for proving keys: axiom-crypto/halo2#7The text was updated successfully, but these errors were encountered: