no_std compatibility

[redshiftzero]

For embedded devices such as hardware wallets, we'll need no_std compatibility for at least:

• decaf377: fix no_std incompatibility decaf377#59 - released in decaf377 0.7.0
• decaf377-rdsa
• penumbra-keys

[cronokirby]

One thing to note is that we don't need to full functionality suite for penumbra-keys. e.g. we don't need to construct transaction with key agreement, we just need to sign, export a full viewing key, and derive addresses. Which, admittedly, is 90% of the code.

[hdevalence]

It's maybe worse than that, no? The custodian has to process the TransactionPlan into an EffectHash.

[cronokirby]

I had a chat with @redshiftzero earlier today and we sort of realized that the logic for doing this would need to be extracted out most likely and rewritten in an embedded context, leaning on the fact that effect hashes are calculated from the proto encoding. We should probably write up the thinking here somewhere.

[hdevalence]

Originally we thought we'd need to do something like that to have no_std support for WASM to run code in the browser. Then it turned out we didn't. So while it might be the case, we should probably not rewrite large parts of our crates without actually gathering requirements first. I don't think that's happened yet. It would be helpful to hear from the Zondax team about how things have gone so far.

[redshiftzero]

Closing this in favor of the plan in #3526