When it comes to Ethereum, the first thing that comes to mind may well be “gas fee”. Nowadays, the mainnet of major blockchain projects are online, and their synonyms for ‘transaction fees’ are often inseparable from the word “gas”.
The high gas fee has always been a sore point for blockchain transactions, especially for smaller scale investors. With the increase of blockchain projects and the expansion of the market, the number of transactions on the blockchain and the average gas consumption of transactions has increased.
Here we can insert some historical data of Gas price
Recently, with the ups and downs of the market, mainnet upgrades, Layer 2 solutions and other factors, the average gas fee of the Ethereum blockchain has continued to decline. In addition to the above factors, can it be possible to reduce the number of transactions necessary to complete a specific function from the perspective of code or smart contract design, so as to optimize the environment of the transactions and the entire blockchain? In this article we’ll compare several protocols that are compatible with the most common token protocol ERC20, including ERC777, ERC1363 and ERC2612.
This article will help you find the best choice of token standard by analyzing the number of transactions required for token transfer operations in several protocols!
ERC20
Currently, the transfer operation of ERC20 protocol tokens requires two steps: approve() and transfer()/tranferFrom(). Therefore, it must be divided into two transactions and two separate gas fees must be paid. The first transaction completes the authorization and the second transaction completes the transfer. In order to solve the “two-step” problem, the current main proposals are ERC777, ERC1363 and ERC2612, of which the first two have been improved, and ERC2612 is still in the optimization stage. The main participants in ERC20 are the senders of tokens and the receivers of tokens. In the following, we will take Alice as the token sender and Bob as the token receiver as an example to visually show you a brief flow chart of the operation.
Brief flow chart of ERC20 token transfer operation
ERC777
ERC777 tries to introduce the concept of operator to avoid the “two-step” problem. After the operator is authorized by the sender, in the ERC777 token contract, the sender can send the tokens to the receiver through the operator. In this transaction, the sender does not need to pay gas, and the gas for sending the token transaction will be paid by the operator.
Brief flow chart of ERC777 token transfer operation
ERC1363
ERC1363 introduces advanced functions inspired by approve(), transfer() and tranferFrom() in ERC20: approveAndCall(), transferAndCall() and transferFromAndCall(). These functions can help the ERC1363 protocol contract continue to execute the onApprovalReceived() method at the sender address and the onTransferReceived() method at the receiver address after completing the approve(), transfer() or tranferFrom(). In this way, the approve and transfer or any other code that the sender or receiver wants to execute are combined into a single transaction.
Brief flow chart of ERC1363 token transfer operation
ERC2612
ERC2612 adopts the method of user signature for approve, and the signature contains the address and quota of the approve. The user submits the signature to the ERC2162 standard contract. After the verification is successful, then the ERC2162 standard contract verifies the signature, obtains the address and quota of the approve from the signature, and uses the information obtained from the verification to directly trigger the transferFrom operation, thereby finally solving the “two-step” problem.
Brief flow chart of ERC2612 token transfer operation
After comparing these types of protocols, we found that: from the perspective of the number of transactions required to complete the token delivery, ERC1363 and ERC2612 are definitely more suitable choices. Besides, ERC2612 is more flexible than ERC1363. At the same time, ERC777, ERC1363 and ERC2612 are compatible with ERC20 type contracts, so no problem will be caused by compatibility.
With the increase of smart contracts built on top of blockchains, the total number of pending transactions generated within a single block will increase. If the total number of pending transactions that need to be packaged into the block to complete the function can be reduced through the protocol code level, it will be of great help to the average transaction speed and average gas cost on the blockchain. The optimization of transaction costs and the environment will not only promote the prosperity and accessibility of the blockchain network, but also improve the blockchain ecology and infrastructure.
