Now that we know a little more about tokens, we are going to delve into another very important concept in Ethereum development which is ERCs, Ethereum Request for Comments.
The ERCs, Ethereum Request for Comments, are proposals generated by the community or the Ethereum developers themselves in order to promote this blockchain platform, generating interoperability in the ecosystem and facilitating the integration of these by applications that make use of tokens. standards medium. In turn, ERCs are nothing more than a type of EIP (Ethereum Improvement Proposal) at the application level, which to become standards must first go through consultation and review phases until they are approved.
Next we are going to discuss the main ERCs token standards that exist today:
Currently, although its functionality is basic, it is the most widely used and most relevant standard due to its great interoperability in the environment.
Provide the methods of token transfer (transfer), approval or authorization of use of your tokens to another Ethereum address (profit), authorized token transfer from another Ethereum address (transferFrom), current balance query (balanceOf) and query of the amount of tokens possible to use on behalf of another Ethereum address (allowance). In addition, there are two types of events (Transfer and Approval) that are triggered when a transfer or approval is made.
To characterize the token, a value must be assigned to a series of attributes in the form of a variable. The only mandatory parameter is the number of total available tokens (totalSupply), the others such as the name (name), the symbol (sym) and the number of decimals (decimals) are optional, although important if you want to give more detail to your token and distinguish it from others. The number of decimal places offers the ability to subdivide a token unit into 18 decimal places.
But, where is the balance of each user who owns that token kept? Good question. To save the balances, a 'mapping' type variable is used, which relates an Ethereum address with its corresponding token balance: (mapping (Address => uint256) balances)
In the 'Etherscan' explorer you can check the number of existing tokens deployed in the main Ethereum network, as well as their value and more information. At the time of writing this article there were 125,699 ERC20 tokens. Probably when you look back at this number it has grown quite a bit, as new ones are being deployed every day.
The ERC721 is the standard of NOT fungible token par excellence (called NFT, Non Fungible Tokens). The concept of "NO fungibility" comes to say that it is unique and cannot be replaced by another. Another characteristic resulting from the above is its indivisibility, since it remains as a singular unit, unlike the ERC20. It is therefore a non-consumable token, but it is exchangeable. It can represent anything from ownership of a work of art to a loan or a traffic ticket. An example of a non-fungible token could be the ownership of a house, since it is something unique and indivisible that when you transfer it to another person it becomes part of their property and you would stop owning it. The example of a fungible token would be money, where a monetary unit (for example, a € 1 coin) is equal and has the same value as another monetary unit (another € 1 coin).
Each ERC721 token is identified by a unique, non-modifiable ID (uint256, 256-byte integer), and an Ethereum address. It implements the ERC20 methods, attributes and events (name, symbol, totalSupply, balanceOf) in order to have compatibility between applications, even if it does not make the same use of them. For example, in the case of the decimal (decimals) attribute, it must correspond to a 0, since as we have mentioned it is an indivisible standard. In addition, it provides new methods such as the secure transfer of token (safeTransferFrom), previously verifying that the address that carries out the transfer is that of the owner of the token; property (ownerOf), to query the address to which the token belongs; or taking ownership of the token (takeOwnership), from an authorized address.
Other possible implementations to carry out can be to reject transfers if the contract is paused, create a list of safe or authorized addresses, reject non-secure transfers, charge the cost of the transaction to both parties, etc.
At the moment, its use is inferior to the ERC20, although it must be recognized that its future is very promising. In the 'Etherscan' explorer it can be seen that there are 262 ERC721 tokens deployed on the Ethereum mainnet.
The most popular application example using this ERC721 standard is CryptoKitties. It is a decentralized application that allows you to acquire, collect and exchange kittens, among other things. Although it seems like a silly game, the approach is really valuable, since for the first time you are the owner of a unique digital asset that you can trade with others in a decentralized way.
Other possible ERC token standards
In addition to the main ERC20 and ERC721 standards, there are others that are in the draft phase waiting to be approved or rejected. Let's see a summary of the most interesting:
Token ERC-777 - New Advanced Token Standard
It is an improvement of the ERC20 that incorporates more advanced functionalities such as:
- Implement a send function: send (to, amount, data), instead of the usual transfer function: transfer (to, amount).
- It allows to control and reject tokens sent / received by registering “hook” functions: tokensToSend (operator, from, to, amount, data, operatorData), tokensRecieved (operator, from, to, amount, data, operatorData). It is useful, for example, to give the sender or recipient the option to intervene in the transfer and even reject it.
- Incorporates the figure of “authorized operators”. It allows authorizing or revoking addresses of Smart Contracts or users to move tokens on behalf of the owner and create additional functionalities to the token: autorhizeOperator, revokeOperator
Token ERC-823 - Token Exchange Standard
Development of ERC20 that incorporates an exchange service facilitating cross payments of tokens. It allows the holder of an ERC20 token to exchange it with another ERC20 using an exchange token to make the transfers: exchangeToken (targetContract, amount). It implements variables of type “mapping” to relate: address and amount of the exchanged token (exchangedWith); address of the person initiating the exchange and the amount (exchangedBy); and the amount of tokens received and the address of the person who issued it (exchangesReceived).
Token ERC-918 - Mineable Token Standard
Minable token standard that uses the “Proof of Work” algorithm for its own distribution. The tokens are distributed following the IMO model, “Initial Mining Offering”, as if it were an ICO. Implement a mint () function that acts as a tap controlling the rate of token distribution and minimizing costs.
Token ERC-998 - Composable Non-Fungible Token Standard
Improvement of the ERC721 standard that allows a token to own or be owned by ERC721 and ERC20 tokens, so that they can have “child tokens” or “parent tokens” respectively. It allows to form property trees based on the relationship between each token as if it were a family tree.
ERC-1080 Token - Recoverable Token Standard
ERC20 standard development supports the return, theft prevention and recovery of tokens. Functions of the type must be implemented: claimLost (Address lostAccount), reportStolen (), chargeBack (uint256 pendingTransferNumber). All of them must return the success or failure of the operation as a response (boolean type).
How to implement my own tokens for applications
Creating a token is very simple, just use a template that implements any ERC standard and characterize it in your own way, but creating it to be efficient and secure is not so easy. In general, all standards are just a pattern or scheme to follow that needs to be shaped, and that is where the problem arises. For example, inside the transfer () function, you could develop malicious logic so that, for each transfer, an X amount of tokens is increased in your favor. You could also implement a token in a correct but vulnerable way, losing all balances or even causing the destruction of the token.
For all this, it is advisable to use resources such as Truffle or OpenZeppelin for the development of secure Smart Contracts. In the OpenZeppelin GitHub repository you will find examples of token implemented and ready to be used.
The token world is still in a stage of maturity and growth. There is still a long way to go to digitize everything that surrounds us. What we cannot deny is that the Token is going to represent a paradigm shift in the way of exchanging, transferring and giving value to assets.