You've probably read about NFTs and associate them with artworks of Apes that have sold for millions of dollars. In this post, I'll tell you what nfts actually are, whether the technology can be used for things other than art and how the technology behind nfts actual works. I promise the latter is so simple it will blow your mind.
In order to dive into the topic, you first need to understand what a None-Fungible-Token (NFT) is. You may have heard that an NFT is something unique and irreplaceable, just like a piece of art. This is true but very abstract and does not really explain the difference between fungible and non-fungible. It is much easier to distinguish fungible tokens from non-fungible tokens by means of an example.
If you give me a dollar and I give you back a dollar, you will certainly be just as happy as before. Nothing has changed for you, the value you perceive is the same even if the serial number of the dollar bill has changed. You probably didn't know the number anyway. This is because the dollar is made to be a fungible token (FT), so it is easy to replace it. The same applies to a Bitcoin, of course.
Now let's look at a non-fungible scenario. If you give me the Mona Lisa and I give you Salvator Mundi, would you be as satisfied as in the dollar example? Certainly not. Even though both might have the same financial value, they are simply too different. You would immediately notice that something has changed.
Let’s move from an Art example to a slightly more complicated movie ticket example. If you have a ticket for Star Wars, it cannot be exchanged with a movie ticket for James Bond but what if a Star Wars ticket is to be exchanged for another Star Wars ticket? In a movie theater, the ticket would still differ from another ticket by the seat. If there is no seat assignment on the ticket, then from a technical point of view it is not an NFT but a non-splitable FT. Confusingly, the term NFT has also become accepted for scenarios where you have a limited supply.
For the further course of this blog, I often refer to this cinema example. Therefore, make sure you understand what the difference between NFT and FT is. To reduce the confusion, I use the term NFT exclusively for really unique tokens.
NFT/FTs are created through smart contracts. A smart contract is basically nothing more than executable code stored on the blockchain. Since data written to the blockchain cannot be changed, the smart contract code cannot be changed either. It is therefore a contract that is valid forever.
In the case of NFTs, the contract is mainly responsible for creating a limited supply of tokens. This process is called minting. Unfortunately, these smart contracts are also often called NFTs. In the cinema example, this means that the cinema i.e., the ticket issuer, is the minting smart contract and the movie ticket is a FT or NFT issued by this smart contract.
The created token does not hold a lot of data like an image of an Ape. Since you pay for every byte stored on the blockchain, the data is typically limited to a token id and a reference to an external resource. The token id would allow a differentiation between Star Wars, James Bond or the seat. The reference could link to a website with an image or further information like the time when the movie starts.
To design such a smart contract there are currently two established standards ERC721 and ERC1155 which describe a set of methods and events that an NFT smart contract must have. If you are a programmer such a standard is basically a programming interface.
In the following I will explain the two NFT standards in detail.
The ERC721 standard was the first established NFT smart contract standard and is characterized by its simplicity. In the blockchain world, simplicity is a very important aspects as it avoids critical errors in the unfixable smart contract world.
By design the ERC721 can only produce NFTs and not FTs. In this standard a 1 to 1 relation between a unique token id and a token owner is established. This means a Star Wars ticket smart contract that issues movie tickets would issue the ticket in the form of a token with a unique seat number as the token id. No two people cloud own the same ticket. In the case of cinema tickets, this makes perfect sense as usually not two people sit on one seat.
For tickets to other movies like James Bond, a new James Bond smart contract would have to be deployed. This makes the standard very expensive, since each new film would require a new smart contract.
To understand what happens behind the scenes i.e., how a NFT is created and transferred, it is worth to analyze the basic implementation of ERC721 by OpenZeppelin, the de facto standard Ethereum programming library.
Let’s take a look at the heart of the smart contract - the magical minting process (see Figure 1). The method takes a receiver of the NFT and the token id and then? After checking that the token id does not exists before, it just sets the value of two variables? Yes! A NFT and a Ethereum token in general is that simple. A token is nothing else then a counter in a smart contract called “balances” and a mapping from a token id to a person’s account called “owners”.
Figure 2 shows the internal smart contract state in the Star Wars movie ticket example. Alice, who is assigned account 0x123, and Bob, who owns account 0xABC, buy a ticket to the movie. Alice decides to buy the ticket for seat 1. In the smart contract, her token ID i.e., the ID assigned to the seat, is linked to her account in the owners variable. Additionally, the balance for her account is linked, since she now owns one ticket. Bob cannot buy seat 1 anymore, because Alice has already bought this seat/token ID. Instead, Bob buys a ticket for seat 2. Just as with Alice, in the owners variable, the token ID for seat 2 is linked to Bob's account address and his balance is also increased by one. In the tickets there is a reference to the movie website where Alice and Bob can get more information like the start time of the movie. If Alice or Bob wanted to buy two tickets, they typically would have to make two transactions.
Now that we know that minting is just filling two variables, we can deduce how a NFT transfer works (see Figure 3). Namely we perform a variable change again. In the balances the sender loses one NFT and the receiver gets one. The property i.e., the token id, is then assigned to the receiver in the next step.
If Alice sells her ticket to Bob, she makes a transfer request to the smart contract. This decrements her number of tickets, increments the number of tickets Bob owns, and transfers the ownership of ticket 1 to Bob's address (see Figure 4).
The ERC1155 standard is a further development of the ERC721. Unlike the ERC721, it allows the generation of multiple NFTs as well as multiple FTs in a single smart contract. This means that Star Wars tickets with seats (NFTs) and James Bond tickets without fixed seat numbers (non-splitable FTs) can be offered in a general cinema smart contract. This makes the smart contract much cheaper. In addition ERC1155 allows you to buy or transfer a bunch of tickets at once, which consequently reduces the price, because you have to pay less transaction fees.
Again a look at the OpenZepplin implementation of the ERC1155 explains how this is working. From the code side, this seems to be even simpler than the ERC721.
Internally the ERC1155 implementation no longer has two variables that map token ids to owners and owners to balances. Instead, if look into the minting code we see that a double mapping is used (see Figure 5). This maps a token id to another map consisting of several owner addresses which than map to the number of NFTs/FTs owned. So, it is possible that several addresses have the same token id in any number. To represent a NFT, the maximum number of tokens of a token type, which is represented by the token id, is just limited to one. To represent FTs, the maximum number of tokens can be chosen arbitrarily.
Let's look at the ticket example again. Here we consider a FT example (Tickets without seat), since this represents the generalization of an NFT. This time Alice is able to buy three tickets for movie 1, Star Wars, in one transaction (see Figure 6). Internally, Alice's address is added to the owner list of token ID 1 for movie 1. Since she buys three tickets, her balance is set to 3. Alice pays less for three ticket purchases using ERC1155 than for transactions using ERC721, since she would have to make three individual purchases there and thus also pay 3x fees.
Similar to minting, the ERC1155 is able to transfer multiple tokens in one transaction (see Figure 7). Therefore a parameter "amount" was added to the method. Similar to the ERC721 only the variable "balances" is updated internally. This is done by reducing the number of tokens the sender owns and increasing the number of tokens the receiver owns.
Since smart contracts are just normal code, we can basically make any adjustments we want. An upcoming example is that we let ourselves pay for the resale of FTs/NFTs. We would modify the transfer event so that a certain amount is transferred directly to our account. A cinema could therefore earn money from the ticket trade.
By recording transactions on the blockchain, FTs/NFTs also enable tracking. The technology thus offers new insights into the customer behavior, which in turn can help to improve products
In summary, from a programming perspective, FTs/NFTs are nothing more than setting a variable. From a user perspective, however, they are much more. Due to the immutability of the blockchain, the number of token IDs cannot be increased subsequently. With ft/nft, we are therefore dealing with programmed digital scarcity. A very interesting concept that has only been made possible in this way by the blockchain world.
Digital scarcity is even superior to physical scarcity in some respects. For example, the authenticity of an NFT can be verified in seconds. Verifying the authenticity of a handwritten signature, on the other hand, requires experts.
Also, earning money from products that have already been sold, tracking and analyzing them, opens up unprecedented opportunities.
What is an NFT?
In order to dive into the topic, you first need to understand what a None-Fungible-Token (NFT) is. You may have heard that an NFT is something unique and irreplaceable, just like a piece of art. This is true but very abstract and does not really explain the difference between fungible and non-fungible. It is much easier to distinguish fungible tokens from non-fungible tokens by means of an example.
If you give me a dollar and I give you back a dollar, you will certainly be just as happy as before. Nothing has changed for you, the value you perceive is the same even if the serial number of the dollar bill has changed. You probably didn't know the number anyway. This is because the dollar is made to be a fungible token (FT), so it is easy to replace it. The same applies to a Bitcoin, of course.
Now let's look at a non-fungible scenario. If you give me the Mona Lisa and I give you Salvator Mundi, would you be as satisfied as in the dollar example? Certainly not. Even though both might have the same financial value, they are simply too different. You would immediately notice that something has changed.
Let’s move from an Art example to a slightly more complicated movie ticket example. If you have a ticket for Star Wars, it cannot be exchanged with a movie ticket for James Bond but what if a Star Wars ticket is to be exchanged for another Star Wars ticket? In a movie theater, the ticket would still differ from another ticket by the seat. If there is no seat assignment on the ticket, then from a technical point of view it is not an NFT but a non-splitable FT. Confusingly, the term NFT has also become accepted for scenarios where you have a limited supply.
For the further course of this blog, I often refer to this cinema example. Therefore, make sure you understand what the difference between NFT and FT is. To reduce the confusion, I use the term NFT exclusively for really unique tokens.
Where does the NFT or FT comes from?
NFT/FTs are created through smart contracts. A smart contract is basically nothing more than executable code stored on the blockchain. Since data written to the blockchain cannot be changed, the smart contract code cannot be changed either. It is therefore a contract that is valid forever.
In the case of NFTs, the contract is mainly responsible for creating a limited supply of tokens. This process is called minting. Unfortunately, these smart contracts are also often called NFTs. In the cinema example, this means that the cinema i.e., the ticket issuer, is the minting smart contract and the movie ticket is a FT or NFT issued by this smart contract.
The created token does not hold a lot of data like an image of an Ape. Since you pay for every byte stored on the blockchain, the data is typically limited to a token id and a reference to an external resource. The token id would allow a differentiation between Star Wars, James Bond or the seat. The reference could link to a website with an image or further information like the time when the movie starts.
To design such a smart contract there are currently two established standards ERC721 and ERC1155 which describe a set of methods and events that an NFT smart contract must have. If you are a programmer such a standard is basically a programming interface.
In the following I will explain the two NFT standards in detail.
NFT Contracts (ERC721)
The ERC721 standard was the first established NFT smart contract standard and is characterized by its simplicity. In the blockchain world, simplicity is a very important aspects as it avoids critical errors in the unfixable smart contract world.
By design the ERC721 can only produce NFTs and not FTs. In this standard a 1 to 1 relation between a unique token id and a token owner is established. This means a Star Wars ticket smart contract that issues movie tickets would issue the ticket in the form of a token with a unique seat number as the token id. No two people cloud own the same ticket. In the case of cinema tickets, this makes perfect sense as usually not two people sit on one seat.
For tickets to other movies like James Bond, a new James Bond smart contract would have to be deployed. This makes the standard very expensive, since each new film would require a new smart contract.
To understand what happens behind the scenes i.e., how a NFT is created and transferred, it is worth to analyze the basic implementation of ERC721 by OpenZeppelin, the de facto standard Ethereum programming library.
Minting
Let’s take a look at the heart of the smart contract - the magical minting process (see Figure 1). The method takes a receiver of the NFT and the token id and then? After checking that the token id does not exists before, it just sets the value of two variables? Yes! A NFT and a Ethereum token in general is that simple. A token is nothing else then a counter in a smart contract called “balances” and a mapping from a token id to a person’s account called “owners”.
Figure 1: OpenZeppelin ERC721 Minting function. This function is used to create a new NFT. The orange boxes indicate the important aspects of the minting process. As you can see a NFT is basically nothing else than a smart contract variable.
Figure 2 shows the internal smart contract state in the Star Wars movie ticket example. Alice, who is assigned account 0x123, and Bob, who owns account 0xABC, buy a ticket to the movie. Alice decides to buy the ticket for seat 1. In the smart contract, her token ID i.e., the ID assigned to the seat, is linked to her account in the owners variable. Additionally, the balance for her account is linked, since she now owns one ticket. Bob cannot buy seat 1 anymore, because Alice has already bought this seat/token ID. Instead, Bob buys a ticket for seat 2. Just as with Alice, in the owners variable, the token ID for seat 2 is linked to Bob's account address and his balance is also increased by one. In the tickets there is a reference to the movie website where Alice and Bob can get more information like the start time of the movie. If Alice or Bob wanted to buy two tickets, they typically would have to make two transactions.
Figure 2: ERC721 Movie ticket smart contract for a single movie. Alice and Bob both buy a ticket for Star Wars. Since each ticket must be unique they are not allowed to buy the same ticket. The ownerships of the tickets are stored in the smart contract.
Transfer
Now that we know that minting is just filling two variables, we can deduce how a NFT transfer works (see Figure 3). Namely we perform a variable change again. In the balances the sender loses one NFT and the receiver gets one. The property i.e., the token id, is then assigned to the receiver in the next step.
Figure 3: ERC721 transfer code. The old owner loses an NFT (decrementing), the new owner gets an NFT (incrementing). In the owners variable it is defined which NFT he gets.
If Alice sells her ticket to Bob, she makes a transfer request to the smart contract. This decrements her number of tickets, increments the number of tickets Bob owns, and transfers the ownership of ticket 1 to Bob's address (see Figure 4).
Figure 4: ERC721 movie ticket transfer example. Alice has transferred her ticket to bob. Therefore, the token id (ticket) is now owned by bob. In the balances we can see that he owns 2 tickets and Alice 0.
NFT Contracts (ERC1155)
The ERC1155 standard is a further development of the ERC721. Unlike the ERC721, it allows the generation of multiple NFTs as well as multiple FTs in a single smart contract. This means that Star Wars tickets with seats (NFTs) and James Bond tickets without fixed seat numbers (non-splitable FTs) can be offered in a general cinema smart contract. This makes the smart contract much cheaper. In addition ERC1155 allows you to buy or transfer a bunch of tickets at once, which consequently reduces the price, because you have to pay less transaction fees.
Again a look at the OpenZepplin implementation of the ERC1155 explains how this is working. From the code side, this seems to be even simpler than the ERC721.
Minting
Internally the ERC1155 implementation no longer has two variables that map token ids to owners and owners to balances. Instead, if look into the minting code we see that a double mapping is used (see Figure 5). This maps a token id to another map consisting of several owner addresses which than map to the number of NFTs/FTs owned. So, it is possible that several addresses have the same token id in any number. To represent a NFT, the maximum number of tokens of a token type, which is represented by the token id, is just limited to one. To represent FTs, the maximum number of tokens can be chosen arbitrarily.
Figure 5: ERC1155 minting code. The balances for a token id that refers to an owner account get adjusted by the ordered amount. In the case of FTs this can be more than one.
Let's look at the ticket example again. Here we consider a FT example (Tickets without seat), since this represents the generalization of an NFT. This time Alice is able to buy three tickets for movie 1, Star Wars, in one transaction (see Figure 6). Internally, Alice's address is added to the owner list of token ID 1 for movie 1. Since she buys three tickets, her balance is set to 3. Alice pays less for three ticket purchases using ERC1155 than for transactions using ERC721, since she would have to make three individual purchases there and thus also pay 3x fees.
Figure 6: ERC1155 general movie ticket smart contract. Alice buys three tickets for the same movie. Bob buys two different tickets. Since Alice buys three tickets for the same movie, she only needs one transaction. Bob, on the other hand, needs two transactions because he buys one ticket each for different movies.The ownership of the tickets, including the quantity of them, is stored in the smart contract.
Transfer
Similar to minting, the ERC1155 is able to transfer multiple tokens in one transaction (see Figure 7). Therefore a parameter "amount" was added to the method. Similar to the ERC721 only the variable "balances" is updated internally. This is done by reducing the number of tokens the sender owns and increasing the number of tokens the receiver owns.
Figure 7: ERC1155 transfer code. We can pass the amount of tokens of a specific token id that should be transferred from the sender to receiver. Internally the balance of the sender and the receiver gets updated.
Figure 8: ERC1155 Movie ticket transfer example. Alice transfers 2 of her Star Wars tickets (Movie 1) to Bob. This happens in a single transaction. Bob owns now 4 tickets in total.
What else can we do?
Since smart contracts are just normal code, we can basically make any adjustments we want. An upcoming example is that we let ourselves pay for the resale of FTs/NFTs. We would modify the transfer event so that a certain amount is transferred directly to our account. A cinema could therefore earn money from the ticket trade.
By recording transactions on the blockchain, FTs/NFTs also enable tracking. The technology thus offers new insights into the customer behavior, which in turn can help to improve products
Conclusion
In summary, from a programming perspective, FTs/NFTs are nothing more than setting a variable. From a user perspective, however, they are much more. Due to the immutability of the blockchain, the number of token IDs cannot be increased subsequently. With ft/nft, we are therefore dealing with programmed digital scarcity. A very interesting concept that has only been made possible in this way by the blockchain world.
Digital scarcity is even superior to physical scarcity in some respects. For example, the authenticity of an NFT can be verified in seconds. Verifying the authenticity of a handwritten signature, on the other hand, requires experts.
Also, earning money from products that have already been sold, tracking and analyzing them, opens up unprecedented opportunities.
- SAP Managed Tags:
