Serialize/Deserialize Poseidon Constants

[lurk-lab]

Serialize/Deserialize Poseidon Constants

[porcuquine]

I agree this will be useful, though I note a stopgap would be to regenerate the parameters on deserialization — which may be tolerable for use cases where the public parameters are cached in memory (which probably makes sense).

I haven't given thought to the typenum issue, but will something like this work? https://www.reddit.com/r/rust/comments/5z3t5j/hey_rustaceans_got_an_easy_question_ask_here/dewmhjl/?context=3

If you have thoughts, a PR would be welcome.

cc: @vmx, @johnchandlerburnham, @dignifiedquire — all of whom may have insight and/or bandwidth.

---

Also note: in the future, it may be that only a single arity is required in the public parameters, in which case some of this complexity might disappear. (The idea is to support the Nova random oracle via sponge in Neptune, so there is no dependence on either the number of elements to be absorbed or on the arity of the the inner function F.)

Given that, if the typenum issue turns out to be problematic, it might be easier to wait — although I realize this wouldn't address the general problem of serialization/deserialization for Neptune.

[arthurgreef]

Thanks. I'll wait for you'll to remove the dependency. The typenum package provides an optional serde feature but only for generic-array and not arraylength. Is there an issue I can subscribe to track the Nova sponge support? Also, it seems problematic to support serde as an optional feature in Neptune because of the use of bounds constraints in structs and implementations. It seems as though to use serde derive you need to have one copy of a struct or impl for when the serde feature is enabled and when it is not. Would you want serde to be an optional feature? Thanks.