Non-fungible token spec design

[tkiapril]

The current draft design of the non-fungible token (NFT) specification, as thought out with @dahlia, is as follows.

We treat each instance of the NFT as a chain of certificates, in which the previous certificates in the chain verify the next certificates in the chain, by including the previous certificate chain in the payload of the next certificate and signing it. You may think of it as a mini-blockchain, that tracks the owner of the given instance of the NFT.

The most basic instance of an NFT certificate chain will look like the following:

cert = {
  owner: C,
  prev: {
    owner: B,
    prev: {
      owner: A,
      prev: { /* ... */ },
      sig: signed-by-X
    },
    sig: signed-by-A  // the previous owner signs the new certificate
  } ,
  sig: signed-by-B
}

Also, the blockchain will keep track of whether a certificate chain is in a valid state or is a historical intermediate chain as a blockchain state with the mechanism that will be specified below. A valid certificate chain can be used for tracking the current owner and other metadata, and the state of the chain can be transitioned into another state. This mechanism is required as a measure to prevent replay attacks, where an attacker who owns an instance of NFT tries to double-spend (or double-transfer, double-mutate-state etc.) it.

Mint

Consider that you are minting a new instance of NFT; you will be creating a payload that indicates the initial owner of the new instance of the NFT to be minted.

payload = { owner: A }

Then, you will be signing this payload and include the signature along the payload.

cert = { owner: A, sig: signed-by-X }

This certificate is the proof that the owner ("A") owns the instance of NFT represented by the certificate. It may be complemented with other metadata, and the certificate may be stored on-chain or off-chain.

State Mutation

When the state of the NFT needs to be mutated, a new payload that contains the previous certificate chain will be created.

payload = { owner: B, prev: { owner: A, sig: signed-by-X } }

Then, it will be signed, and the signature will be combined with the payload to make the new certificate. Only the owner of the previous chain may sign the certificate, for the new certificate to be valid.

cert = { owner: B, prev: { owner: A, sig: signed-by-X }, sig: signed-by-A }

Transfer

Transferring instances of NFT is a specific case of state mutation. The example above actually illustrates the transfer of NFT instance from A to B.

Certificate Validation

Consider a scenario where a malicious actor, E, tries to conduct a double-spending attack. E will be sending A their instance of NFT, but they are going to try sending it to B as well. To prevent this, we make an annotation on the blockchain state to verify if a certificate is valid and is available to be processed. This is done by writing the hash of the newly mutated certificate chain in the space marked with the hash of the previous certificate chain. (When mutation A -> A' is created, hash(A') is written in [hash(A)].) This means when there is nothing written in [hash(A)], there is no new version of the certificate A. Whenever the NFT instance is being manipulated in the chain, the hash of it will be looked up, and will be considered valid if nothing is found, and otherwise of there is a recorded state.

Since the execution order of actions in a tx is preserved, and the order of txs from an address is ensured according to the tx nonce, in any circumstances actions from an account will be processed in a serial manner and any kind of double-spending attack will be prevented, since the second transfer attempt will be deemed invalid after the first transfer. Similarly, replay attacks can be avoided as well.

Future remarks

The current state of the specification is barebones, just enough to implement the NFT as a runtime object. Topics that may be discussed in the future includes:

• Atomic transfers:
  • Transfer action where a party may suggest a transfer, providing what will be given and what will be requested in return, and the receiving party must accept (with sufficient deeds in posession) for the transfer to be processed in a nondivisible manner
• Indexing & retrieval
• Delegation

[dahlia]

Needs to further discuss:

• Should non-fungible tokens be able to be minted by system (without actual minter account)?
  • Should item drops in dungeon be represented as systemic minting?
  • Or, is it okay to represent them as transfers from the system-owned fund?
    • Does it mean the total supply of items in the game world should be determined and never expanded even if the number of players becomes much higher?
• Does it make sense if we have administrators with privileges to mint non-fungible tokens?
  • Should those administrators have terms?
  • Should the set of administrators be mutable?
• Would anyone be able to declare their own new non-fungible token?

[dahlia]

Keeping a record: We've decided to put off implementing general-purpose non-fungible token in Libplanet. Instead, we first are going to a game-specific mini implementation of it in Nine Chronicles (specifically, in lib9c) this quarter. After some experiments, we are going to resume designing its general-purpose version for Libplanet later.