NFT is a new/old buzzword of the blockchain world. The NFT standard ( ) was created in 2018, but after CrptoKitties this field was relatively silent. EIP-721 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 (fungible) tokens, NFT (non-fungible tokens) are also simple “databases” on the blockchain. ERC20 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 , you will find a complex token logic and many internal state variables. 0xcert’s implementation 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 ( uint256[]) internal ownerToIds;
mapping ( uint256) internal idToOwnerIndex;
mapping ( address) internal idToOwner;
mapping ( uint256) private ownerToNFTokenCount; => address => uint256 => uint256 => address The mapping contains the token IDs that are assigned to the Ethereum address, is a token ID -> Ethereum address mapping, assigns the token ID to the index of the owner’s token array, and finally, assigns the owners Ethereum address to the token count (how many NFT are owned by the owner). 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 and . The first parameter is the target Ethereum address that will own the newly minted token. _to _ipfsHash The second parameter is a unique hash that points to the metadata on . In the original ERC-721 specification metadata is pointed by a . Why do we use an IPFS hash instead? There are many reasons. IPFS 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 method reads the current value of the variable to get a unique token ID. The method increments this variable by every call, so the token ID will be absolutely unique. The method stores the token ID - Ethereum address assignment into the mapping, which is the only one mapping what we store on the blockchain. In the last step, the method emits a Mint event, which will be very important later. mint tokenCounter idToOwner The method has two parameters and . The first parameter is the target address that will own the NFT, and the second parameter is the ID of the token. The first line of the method checks the ownership of the token using the mapping. Only the token owner can call the transfer method. If the token owned by the caller, then the method modifies the assignment in the mapping and emits a Transfer event. transfer _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 , it will be stored on the blockchain in the logs. event These logs are available through the 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. JSON-RPC API To show this, let’s check the ERC-721 methods and how an external database can provide the data. - These can be easily calculated from Mint and Transfer events balanceOf , ownerOf - Our minimalistic NFT doesn’t provide approval logic, only the owner can transfer the tokens. If needed, this feature can be implemented by a second mapping. approve , setApprovalForAll , getApproved , isApprovedForAll - Transfer safety can be checked externally, and from parameter is meaningless here, because our tokens can be transferred only by the owner. safeTransferFrom , transferFrom - The URI of the token can be generated from the IPFS hash part of the Mint event. tokenURI - These can be calculated easily from the Mint and Transfer events. 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.

Ethereum

Target

2022 - HackerNoon Contributor of the Year - Dao

2022 - HackerNoon Contributor of the Year - Neural Networks

2022 - HackerNoon Contributor of the Year - Proof Of Stake

2022 - Ios Writer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Neural Networks

Nominated for 2022 - HackerNoon Contributor of the Year - Proof Of Stake

Nominated for 2022 - HackerNoon Contributor of the Year - Dao

Nominated for 2022 - Ios Writer of the Year

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

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

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

Too Long; Didn't Read

Company Mentioned

Coin Mentioned

Laszlo Fazekas

About Author

TOPICS

Languages

THIS ARTICLE WAS FEATURED IN...

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

Too Long; Didn't Read

Company Mentioned

Coin Mentioned

Laszlo Fazekas

About Author

TOPICS

Languages

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES