Consider allowing faucets to issue multiple fungible assets

[PhilippGackstatter]

Summary: Consider changing fungible asset validation to not require that asset ID limbs are set to zero. This would effectively allow a faucet to issue multiple fungible assets.

Basically, these two elements [editor's note: the AssetId] uniquely identify an asset among all the assets issued by a given faucet. There is actually no reason why a given faucet couldn't issue many fungible assets. We don't allow this right now, but we could relax this in the future. To give a couple of examples of such assets:

• A movie theatre issues tickets for a given showing. Each showing has 100 fully fungible tickets. In this case, the SubAssetId would identify the showing.
• A corporation issues different classes of stock - e.g., A, B, C. Shares are fully fungible within a given class. Here, the SubAssetId would identify the share class.

We can of course emulate these in other ways - e.g., by creating a separate faucet each share class - but we can also decide if we want to allow this later on.

Originally posted by @bobbinth in #2630

At the protocol level we can technically allow this later, but it would be an invasive change nonetheless: We'd need a second variant of the create_fungible_key procedure that takes an asset ID as input. All procedures that call that procedure would have to gain a second variant as well, which ripples quite far. Note that changing the original procedure is not possible after mainnet, since it would break its MAST root.

By my read, this would, for example, affect the agglayer's unlock_and_send, which calls asset::create_fungible_asset. This agglayer code path seems to only store the faucet ID for fungible assets, and so adding support for fungible assets with arbitrary asset IDs seems to require breaking changes at that level.

I mention this now while we still have time to potentially prepare for this change.

[bobbinth]

At the protocol level we can technically allow this later, but it would be an invasive change nonetheless: We'd need a second variant of the create_fungible_key procedure that takes an asset ID as input. All procedures that call that procedure would have to gain a second variant as well, which ripples quite far. Note that changing the original procedure is not possible after mainnet, since it would break its MAST root.

Could we not just introduce a new procedure? Something like:

#! Inputs:  [enable_callbacks, issuer_id_suffix, issuer_id_prefix, class_suffix, class_prefix]
#! Outputs: [ASSET_KEY]
pub proc create_fungible_key_with_class
    ...
end

This would be a pure addition. All old code remains as it was (and so already deployed faucets are not affected), but new faucets will be able to use the new code to create a broader set of assets. Or am I missing something here?

[mmagician]

I think this would work, though it would implicitly encode a default class for all the already-isssued assets (which is fine, just noting this).

[PhilippGackstatter]

Yes, that definitely works, but what I meant was primarily two things:

• because this procedure sits at a low-level, we'd need various new versions of existing procedures:
  • asset::create_fungible_asset
  • faucet::create_fungible_asset
  • fungible_faucet::mint_and_send
• callers like the agglayer that currently assume "fungible asset has asset ID limbs (0, 0)" for their storage layouts would not support the new assets automatically, and at first glance, it seems like changing this post-stabilization would not be possible (without breaking things).

Both points are fine in principle. The API is purely additive, so a non-breaking change. Actually supporting such assets in the agglayer (or similar asset applications) may be a breaking change, and so we may want to prepare for it.