add eddy crate: flow encryption implementation scaffold

[avahowell]

Co-Authored-By: Henry de Valence hdevalence@penumbra.zone

[hdevalence]

Mathematically, decryption can only fail if the value is not present in the lookup table, and while the point of the value integrity proofs is to guarantee that this cannot occur, someone could add too many ciphertexts at once, or similar, so it's important to model.

But in practice, the lookup table may not be entirely resident in memory, and might involve access to I/O, which is (1) async and (2) fallible. So there are two kinds of errors: errors from the underlying storage, and a failed lookup.

The lookup trait returns a Result<Option<u32>, anyhow::Error>, with an outer Result allowing indication of an arbitrary I/O error, and the inner Option signaling whether or not the value was present. This is a good API for external users to plug into, since they can put whatever I/O errors they want in the Err variant, and it's easy to signal missing values with None.

Here in decryption, though, we probably want a way to allow users to distinguish whether the error was due to underlying I/O issues, or whether a value went out of range. If we use anyhow! to make a stringy error, we can't do this.

There are two options:

1. We could change the return type of decryption to Result<Option<Value>, anyhow::Error>, with the inner Option signaling whether the value was too large or not;
2. We could leave the return type as Result<Value, anyhow::Error>, but create a LimbRangeError struct, and use thiserror to derive an Error implementation for it, then do .ok_or(LimbRangeError)? here.

If we do the first option, all downstream users have to manually transform the inner Option. If we do the second option, downstream users that don't care can bubble up a generic error, and downstream users that do care can use downcast_ref::<LimbRangeError>() to handle it specially.

So option (2) seems better to me.

[hdevalence]

While decaf377 gives us a prime-order group, the group still does have one small subgroup -- the identity element is a subgroup of size 1, and so I think we need to check that we're not processing a bunch of identity points.

One way we could do this is suggested in the Merlin docs -- include validation in the transcript functions, making them return Results and fail on identity points.

[hdevalence]

Based on tendermint/tendermint#9053, it seems like ABCI++ is not going to ship in its complete form (i.e., including VoteExtensions) in a deployable version of Tendermint before late this year at the earliest. Unfortunately, this means that we will not be able to include flow encryption in the initial version of Penumbra, and we will have to add it in a later network upgrade some time in 2023.

As a result, we should pause this work, and just try to get it in a good enough state to merge in for now, and come back to it for v2. I did a docs/API pass to that effect.