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
{{ message }}
This repository has been archived by the owner on Oct 31, 2024. It is now read-only.
CanonicalSerialize / CanonicalDeserialize -> those are easily derived as all our wrapper types rely on arkworks traits that do implement those;
custom to_bytes / from_bytes inherited from the old codebase, which are simply calling CanonicalSerialize / CanonicalDeserialize methods internally.
This issue concerns two points related to serialization:
addressing the code duplication induced by all the custom to_bytes / from_bytes methods through new traits, like Encode/ToBytes and Decode/FromBytes (names are arbitrary and not carved in marble), which would be supertraits of CanonicalSerialize and CanonicalDeserialize respectively.
We may want to additionally support serde behind some feature flag for all our public types. This could actually remove the need for a custom serialization mechanism, or be complementary to it (for users who would like to rely on as few extra dependencies as possible and stick to the custom Encode/Decode).
Any thoughts?
The text was updated successfully, but these errors were encountered:
We currently support two types of encoding:
CanonicalSerialize
/CanonicalDeserialize
-> those are easily derived as all our wrapper types rely onarkworks
traits that do implement those;to_bytes
/from_bytes
inherited from the old codebase, which are simply callingCanonicalSerialize
/CanonicalDeserialize
methods internally.This issue concerns two points related to serialization:
addressing the code duplication induced by all the custom
to_bytes / from_bytes
methods through new traits, likeEncode
/ToBytes
andDecode
/FromBytes
(names are arbitrary and not carved in marble), which would be supertraits ofCanonicalSerialize
andCanonicalDeserialize
respectively.We may want to additionally support
serde
behind some feature flag for all our public types. This could actually remove the need for a custom serialization mechanism, or be complementary to it (for users who would like to rely on as few extra dependencies as possible and stick to the customEncode
/Decode
).Any thoughts?
The text was updated successfully, but these errors were encountered: