Previously, we explored the ERC-20 interface, a contract standard which allowed for the implementation of a token contract which the majority of smart contract users are able to easily call. As a result of the ERC-20 standard, many protocols were able flourish without having to worry about incompatible token interfaces. However, there is one thing that the ERC-20 standard did not fix...
To understand the biggest shortcoming of the ERC-20 standard, we have discussed the concept of fungibility. Its design enables crucial fucntionality. However, this also implies that for a use case that requires for 1 unit of some ERC-20 A to be different in value than 1 unit of the same ERC-20 token A, the ERC-20 token standard is not sufficient for such a use case.
To make clear a particular that ERC-20 cannot support, imagine we wanted to represent an art collection within a smart contract. The smart contract would contain the following functionality in a similar fashion to an ERC-20 token:
The ability to query the "balance" (i.e. the art holdings) of a particular user
The ability to transfer art pieces from one account to another
The ability to get information about the art collection
The biggest different between an arbitrary ERC-20 token contract and an art collection is the fungibility of individual items - ERC-20 tokens are inherently fungible with items in the art collections are not (since the items each vary in value).
To account for uses cases like an art collection, the ERC-721 standard was introduced. Formally, ERC-721 is a standard for non-fungible tokens. Below is the interface of the ERC-721 token from its original proposal :
Notice that for an ERC-20 token, we can store the balance of all token holders with the following data structure:
In the case of the ERC-721 token standard, this is not enough, since using just this data structure would imply that all tokens of an ERC-721 contract are fungible. Therefore, we want to use the following data structures:
The balances data structure will map accounts to the number of non-fungible tokens they hold. The data structure holders, meanwhile, will map the ID of each non-fungible token to the address which holds the token. Therefore, by adding just another mapping, we've just allowed our token contract to incorporate non-fungible tokens!