feat: add new methods for conversion between Ed25519 public key and long account ID (as defined in HIP-32)

[bguiz]

Problem

Why

• Some Mirror Node APIs do not accept the default serialisation format for the public key, and this conversion needs to be performed first
• In some circumstances, one needs to have a valid account ID, prior to the account being initialised on the network, for example in order to receive an initial transfer

Context: HIP-32 defines the a long form account ID like so:

This long form doesn’t look like 0.0.123, but instead is an alias consisting of <shard>.<realm>.<bytes>, where the bytes is a base32url representation of the bytes of a serialized HAPI primitive Key, with the trailing = padding characters removed. For example, 0.0.CIQNOWUYAGBLCCVX2VF75U6JMQDTUDXBOLZ5VJRDEWXQEGTI64DVCGQ is the alias address of shard 0 realm 0 with a serialization of a HAPI Key for the ed25519 public key 0xd75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a.

Solution

What

• Consider adding utility methods in EntityIdHelper class or the PublicKey class
• One method to convert from Ed25519 public key to long account ID, for example:
  • Input: d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a
  • Output: CIQNOWUYAGBLCCVX2VF75U6JMQDTUDXBOLZ5VJRDEWXQEGTI64DVCGQ
• Another method to convert from long account ID to Ed25519 public key, for example:
  • Input: CIQNOWUYAGBLCCVX2VF75U6JMQDTUDXBOLZ5VJRDEWXQEGTI64DVCGQ
  • Output: d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a
• Take into account the specific configuration of base32url

Alternatives

Further considerations

• HIP-32 does not define behaviour for ECDSA secp256k1 public keys (as it predates them being on Hedera, slightly, Dec 2021 vs Feb 2022)
  • This is beyond the scope of this github issue, but is something worth investigating separately

References

• HIP-32: Auto Account Creation
• IETF RFC 4648: base32url
• Smart Contracts 2.0: Live on Mainnet