[Proposal] Use nicer formatting for human-readable serialization of checksums

[mitchmindtree]

Context

Currently, it appears we serialize checksums using the default derived implementation for lists of bytes:

       Leo     The program checksum is: '[167u8, 156u8, 237u8, 201u8, 116u8, 83u8, 250u8, 38u8, 129u8, 210u8, 60u8, 95u8, 245u8, 200u8, 10u8, 21u8, 14u8, 3u8, 230u8, 145u8, 106u8, 235u8, 21u8, 146u8, 115u8, 92u8, 241u8, 22u8, 235u8, 234u8, 119u8, 58u8]'.

These are unwieldy and add a lot of noise to the leo CLI output.

Possible Formats

Ideally these would be formatted as one of the following:

• Hex - simplest, universally understood, and the standard for checksums everywhere else (git, sha256sum, etc.). e.g.

  Leo     The program checksum is: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2
  

• Bech32m with a custom HRP (e.g. chksum1...) - most consistent with Aleo's ecosystem conventions for public-facing data. e.g.

  Leo     The program checksum is: chksum1q9s4wz8xhv7y3k2m5n6p8r0t1u4v7w9x2y5z8a3b6c9d2e5f8g0h3j6k9
  

• Field element literal - if the checksum is actually a field element internally, we could consider just displaying it as <value>field. e.g.

  Leo     The program checksum is: 73198264501938475620384756102938475610293847561029384756102938field
  

Implementation

Provide simple hand-rolled Serialize and Deserialize implementations for the checksum type that check the is_human_readable flag on the serializer, and use this to select between the encoded string or raw forms.

[vicsn]

Great idea!

If we use bech32m and we move that new definition to snarkVM, would we only have to change a few lines of fmt code, or wherever we use ProgramChecksum: Field?

[mitchmindtree]

After digging into this a little there's a couple considerations.

If we only care about formatting for the CLI output, this is trivial as we can just change this formatting locally in the CLI tooling.

However, @d0cd mentioned these values are often copied from the output to use as input to another function. To maintain compatibility for this use-case, we'd want to implement this formatting behaviour in the serialization of human-readable formats as mentioned in the OP.

This is fairly common practise for byte-representations in human-readable formats like JSON and TOML as it makes them more terse and bandwidth friendly. serde supports this with the is_human_readable flag.

After digging into the latter, I've noticed we don't actually have a newtype for checksums - snarkvm tends to use [U8<N>; 32] for checksums which makes this trickier as we can't specialise the implementation of serde traits for [T; 32] directly.

I think a proper solution would look like introducing a ProgramChecksum<N> newtype in snarkvm where we can provide the proper trait ipmls. We could probably do this in a backwards-compatible way where the Deserialize impl falls back to the raw representation if the encoded one fails.

I've opened up a proposal for introducing a newtype in snarkvm.

• [Proposal] Introduce ProgramChecksum<N> newtype with hex formatting snarkVM#3174

It ends up touching a lot of places in the VM, though they're fairly simple and seem mostly doable in a backwards-compatible manner. Maybe we could address this as a part of Q2 CLI improvements? I'll leave the call up to you!

[vicsn]

Thx let's go for hex then!