How many transaction operations are required for common token protocol transfers?

When it comes to Ethereum, the first keyword that comes to our mind is probably “gas fee”. Nowadays, when major blockchain projects are launched on their mainnets, the word “gas” is often used in their promotional directions.

High gas fees have always been a pain point for blockchain transactions, especially for investors in various fields of the cryptocurrency circle.

As the number of blockchain projects increases and the market size expands, the number of transactions on the blockchain and the average transaction gas consumption also increase.

Gas price history data in Gasnow

Recently, with the ups and downs of the market and factors such as mainnet upgrades and Layer 2 solutions, the gas fees of blockchain networks led by Ethereum have continued to decline.

In addition to the above factors, is it possible to reduce the number of transactions required to complete specific functions from the perspective of code or smart contract design, thereby optimizing the transaction costs and environment of the project and the entire blockchain?

Today, this article will introduce you to this topic: comparing 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 option 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()/transferFrom().

Therefore, it must be divided into two transactions and two Gas payments must be made: 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. The first two have been perfected, and ERC2612 is still in the optimization stage.

The main participants in ERC20 are the token sender and the token receiver.

In the following, we will take Alice as the token sender and Bob as the token receiver as an example to show you a brief operation flow chart.

ERC20 token transfer operation flow chart

ERC777

ERC777 attempts to introduce the concept of operator to circumvent the “two-step” problem.

After the operator is authorized by the sender, in the ERC777 token contract, the sender can send tokens to the receiver through the operator.

In the transaction of sending tokens, the sender does not need to pay gas, and the gas for sending token transactions will be paid by the operator.

ERC777 token transfer operation flow chart

ERC1363

ERC1363 introduces high-level functions inspired by approve(), transfer() and transferFrom() in ERC20: approveAndCall(), transferAndCall() and transferFromAndCall().

These functions can help the ERC1363 protocol contract continue to execute the onApprovalReceived() method of the smart contract at the spender address and the onTransferReceived() method of the smart contract at the receiver address after completing approve(), transfer() or tranferFrom().

In this way, approve and transfer or any other code that the spender or receiver wants to execute can be linked together into a transaction.

ERC1363 token transfer operation flow chart

ERC2612

ERC2612 uses user signature for approval, and the signature includes the approved address and amount.

The user submits the signature to the ERC2162 standard contract, and then the ERC2162 standard contract verifies the signature, obtains the approved address and amount from the signature, and uses the information obtained from the verification to directly trigger the transferFrom operation after the verification is successful, thereby ultimately solving the "two-step" problem.

ERC2612 token transfer operation flow chart

Written at the end

After comparing these types of protocols, we found that:

From the perspective of the number of transactions required to complete the token sending, ERC1363 and ERC2612 are definitely more suitable choices, among which ERC2612 is more flexible than ERC1363. At the same time, ERC777, ERC1363 and ERC2612 are all compatible with ERC20 type contracts, so there are no problems caused by compatibility.

As the number of blockchain smart contract projects increases, the total number of waiting transactions generated within a single block increases accordingly.

If the total number of waiting transactions that need to be packaged into blocks to complete functions can be reduced at the protocol code level, it will greatly help the average transaction speed and average gas cost on the blockchain.

The optimization of transaction costs and environment will not only promote the prosperity of the blockchain network, but also make the blockchain ecology and infrastructure more perfect.