[fastx types] 32 byte authenticator

[sblackshear]

This is based on #88 and thus may be hard to review until that PR lands...

Previously, we assumed that Move addresses (16 bytes)/Authenticators and FastX addresses/authenticators (currently 32 bytes) had to coincide + used unsafe hacks to convert between them. This PR separates the two, allowing Move Authenticators to be 32 bytes + eliminating all the hacks.

[huitseeker]

Consider making (the branch of) #88 the target branch?

[sblackshear]

I'm embarrassed to say I don't know how to do this when the base branch is on my fork--I only see the following options when I try to change it:

[huitseeker]

@sblackshear 🤦 it's not you: that's impossible. This would be one case where only opening a (feature) branch on the main repo would work.

[huitseeker]

The single error case of this TryFrom is just an invalid length error. There is a host of other problems completely ignored by the current implementation:

• there are sequences of 32 bytes that will structurally not ever be usable as an Ed25519 Public Key in any way,
• there are sequences of 32 bytes that will 100% be usable as an Ed25519 Public Key, but that demonstrably and unambiguously aim at tricking anybody who does so.

The above takes exactly none of that into account. Further, several of those checks will not be performed by check_internal's dalek::PublicKey::from_bytes (and the library has a nice warning to say so).

I admit it's probably a completely orthogonal point to this PR, and worth tackling in a different issue (probably extracted from this comment), but I'd appreciate a spectacular comment on PublicKeyBytes making this clear. Here is an example of my personal minimum bar for the word "spectacular".

[huitseeker]

@sblackshear I'm happy to write a BCS-compatible serialization for Array<T, const N: usize> (possibly even upstream) if you open a fastNFT ticket for it & assign to me, I've already done most of the work in Narwhal in MystenLabs/narwhal#29

[sblackshear]

@sblackshear I'm happy to write a BCS-compatible serialization for Array<T, const N: usize> (possibly even upstream) if you open a fastNFT ticket for it & assign to me, I've already done most of the work in Narwhal in MystenLabs/narwhal#29

Thanks for flagging the issue above + this offer!

I'm not sure we need this for now because of the forthcoming decoupling of FastPay addresses and authenticators:

• After this change an FastPayAddress, will instead be the hash of an authenticator (e.g. pubkey)
• In Move, we'll probably need to encode a FastPayAddress with a vector<u8> (Move doesn't have fixed-size arrays, though would be nice to add them in the future), which has a different BCS serialization than a fixed-length array (because it includes a length prefix).