dusk-network / dusk-bytes Goto Github PK

I would prefer to do:

use dusk_bytes::Deserializable;

let easy_u64_obtention = u64::from_le_bytes(&buf[256..264]);

Rather than what I'm forced now:

one_u64[..].copy_from_slice(&buf[256..264]);
let not_that_easy_obtention = u64::from_le_bytes(one_u64);

A macro for all the basic types will suffice IMO.

We fixed in #11 the needs to leak the size of a Serializable type during the from_bytes for complex structure.
However, there is nothing similar for to_bytes.

In short, with v.0.1.2 we can have:

    fn from_bytes(bytes: &[u8; Self::SIZE]) -> Result<Self, Self::Error> {
        let mut bytes = &bytes[..];
        let a = BlsScalar::from_reader(&mut bytes)?;
        let b = BlsScalar::from_reader(&mut bytes)?;
        let c = BlsScalar::from_reader(&mut bytes)?;

        Ok(Self { a, b, c })
    }

However, for to_bytes, we still have the following:

    fn to_bytes(&self) -> [u8; Self::SIZE] {
        let mut buf = [0u8; Self::SIZE];
        buf[..32].copy_from_slice(&self.a.to_bytes());
        buf[32..64].copy_from_slice(&self.b.to_bytes());
        buf[64..].copy_from_slice(&self.c.to_bytes());
       
        buf
    }

Given a type implements HexDebug, consider the output of the following snippet:

let a = BlsScalar::one();
println!("{:x?}");
println!("{:#x?}");

The current output is

0100000000000000000000000000000000000000000000000000000000000000
0100000000000000000000000000000000000000000000000000000000000000

But since we are using alternate mode, it should be

0100000000000000000000000000000000000000000000000000000000000000
0x0100000000000000000000000000000000000000000000000000000000000000

Some structs (e.g. BlsScalar) serialize their bytes as little endian.

This means the printed chars are inverted. This can be misleading, sometimes.

Proposal:
The procedural macro should consider as default the little endian encoding, and should have a flag to indicate if the serialization is performed as big endian.

Example:

println!("{:x}", BlsScalar::one());

Will print: "0100000000000000000000000000000000000000000000000000000000000000"
Should print: "0000000000000000000000000000000000000000000000000000000000000001"

Adding auto trait in dusk bytes will reduce the boilerplate code when DeserializeSlice and ParseHexStr are implemented by consumer.

This should be done before the next bump of jubjub since it will slightly change the code.

Summary

There are more constant sized primitives that could use a Serializable implementation. Examples include [T; N] where T: Serializable, Option<T> where T: Serializable, the signed integers - i8, i16, etc... - and even u8.

Possible solution design or implementation

Implement Serializable for the above mentioned structures:

impl Serializable</*...*/> for i8 {
    // ...
}

Additional context

It is important to implement this trait eagerly, since it is used everywhere to transport structures over the wire.

We need a function to parse an hexadecimal string (e.g. "fe12c6" to [0xfe, 0x12, 0xc6]) that can be constant evaluated.

In order to land #4 we need to fix the CI, since dusk-analyzer reports derive-hex does not have the proper LICENSE file (when is present)

This is likely a bug on cargo-dusk-analyzer that does not handle properly workspaces.

Error:  --> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/dusk-bytes-0.1.3/src/lib.rs:7:12
  |
7 | #![feature(external_doc)]
  |            ^^^^^^^^^^^^ feature has been removed
  |
  = note: use #[doc = include_str!("filename")] instead, which handles macro invocations

We should update this since the feature has been removed @ZER0

Summary

Add more documentation and READMEs.

canonical_derive is using 1.0.17 and dusk-bytes is using 1.0.58

They are conflicting when implemented over the same crate. Both should not specify the patch version

A recurrent pattern is when we have multiple serial structs in a single slice of bytes.

One efficient solution is to have a function fn from_slice_split<T>(bytes: &[u8]) -> Result<(T, &[u8]), _>

It will take the first n bytes required to parse the provided type, split the slice and return a tuple with the parsed type and the remainder bytes.

Considering the required traits are implemented for T and we have a tuple (T, T) = (a, b), the following test case should pass:

const B: u8 = 0xfa;

let mut bytes = [B; 2 * T::SIZE + 1];
bytes[..T::SIZE].copy_from_slice(&a.to_bytes());
bytes[T::SIZE..2 * T::SIZE].copy_from_slice(&b.to_bytes());

let (a_p, bytes) = T::from_slice_split(&bytes).unwrap();
let (b_p, bytes) = T::from_slice_split(&bytes).unwrap();

assert_eq!(a, a_p);
assert_eq!(b, b_p);
assert_eq!(bytes, [B]);