|0.1.1||Mar 1, 2023|
|0.1.0||Jun 14, 2021|
#897 in Encoding
86 downloads per month
Used in 5 crates (via binary_sv2)
SERDE <-> Sv2 bool <-> BOOL u8 <-> U8 u16 <-> U16 U24 <-> U24 u32 <-> u32 f32 <-> f32 // not in the spec but used u64 <-> u64 // not in the spec but used U256 <-> U256 String <-> STRO_255 Signature<-> SIGNATURE B032 <-> B0_32 // not in the spec but used B032 <-> STR0_32 // not in the spec but used B0255 <-> B0_255 B064K <-> B0_64K B016M <-> B0_16M [u8] <-> BYTES Pubkey <-> PUBKEY Seq0255 <-> SEQ0_255[T] Seq064K <-> SEQ0_64K[T]
Serilalizer and Deserializer are implemented using slices in order to reduce copies:
Fixed length primitives:
Each fixed length Sv2 primitive type when deserialized contains a view in the input buffer so no copy is needed to deserialize raw bytes.
Non fixed legth primitives
Non fixed length primitives can be diveded in strings, byte sequences and general sequences.
Strings are automatically handled by Serde
Non byte sequences
SEQ0_64K[T] are implemented as a
struct that contains two optional field:
- an optional view in the input buffer
- an optional slice of T
When the sequence is constructed from a serialized message we just get a view in the input buffer and no data is copyed.
When the sequence is constructed from [T] the sequnce can safely point to them without transmute.
Byte sequences can be limited length sequences or unlimited length sequences, the latter are automatically handled by Serde. Limited length byte sequences are not implemented as a specific new type of generic sequences cause:
- For the rust type system a serialized byte array and a deserialized byte array are the same thing, that is not true for generic sequences.
- In order to not copy data around generic sequences need to be implemented as struct containing two optional field, a slice of byte and a slice of T.
- This dicotomy is not needed for byte sequences so they are implemented as specific smaller struct.
Why not rkyv?
rkyv is a a zero-copy deserialization framework for Rust. I do not know rkyv but it seems that the objective of this library could have been readched with less effort and better using rykv instad then serder.
Btw Serde is like standard for rust code, very safe and stable. The deserialization/serialization part will be in the code that need to be added to bitcoin core, so it must use the most safe and stable option. That do not exclude that a serialization/deserialization backend can be implemented with rykv and then used by the subprotocols crates via a conditional compilation flag!