ginger-lib icon indicating copy to clipboard operation
ginger-lib copied to clipboard

Refactor Serialization/Deserialization APIs

Open 95DDB opened this issue 4 years ago • 0 comments

Currently we have 3 ways of serializing/deserializing structs in ginger-lib:

  • ToBytes/FromBytes/FromBytesChecked/ToBits/FromBits/ToCompressedBits/FromCompressedBits;
  • CanonicalSerialize/CanonicalDeserialize;
  • serde derive macros

For sure this situation is highly confusing and error prone, so I propose the following changes:

  • [ ] While ToBits/FromBits/ToCompressedBits/FromCompressedBits may still have some utility, ToBytes/FromBytes/FromBytesChecked are more or less duplications of CanonicalSerialize/CanonicalDeserialize traits so I would remove them. ToBytes and FromBytes can be directly replaced with CanonicalSerialize/CanonicalDeserialize; regarding FromBytesChecked we should modify deserialize and deserialize_uncompressed functions of CanonicalDeserialize trait to contextually perform validity checks (as defined by SemanticallyValid trait impl for a given struct, possibly in an optimized way enabling to perform early return in case of failures);
  • [ ] serde derive macros are very useful to get representation of structs in different formats (like JSON) so it may make sense to keep them; would be nice to find a way to integrate in them the compression capabilities of CanonicalSerialize/CanonicalDeserialize(WithFlags), possibly privatizing the latters and exposing as public APIs only the serde functions and macros (or even viceversa)

95DDB avatar Jul 07 '21 13:07 95DDB