Skip to content

Latest commit

 

History

History
64 lines (42 loc) · 3.34 KB

PIP-0044.md

File metadata and controls

64 lines (42 loc) · 3.34 KB
Raw
  PIP: PIP-0044
  Title: Induplicatable NFT
  Type: Protocol
  Impact: Hard-Fork
  Author: Albert Molina   
  Copyright: Albert Molina, 2023 (All Rights Reserved)
  Comments-URI: https://discord.gg/Scr8mcwnrC (Discord channel #pip-44)
  Status: Proposed
  Created: 2023-03-14

Summary

NFT (Non-fungible-token) is a well known item in the blockchain industry. It's currently based on store the item (usually a HASH of a information) in the blockchain as a Proof-of-ownership of the item.

This means that this HASH of the item is stored in a transaction included in a block, and what really is used for transfers (buy/sell transactions) is a reference of the transaction, so there is no warranty/prevention that same NFT HASH is stored in other blocks/transactions

A true NFT must be something that is impossible to be duplicated, so we present a way to store Induplicatable NFT on the blockchain because the HASH will live on the Safebox struct (that is a representation of the ledger balance of the blockchain information) and HASH will be induplicatable on Safebox struct, converting NFT owner in a PASA owner

Also, thanks to Safebox current features, this Induplicatable NFT can be sold using same on-chain transactions mechanism without third party neither single point of failure (PIP-0002 - In-protocol PASA Exchange)

Proposal

This PIP specifies how to use current Safebox struct and operations to store Induplicatable NFT on the PascalCoin blockchain

  • Safebox PASA's has Account Names and Types as described on PIP-0004, that allows to store unique Account Names in the safebox

  • Implementation of PIP-0004 limited Account Name to be Null or 3..64 characters long

  • Implementation of PIP-0004 prevents first char to be a number ('0'..'9') to not confuse name as an account number

In order to use Account Name as a HASH, we must do one of proposals:

  • Without protocol upgrade:

    • Option A: Use a "encode"/"decode" function to convert first char in a numeric/non-numeric char like convert "ghijklmnop" as "0123456789" for first char, so hash 9a737f6e41c58935c535fe7b08426006f246986810c21deeb808cc564b8ecdca will be encoded to pa737f6e41c58935c535fe7b08426006f246986810c21deeb808cc564b8ecdca (transform 9 -> p)

  • With protocol upgrade (Hard fork):

    • Option B: Start hash value with a suffix like "nft_" because first char cannot be an Hexadecimal numeric number, in this case the 64 characters length is a limitation because we cannot store 32 bytes hash plus suffix length in 64 chars

    • Option C: Allows usage of numeric first char when name is a representation of a 32 bytes hexadecimal value

This PIP-0044 will implement Option C allowing first char as a numberic "0".."9" char when name contains a 32 bytes (64 chars) hexadecimal value, this will prevent to use first number as an account number caused to overflow

Implementation

  // Update ValidAccountName function introducing this exception:
  ...
  if (new_name[0] in [Ord('0')..Ord('9')]) then
    if (protocol_version>=CT_PROTOCOL_6) and
       (length(new_name)=64) and
       (IsHexadecimal(new_name))
    then continue
    else Error('Invalid numeric first char on a non-hash hexadecimal 32 bytes representation');
  end;

Backwards Compatibility

This change is not backwards compatible and requires a hard-fork activation.