RLN: implement witness and proof values serialization in serde

[s1fr0]

Problem

We want to serialize Groth16 witness and proof values (i.e., public inputs of the circuit) using serde. These values are embedded in the two data structures RLNWitnessInput and RLNProofValues, containing different data types.

From #20, serialization/deserialization of these two data structures is done through custom functions (serialize_witness,deserialize_witness,serialize_proof_values,deserialize_proof_values, all in the protocol crate).

Acceptance criteria

Implement serialization and deserialization of relevant data structures using serde framework.

[rahulghangas]

@s1fr0 @oskarth Are we married to using serde? I understand that arkworks uses serde (iirc), but using something like borsh would make our lives much easier. Easier to implement, and we get free performance gain as well

[rahulghangas]

I've got serialization working with serde, but implementing deserialization is such a pain

[oskarth]

No strong preferences here. By default it'd probably make sense to use same as arkworks, but maybe fine to use something else if we have good reasons? Not immediately obvious to me what implications would be in terms of ease of interop etc.

What are the problems with serde de-serialization and how does borsh make it better?

@s1fr0 any specific reason for serde from your POV?

[s1fr0]

I've got serialization working with serde, but implementing deserialization is such a pain

I know what you mean, and that's one of the reason why I prefer to have our custom and simple de/ser utilities.

I don't have any strong preference for serde (it was proposed some time ago when RLN module was still using both poseidon-rs Field and arkworks Fr data types) and if we have to chose any, I'd go too with arkworks default serialization/deserialization utilities.

We should keep it mind that serialized data is passed to zerokit APIs, hence data serialization has often to be done on the client side. In other words the deserialization implemented in zerokit should match the serialization implemented/available in clients using zerokit.

Except for the proof (which is a 128-bytes array that is passed to zerokit APIs "as it is", so needs no further encoding/decoding on the client side), other serialized values are essentially elements in Fr, that is fixed-length big Integers encoded in little-endian, a pretty standard and widely-available way to serialize integers. This was one of the main reason why we never went for serde or similar, preferring the simple and straightforward serialize/deserialize utilities in rln/utils.