Code A Minimalistic NFT Smart Contract in Solidity On Ethereum: A How-To Guide

NFT is a new/old buzzword of the blockchain world. The NFT standard (EIP-721) was created in 2018, but after CrptoKitties this field was relatively silent.

Nowadays NFTs are back in fashion, and everybody wants to make NFT from everything. You can sell your arts or tweets, or anything that you can imagine in form of NFTs. But what is this mystic NFT thing?

NFT is not a big deal. As ERC20 (fungible) tokens, NFT (non-fungible tokens) are also simple “databases” on the blockchain.

While an ERC20 token contract stores balances of Ethereum addresses, the NFT contract stores unique ID -> Ethereum address assignments. When you mint an NFT to yourself, the token contract assigns the unique token ID to your Ethereum address.

Technically this unique ID is the NFT itself.

You can sell it, or buy other NFTs which is a reassignment of the ID. Metadata can be assigned to the ID (by a URI) that represents the thing behind the NFT (ex.: an image, a tweet, etc.). That’s all. Easy, right? I told, NFT is not a big deal…

Although an NFT is not a complicated thing, an NFT contract can be quite complex. If you take a look at 0xcert’s implementation, you will find a complex token logic and many internal state variables.

The problem with complexity is the high transaction cost. In this article, I will show how can you create a minimalistic but fully functional NFT contract on the Ethereum blockchain.

First of all, take a look at some of the state variables of 0xcert’s implementation:

mapping (address => uint256[]) internal ownerToIds;
mapping (uint256 => uint256) internal idToOwnerIndex;
mapping (uint256 => address) internal idToOwner;
mapping (address => uint256) private ownerToNFTokenCount;

The

ownerToIds

idToOwner

idToOwnerIndex

ownerToNFTokenCount

As you see, this data structure is strongly redundant, because every mapping could be calculated from the first ownerToIds structure.

All of these mappings are stored on the blockchain, and all of them have to be managed in the contract’s methods. Unfortunately, all of them are needed if we want to implement the ERC-721 token standard. So, what we can do to reduce the complexity and the transactional cost of method calls?

If ERC-721 compatibility is not needed then we can do a simple trick. In this case, we can store on the blockchain only the things that are absolutely necessary.

Every other thing can be stored in an external database. If we store the token balances, token lists, etc. in an external (non-blockchain) storage then we don’t need the redundant mappings. The contract will be simpler and the transactions will be cheaper. After the theory, let’s take a look at the code:

Only 24 lines of code. Not bad. But is it really a fully functional NFT contract? Let’s see. It has 2 methods: mint and transfer. The mint method creates a new NFT token. It has 2 parameters

_to

_ipfsHash

The second parameter is a unique hash that points to the metadata on IPFS. In the original ERC-721 specification metadata is pointed by a

tokenURI

An IPFS hash is only 32 bytes, so writing it to the blockchain is cheaper than a URI string. The second reason is that IPFS is immutable. The content cannot be changed, because if it changes the IPFS hash would also change. So, storing the data on IPFS and writing the hash to the blockchain is something like writing the data itself to the blockchain, but much cheaper.

The mint method reads the current value of the

tokenCounter

idToOwner

The transfer method has two parameters

_to

_tokenId

idToOwner

This two method is enough for a fully functional NFT. But what about the balances, ownership queries, etc.? Here comes the external database. When a contract emits an event, it will be stored on the blockchain in the logs.

These logs are available through the JSON-RPC API directly, or you can use the JavaScript API to read them. These logs contain the full transaction history, so they contain every piece of information that is needed. Since they are stored on the blockchain, at every point in time a database can be built from them that contains the token ownership, balances, and every other data that is needed.

To show this, let’s check the ERC-721 methods and how an external database can provide the data.

balanceOf

ownerOf

approve

setApprovalForAll

getApproved

isApprovedForAll

safeTransferFrom

transferFrom

tokenURI

totalSupply

tokenByIndex

tokenOfOwnerByIndex

As you can see, our minimalistic NFT token can do everything that an ERC-721 token can do except the approval logic, but it can be implemented if needed.