What is an ERC?

ERC stands for “Ethereum Request for Comment” This is Ethereum’s version of a Request for Comments (RFC), a concept devised by the Internet Engineering Task Force. Memos within an RFC contain technical and organizational notes. For ERCs, this includes some technical guidelines for the buildout of the Ethereum network.

This was written by Ethereum developers for the Ethereum community. Thus, the workflow of generating an ERC includes a developer. To create standards for the Ethereum platform, a developer submits an Ethereum Improvement Proposal (EIP). This includes protocol specifications and contract standards. Once that EIP is approved by a committee and finalized, it becomes an ERC. The complete list of EIPs can be found here.

The finalized EIPs give the Ethereum developers a set of implementable standards. This allows Smart Contracts to be built with these standards, which a common interface can access. ERC20 is the most well-known of all the standards within the entire crypto community, and most tokens issued on top of the Ethereum platform use it.

Sources link ==> https://github.com/OpenZeppelin/openzeppelin-contracts

ERC20

任何 ERC20 代币都能立即兼容以太坊钱包(几乎所有支持以太币的钱包,包括Jaxx、MEW、imToken等,也支持 erc20的代币

The ERC20 standard includes the following functions:

1
2
3
4
5
6
7
totalSupply() //returns total token supply
balanceOf(address _owner) //returns account balance of _owner’s account
transfer(address _to, uint256 _value) //takes in number _value and transfers that amount of tokens to address _to and triggers transferevent
transferFrom(address _from, address _to, uint256 _value) //transfers _value amount of tokens from the address _from to the address _to, and triggers the transfer event.拥有者从 _from地址给 _to地址转账授权范围内的一定额度的一类同质化通证。
approve(address _spender, uint256 _value) //allows _spender to withdraw any number up to _value amount
allowance(address _owner, address _spender) //returns the amount which the_spender is still allowed to withdraw from the _owner
// 授权给_spender账户一定额度。拥有者 _owner给消费者_spender在当前查询账户授权(approve)的额度。

The following events are triggered based on the functions above:

1
2
transfer(address indexed _from, address indexed _to, uint256 _value) //this is triggered whenever tokens are transferred
approval(address indexed _owner, address indexed _spender, uint256 _value) //is triggered on any call to approve()

ERC20 was proposed in 2015 and officially formalized in September 2017. It is a great starting point for token standardization. However, some in the developer community have noted that it has certain flaws and vulnerabilities. Additionally, there are some use cases that require something different.

另外,https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/token/ERC20

Extensions\扩张功能

Utilities\工具方法

ERC223

Status: Open

Date Proposed: 3/5/2017

一句话:ERC223令牌标准可以防止令牌在以太坊网络上丢失。

A post by developer Dexaran describes these two scenarios in detail:

There are two ways of performing a transaction in ERC20 tokens:

  1. transfer function.
  2. approve + transferFrom mechanism.

Token balance is just a variable in the token contract.

The transaction of a token is a change in the internal variables of the contract. The balance of the sender will be decreased and the balance of the recipient will be increased.

The transfer function will not notify the recipient when the transaction occurs. The recipient will not be able to recognize the incoming transaction! I wrote this illustration of the process that is leading to unhandled transactions and money losses.
As a result, if the recipient is a contract, users must transfer their tokens using the approve +transferFrom mechanism. If the recipient is an externally owned account address, users must transfer their tokens via the transfer function. If a user makes a mistake and chooses the wrong function, the token will get stuck inside contract (contract will not recognize a transaction). There will be no way to extract stuck tokens.

His proposed solution to this issue is contained within ERC223. It is very similar to the ERC20 standard, but it solves the problems described above. When tokens are transferred to a smart contract, a special function of that contract is tokenFallback. This allows the receiving contract to decline the tokens or trigger further actions. This can be used in place of the approvefunction in most cases.

由openzeppelin-contracts SafeERC20 完成。

ERC621

Status: Open

Date Proposed: 5/1/2017

一句话:发行 Token 总量可变。ERC621 = ERC20 + increaseSupply() + decreaseSupply()

ERC621 is an extension of the ERC20 token standard. It adds two additional functions, increaseSupply and decreaseSupply. This can increase and decrease the token supply in circulation. ERC20 only allows a single token issuance event. This restricts the supply to a certain amount which can’t be changed. ERC621 proposes that totalSupply can be modified.

ERC721

Status: Open

Date Proposed: 9/22/2017

一句话:每个代币都是 unique,例如以太猫。

ERC721 is very different than ERC20 and ERC223. It describes a non-fungible token. This means that each token is totally different and each one can have a different value to different users. One way to think about this is to recall CryptoKittes. Each one is its own separate commodity whose value is based on its own rarity and desirability by users.

ERC721 tokens can be used in any exchange, but the token value is “a result of the uniqueness and rareness associated with each token.” The standard functions are name, symbol, totalSupply, balanceOf, ownerOf , approve , takeOwnership , transfer , tokenOfOwnerByIndex, and tokenMetadata. It also defines two events: Transfer and Approval. This article by Gerald Nash does a good job explaining the concept of fungibility as it relates to tokens and goes into good technical detail.

ERC1155

Status: Final

Date Proposed: 2018-06-17

一句话:ERC-1155的创造者是Enjin coin的CTO Witek Radomski。ERC1155标准定义了一种解决上述问题的新方法。现在“物品”(可能包含ERC20的token或ERC721的token或两者都有)可以被单一的一个合约(打包处理)来定义了。合约里包含区别token们所需的最小量的数据。

ERC1155协议主要包括ERC1155Mintable.sol同质化可增发智能合约和ERC1155NonFungibleMintable.sol非同质化可增发智能合约,本章只讲解同质化可增发智能合约的功能。