An Introduction to NFTs

Published in

Coinmonks

11 min readApr 4, 2021

NFTs or non fungible tokens are the craze right now! They are the counterpart to virtual currencies. In the article, I will explain the concept of NFTs, their traits, ERC standards for representing NFT, and How NFTs store data.

*Some degree of computer science knowledge would be beneficial in understanding the topics within the article.

NFT: Non-Fungible Tokens are the opposite of what you would expect of “tokens”. It is the little brother of FT: fungible tokens. However, NFTs and FTs can be viewed as counterparts of each other, as they represent different types of things for their token structure. FTs takes the form in currencies and goods which are a commodity and exchanged (ex. Ether). And on the other hand, NFTs takes form in unique tokens and instances which are non reproduced or fungible (ex. parts of a painting, parts of a fossil …). Thus, each NFT can’t be interchangeable like tokens such as Ether.
One NFT != another NFT. Also, because of this, I will instead refer to NFT tokens as individual assets.

Very much like its counterpart, FTs, NFTs also function on the blockchain. It is “powered” by smart contracts which facilitate the tokens throughout the network. And, because smart contracts’ nature is to help facilitate the tokens distributed throughout a network, the non-fungible aspect of the smart contract ensures that there is only one copy of a specific NFT asset in existence at a time.

On the point of smart contracts, the current most compatible and used NFT standard is the ERC721 standard on Ethereum. In fact, its functions overlap with almost all of the ERC20 standard; such as being able to be transferred in specific reference to the token. Additionally, the ERC20 standard does also have the ability to lend tokens to accounts, but that specific aspect is not implementable in ERC721 as NFTs are not interchangeable in value.

Each NFT smart contract will contain some way of ownership record. One common way are arrays of ownerships, storing important values such as the list of assets each wallet account owns, and mapping each asset to the owner wallet address.

A unique aspect in NFT token smart contracts is the mint function (accessible by the client), which ERC20 tokens does not have. The mint function within the smart contract of NFTs allows users to mint and create a unique token.

Different platforms such as OpenSea, Rarible and CryptoKitties all use the mint function, allowing users to have the ability to create their own unique asset/token using the marketplaces’ online platform. Often, NFT marketplaces support a variety of file formats, images, sound files, animations, and more (for maximum creativity!).

Code implementations in the NFT smart contract segment would implement different features and traits of NFT tokens: (Ethereum.org)

Each NFT token is minted and given a unique identifier
Ability to find the owner wallet address of each token/asset
Bought and sold on Ethereum NFT based markets
No one can change the data of an NFT token in anyway after minted (data change only if programmed to modify itself)
Creators can earn income when sold (when sold on NFT markets P2P)

When there is a special case of representing assets that need to be replicated in a limited amount, creators can replicate their creation at their minting stage (ex. concert tickets). The creators can decide how many replicas exist when minting (only those will exist thereafter). Despite there being different replicas of the same copy of NFT token, they are always assigned unique identifiers (similar to hashes), with only one owner. Using concert tickets as an example, the event organizer can create 5000 standard tickets and 500 deluxe tickets. Although the copies are the same per piece of ticket, they feature a different identifier like unique pieces of barcodes that you see on physical tickets.

The tickets are all the same, but the #id is different

An example of minting in terms of hex color tokens:

rough onenote sketch: Joe mints color token

Basic walk through for the diagram:
Joe wants to mint a color token #F08080 (tokens with unique color hex code). He first creates the token by calling the ‘mint function’. Because this token is an NFT, the mint function has to check if the specific hex code of the color had already been minted. In order to proceed, the color token has to be have never minted before. Then, when the new color token is minted, the array of token existence will be updated to contain the newly minted color token. In order for Joe to technically own the token, the color token will be added to his wallet account’s array storage in the smart contract, assigning his wallet address as the owner of the color token.

Different Standards for representing NFTs

The different types of standards within smart contracts are what creates uniformity in different decentralized applications and web interfaces. The Ethereum ERC721 and the ERC1155 standards are part of Ethereum’s series of ERC standards (Ethereum Request for Comments). They are application level standards for Ethereum smart contracts and include token standards, name registries, libraries and packages. Anyone can create an ERC, but they would have to explain the standard and gain approval within the community.

ERC standards commonly define a set of functions for a type of token. The common example would be the ERC20 token standard, which means for creation of crypto like Ether.

ERC standards are commonly displayed through Solidity, Ethereum’s main programming language for smart contract development. Solidity is a turing complete language in a OOP style similar to that of python and javascript. This similarity is seen with the declaration of ERC standards using interfaces. Interfaces are essentially a blank template or storyboard of how a smart contract should be structured roughly.

Interfaces contain the first line of method declaration such as:

function ownerOf(uint256 _tokenId) external view returns (address);

but interfaces do not implement the method. The smart contract that will follow/implement that interface will have to implement the methods within the interface. Thus, ERC standards are sometimes constructed as interfaces for smart contract devs to follow as a basic template.

Thus, you will see some smart contracts first lines like this one:

contract myContract is ERC721 { 
  // contract content
}

ERC721 Standard

The ERC721 standard introduces an interface standard solely for NFTs. Each asset is unique based on its different values in variables such as: age, rarity, visuals. Visuals are also incorporated in assets of the standard through an uint256 variable called tokenId, unique for each asset along with the contract address. The smart contract is able to store visuals/images in their built in space or using an external database utilizing the tokenId value to access and store specific values.

ERC721 provides a mapping of unique identifiers (each represents a NFT token asset) to owner wallet addresses.

interface IERC721 { function ownerOf(uint256 _tokenId) external view returns (address);function transferFrom(address _from, address _to, uint256 _tokenId) external payable;}

