[Proposal] Allow asset owners to change owner key

Goal

Allow the account with permission to mint an asset to transfer this permission to a different account, or to disallow future mints forever.

Terminology

  • Account: A simplification used to represent a spend key and it’s derived key parts.
  • Asset Creator: The account used to create the first mint of asset. This account’s public address is used to derive the asset identifier, and is by default, the first owner.
  • Asset Owner: The account that may mint an asset. There can only be 1 owner per asset at a given time.
  • Freezing an asset: Make it impossible to mint any more tokens of an asset. Has no effect on the circulation or transfer of the existing tokens.

Proposed change

Modify the MintDescription of a Transaction to allow changing the asset owner. This is accomplished by adding a new optional field to the MintDescription called transferOwnershipTo which would contain the public address of the account to transfer ownership to.

This allows the key responsible for minting an asset to be rotated. This also allows an asset to be “frozen” by transferring ownership to a throw-away address like ‘000…000’. This brings IF a step closer to supporting NFTs.

Nodes would be responsible for storing this new owner field in the asset database as well, so verification can be done at the consensus level. This new owner would be passed in as a public input to the mint description proof for verification. This would not require any changes to the zero-knowledge proofs.

The current field known as asset owner would be renamed to asset creator, for clarity. The creator’s only purpose once the creator transfers ownership is to be used as part of the asset identifier pre-image.

When an asset is minted for the first time, the creator is by default the owner, unless the initial mint also contains a transfer of ownership.

Hard fork

Due to changing the format of the MintDescription, this would require a hard-fork since outdated nodes would only validate mints by the creator, regardless of whether the owner has changed or not.

Importance

The reason this is important is that, currently, there is no way to change the owner key of an asset. This is a security problem, because if the key is leaked, the asset is now useless and can no longer be used or trusted since an attacker could mint an arbitrary amount forever-more. This would defeat the purpose of bridged assets from other networks, NFTs, etc.

With this change, asset owners can practice good security practices by regularly rotating their keys, and keeping a fresh key ready to transfer ownership to in the event of a suspected issue.

Other possible implementations

This could be implemented by separating the asset owner into 2 pieces: an asset “master” key, and an asset “mint” key. The master key’s purpose would be to modify the mint key or the master key, but would probably have no power to mint an asset itself. The mint key would be responsible for minting or transferring mint permissions to another key.

  • This approach is more robust, but also would require greater complexity to add. It would likely require 2 separate descriptions, one for the “master” key operations, and another for the “mint” key operations. Combining them into 1 description is probably possible, but feels like it would lead to overly complex implementation logic, leading to greater possibility of bugs.
  • This initial proposal does not exclude pursuing this implementation at a later time.
  • In the effect of a mint key leak, the asset owner could rotate the mint key leak without the risk of the asset being frozen by the attacker.
  • This would require an explicit mechanism to allow freezing of an asset since the master key could override the mint permissions at any point

Can we increase the metadata size of mint transaction as part of this proposal? We have only 96 byte as i can see in ironfish_rust, pub const METADATA_LENGTH: usize = 96; this really limits the NFT implementation here.

Almost 10 days since my last comment. I don’t know what’s the opinion on your team side about increasing the metadata size. I think we all know this is important for NFT.

Bridging some of the conversation we had elsewhere on this topic.
Increasing size of metadata would increase the size of every Mint Description. 96 bytes is enough to use as a pointer to data that would live elsewhere. The problem of needing more space to store NFT metadata is also a problem on other chains like Ethereum.
For Ethereum, there are some great examples of fully on-chain NFT projects that have gotten creative to work around the problem of not having enough space on-chain to store a full image:

  • CryptoPunks: the contract only stored a hash of the image containing all 10k punks (32 bytes) and an index (1 through 10,000) indicating which slot in the image your punk lives in (another 32 bytes or less)
  • Autoglyphs: ascii/character art
  • Nouns: generative on-chain art (I believe the full render code is off-chain, but traits/parameters to the rendering are on-chain)

I think 96 bytes can be enough for some interesting cases already. If you’d like that to be increased to something else, please be more specific on what that number should be and why, and how those benefits outweigh the drawbacks of having a larger Mint Description.

That’s it, we can reply on 3rd storage provider :smiley: :smiley: :smiley:

Just to be clear — all the examples I gave above are what is considered to be on-chain NFTs that you can support on Iron Fish today with the 96 bytes of metadata.

Thanks very much :grinning: :grinning: