[BUG] - Native tokens with non-UTF8 names break cardano-cli query utxo

[Quantumplation]

External

Area Native Tokens Related to Native Tokens (Mary). Plutus Related to Plutus Scripts (Alonzo).

Summary

If you create a native token with an assetName that isn't valid UTF-8, cardano-cli is unable to render it as part of cardano-cli query utxo.

Steps to reproduce Create a native token by constructing and serializing the transaction from haskell, using an "allow all" minting policy, which has an asset name that is not valid UTF-8.

In our case, we are setting the asset name to the bytes from a sha256 hash, since that fits perfectly in the 32 bytes allowed for the asset name.

Expected behavior

One of two possibilities seems sensible:

• Allow only UTF-8 encodable asset names, and reject the transaction
• Fall back to rendering base16 encoded versions of the asset name.

We've patched cardano-cli locally with the latter:

$ cardano-cli query utxo --whole-utxo --testnet-magic 31415
                         TxHash                                              TxIx               Amount
--------------------------------------------------------------------------------------------------------------------------
4264cb256d94533b6e152da59256638bc6adfda3efc5550d7607d4e6e45592fc                0               10000000 lovelace + 100 ba372dc1677a26ef3396bc357c31765ef0287e94d0c41629ad3.{ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb}

We wrap the assetName with curly brackets to give some indication that it's base16 encoded, rather than the actual asset name.

If there's interest in this approach, we're happy to submit a pull request!

System info (please complete the following information):

• CLI version: cardano-cli 1.27.0 - linux-x86_64 - ghc-8.10 git rev fc46e19f54b5e6413b63996fd7be13f9105286b6

Screenshots and attachments

Additional context

[savaki]

For clarification, the cardano-cli prints all the utxos up to the point where it encounters the first utxo with a non-UTF8 asset name and then bombs there.

[dcoutts]

Yeah, it's just a presentation issue, and should be fixed as a presentation issue. The asset names are not required to be UTF8 (they have to support the use case of hashes for example).

[Quantumplation]

@dcoutts would you accept a pull request?

If so, would you prefer:

• Print non-UTF8 asset names as base16 encoded, and wrap them with curly braces, to indicate that the name isn't literally as depicted; Parse asset names on the command line similarly.
• Print base16 if non-UTF8, use a separate command line argument for base16 encoded asset names
• Some other solution

[gitmachtl]

please be careful with such transactions, i don't see a way for the "normal" cardano-cli user to handle such tokens in his utxos rather than filtering out the incoming utxo in total. so, not a good think for the mainnet atm.

[Quantumplation]

@gitmachtl In particular, this is needed for protocol tokens whose names are the SHA256 hash of some data. Asset names are the perfect size to hold a SHA256 hash, and hex-encoding them first would make them too big.

The fix we have in our locally-patched cardano-cli locally is, if UTF8 encoding fails, print policyID.{[hex-encoded]}, such as ba372dc1677a26ef3396bc357c31765ef0287e94d0c41629ad3.{ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb}. When reading token names from the CLI, we apply a similar reverse translation.

[Quantumplation]

(But yes, we have held off running our contracts on the public Alonzo White / Alonzo Purple testnets to avoid breaking anyone; we have been using a private alonzo purple instance instead)

[gitmachtl]

solved in https://github.com/input-output-hk/cardano-node/pull/3211

[cblp]

Must be fixed in master

[cblp]

If reproduced, comment here to reopen.