The above is essentially the essence of the ERC721 standard in order to represent the NFT (*Note that there are more to the interface for the standard than the above). The ownerOf function allows for clients to check the owner of different assets/tokens considering market functionalities, and the transferFrom function allows the transfer of assets/tokens in between wallet addresses.

Additional to implementing by hand, developers can also easily create a new contract through importing libraries and packages from the ERC721 OpenZeppelin libraries.

ERC1155 Standard

The ERC1155 standard pioneered by Enjin can also be used to represent NFT assets. However, this smart contract standard can also be used to create a semi-fungible token, combining uniqueness and exchangeability into tokens. The main aspect that is differing is the ability to categorize and group different assets using different id. This concept is very much like inheritance in OOP languages concerning classes. (id concept explained below)

The items: apple, banana, and orange are all “Fruit” type

interface IERC1155 {function balanceOf(address _owner, uint256 _id) external view returns (address);function transferFrom(address _from, address _to, uint256 _id, uint256 quantity) external payable;// more implementation not shown}

The above piece of interface code are the balanceOf and transferFrom functions of the ERC1155 standard. The notable thing about the two declarations of the functions is that they both feature the uint256 variable _id for referencing token categories, the transferFrom function features the uint256 variable quantity for transferring an amount of the specified type (variable is commonly defined in fungible tokens).

For example, if there was an id which represents different “stickers”. And if a wallet account owned 300 assets of type “stickers”, consisting of different sticker items such as a “Gopro sticker”, “Thrasher sticker”, “Supreme sticker”, etc… Utilizing the balanceOf function and plugging in a parameter of the id type “stickers” would return the number of “sticker” type assets there are in the wallet, in this case, 300 of them. Similar with transferring tokens, one can use an id to transfer a quantity of assets of the same type. In this case, the wallet owner can transfer all 300 unique stickers in one transaction specifying the id and the uint256 quantity. Through this, providing a lot more flexibility in decentralized transactions.

ERC1155 provides a superset of ERC721 functionality, an ERC721 NFT smart contract can be also built using ERC1155 but with unique IDs and quantity kept at 1.

Anatomy for data mapping

This is the structure for data mapping for the three different ERC standards. ERC20 maps addresses to amounts, ERC721 maps unique IDs to owners, and ERC1155 has a nested mapping from references to owners to amounts.

But where are the contract data stored?

It is done through files called the metadata. The NFT token smart contract points to a series of metadata files in order to access information for visuals/images, supply and authenticity. (Detail on Metadata standards).

Metadata provides descriptive information for a specific token id through variables. For example, a metadata file for a color token might look like this:

{
  "name": "Color",
  "hex": "#F08080",
  "link": "https://bit.ly/3mdRahT",
  "owner": "0x6902702BB5678D7361C94441c71F600C255dd833"}

A metadata file is commonly structured like a series of variable declarations for storing data, and in this case, the color token’s metadata tells us: the name of the token, the hex color code, link to the color image, and the owner of the color token.

A online real life example of NFTs would be CryptoKitties, a kitten collecting game using ether as a currency (every kitty is unique). One of the important methods in the CryptoKitties smart contract is the ownerOf method, which uses a specific kitty’s metadata to figure out the owner and other attributes of the kitty, which uses the metadata of each asset.

ownerOf Function of CryptoKitties smart contract (deployment page)

Storing Metadata

Mainly two options, On-chain, and/or Off-chain.

On-chain

The “chain” refers to blockchain, so the word entirely refers to on-the-blockchain. This means that whatever is specified to be on-chain will have to follow data’s behaviour on the specific blockchain (ex. data cannot be modified by anyone after deployment). My article on blockchain functionality here.

Deploying the metadata of token on-chain will make sure that it is there to stay and will permanently reside with the token, overcoming off chain data storage external factors. So, regardless of the existence of the original website or decentralized application, a piece of digital art can continue to exist.

Off-chain

The opposite of On-chain, data off of the blockchain. Meaning that the data does not have to abide to blockchain local or global restraints. However. this creates freedom and security vulnerabilities (freedom for data modification).

Storing metadata off chain right now is simply more efficient and convenient due to costs of deployment and storage limitations of the Ethereum Blockchain. Many developers utilize centralized servers such as AWS cloud, and the InterPlanetary File System (IPFS) to store metadata.

function tokenURI(uint256 _tokenId) external view returns (string);

The above function, tokenURI is part of the ERC721 standard and returns a public URL of an external metadata file stored on the internet. The metadata file should follow the ERC721 metadata json schema.

Overall:

On-chain metadata is time proof and serves a more efficient method of communication with the smart contract
Off-chain metadata is cheaper, realistic. But it isn’t tamper proof.

Real life and systems

Currently, NFTs and decentralized markets are rapidly developing in technology. Although NFT systems are still constraint within the virtual entertainment realm of things (ex. Art, Item collection, songs), there are strong signals for the future incorporation of NFTs into our daily lives (ex. DeFi).

In the future, the tokenization of physical Items will become possible, where unique and different items can be tokenized, such as houses, pokemon cards and different collectable fossils and art pieces, etc…
As NFTs are essentially different item, you could essentially use ETH to buy a house or apartment as an NFT (key) in return, with your Ethereum address becoming the key to daily life (literally).

Although blockchains are not very eco friendly due to mining, Ethereum is gradually working to improve that through the upgrade into Eth2, replacing mining with staking to make decisions upon the verification node. (Check out my article on blockchain mining!)

Conclusion

Hi, thanks for reading this article. I’m Jerry, a 15 year old who is passionate about upcoming technologies and solving real world problems with these technologies.

See you in the next article! :)

Join Coinmonks Telegram group and learn about crypto trading and investing