Hashgard Development Geeks — How to Achieve Bulk Transfer on Etherum

ETH congestion troublesome — exchange mechanism

7 min readAug 16, 2018

As the most widely used smart contract network, ETH is subject to network congestion due to the constraints of TPS (current ETH block production speed is 14 seconds/block, each block contains about 140 transactions, which equals 10 transactions per second). Therefore, developers must consider congestion and transaction fees before beginning any designs.

Initiating a transaction on ETH, the miner charges a gas fee to package the transaction into the next block. To explain the process better, we use simple analogies to explain the whole process.

Work Load = Fuel Cost

Gas Limit = Fuel Amount（Fixed）

Gas Price（Unit：Gwei） = Unit Cost of Fuel

Miners = Gas Station Owner

Transaction fee = Work Load (Fuel Cost)= Gas Limit (Fuel Amount) x Gas Price (Unit cost of Fuel)

Due to restriction in number of TPS of each block, to maximize profit, miners will prioritize transactions that pay the highest gas price. Usually, ETH recommends a gas price to ensure reasonable prices and fast speed of transaction. As increased transactions waiting to be processed result in congestion, users will significantly increase the gas price to budge in front of other transactions. A negative feedback loop happens as more and more users put increasingly higher gas prices. Gas price keeps on increasing, resulting sometimes in a gas price that’s 10 times the normal price, or 100 times.

The photo above is the data of observed gas price. The bottom blue line and green line are respectively safe prices and proposed prices from etherscan.io. The middle teal line is the standard gas price given by ETH nodes under default setting. (Standard Gas Price is the average gas price calculated from some recent blocks, multiplied by a constant) Safe price is calculated from nodes on etherscan.io. When sending transactions, do not set a lower gas cost than the safe price, otherwise, you may not find details regarding this transaction on etherscan.io temporarily. Standard Gas Price is usually higher than the Safe Price from Etherscan.io. Setting gas as Standard Gas Price, will usually get the transaction processed in a few minute. Meanwhile, the Proposed Price is a prioritized method, usually processed in a few blocks.

- 02 -

ETH Congestion Problem — Batch Transfer

In the case of candy boxes, entities such as exchanges often require bulk trading. Although it is possible to issue multiple transactions at once by accumulating the nonce value, the issued transaction enters the unconfirmed trading pool and will only complete until they are packaged into the block. When these batch transactions are packaged depends on the network congestion and the Gas Price set by the users.

The following paragraph intends to explain what nonce is in ETH. According to the ETH account system mechanism, transactions sent from any addresses contain a sequence number, starting from 0. When the next transaction sent from the same address is packaged into the block, the sequence number is increased by 1. The numbering system which is used to record the order and quantity of transaction history is called nonce. If address A wants to send the 10th transaction after the previous 9 transactions were all sent successfully, the nonce is set as 9 (starting from 0). If setting as 10, the minors will have to wait for the occurrence of transaction with a nonce of 9 and the one with a nonce of 10 will not be able to be packaged into the block. As a result, minors will have to enforce the transactions based on numerical value of the nonce. If there are two transactions with a nonce of 9, node will choose the one with higher transaction fees and will not process the other transaction.

As shown on the graph, when there are 10 transactions issued from address A and are packaged into the block, the nonce value is 9 (starting from 0). Therefore, transactions with nonce values of 10, 11, 12 will be packaged by minors based on their orders. Those unapproved transactions are pending. However, since a transaction with a nonce of 13 is missing, the transaction with a nonce of 14 is temporarily impossible for the miners to be included in the group of candidate transactions ready to be packaged; instead, it is in a queued state. Once a transaction with a nonce of 13 appears in the trading pool, the transaction with a nonce of 14 is likely to be packaged.

Consequently, if a certain address issues a batch of transactions and the Gas Price of a transaction is too low, according to the nonce mechanism, the system will not process any transactions behind that transaction, causing the batch transmission to stagnate.

- 03 -

Strategies that Can be Taken When Congestion Occurs

If there are network congestions, a ‘multi-quantity and multi-address’ strategy will be established. It first sets up a water ceiling; when an address in the pending queue has 50 incomplete transactions in the trading pool, it will be blocked from sending transactions until those 50 transactions are packaged by the minors. Furthermore, multiple addresses will be used to send transactions to avoid the collapse of tool module resulted by a single transaction congestion. Besides, if a transaction is pending for a long time, the transaction can be resent with a higher and more reasonable Gas Price. The node of minors will replace the old transactions with the new one, which can often solve the congestion problems. Such dynamic compensation mechanism is widely used by exchange institutions and wallets.

This strategy aims to ensure the normal operations of applications and users’ experience, increasing Gas Price and fees consumption fundamentally. If there are approaches to reduce gas consumption of a single transactions, the transaction fees will be lower.

- 04 -

Batch Transfer at the Contract Level

Assuming that an ERC20 Token is sent from an address to 10 addresses, the current approach is to create a transfer transaction for each address, generate 10 transactions in batches and issue them. If it is possible to write multiple transfer operations in a transaction like BTC, then the Gas consumption can be reduced.

Some Tokens implement the batchTransfer method for batch transfer in the contract, which takes an array and then starts the loop, initiating a transfer for each address in the array. BatchTransfer is not the standard of ERC20 token. Based on the principle of simpler and safer, a security audit of the code is necessary when implementing this function in the Token contract. Let’s take a look at the implementation of batchTransfer in the BEC contract:

The logic is reasonable. Unfortunately, the BEC development team has an extremely serious bug here: After the operation, there is no overflow judgment on the outcome, resulting in a serious risk which the attacker can use it to generate tokens freely.

In addition, there are other ways to implement batch transfer at the contract level.
First of all, ETH is unable to directly call a contract or call multiple contracts at the same time in a transaction, but the function in the contract can call other contracts externally. We can implement this bulk transfer logic through a smart contract. Through the method of multiple external calls within the Token contract, the goal is reached. The principle is as follows:
Address B is a token contract that supports the ERC20 standard. It provides a “transfer” method. We can deploy an intermediate contract to implement the logic of the batch call. The “batchTranfer” in the intermediate contract receives the contract address of the ERC20 token. An array of currency recipient addresses, is opposed to an array of token transfer quantities. For each recipient in the acceptor array, the “transfer” function on the Token contract (address B) is called externally, and the implementation code is: “_token.call(bytes4(keccak256(“transfer(address,uint256)”) , receivers[index], amounts[index])”. Here is the utilization of “call”, which is a very basic method in solidity. If it is used improperly, there will be security risks. It is important to learn more about “call”!

Note that when the “transfer” of the Token contract (address B) is called outside the intermediate contract (address A), due to the nature of the “call”, message sender will change from the original address C to address A, which is actually issued from the address A; to issue Token from address A, we must first transfer enough Token to address A. In order to secure the Token on the intermediate contract (address A), the contract must be assigned to an owner. There must be logic in the “batchTransfer” to check whether the address C caller is consistent with the owner. It must ensure that the owner is address C; only the intermediate C can be called by address C, and the transaction fee for the entire transaction is deducted from address C.

Implementation needs to specifically consider security and performance issues, such as whether the_receivers array and _amounts array length is equal, whether the loop “call” call should be rolled back after the entire batch transaction, and to avoid the length of the incoming array is too large, etc. .

Let’s take a look at the actual effect of the program:

The following figure shows the consumption of the transfer method in the Token contract from an address:

The intermediate transfer of BatchTransfer Caller is used to call the transfer of the Token contract. Here we only pass one recipient to the parameter array:

There are more intermediate operations and the parameter structure is more complicated. When the length of the incoming array is 1, this will increase the consumption of the Gas than the transfer that directly calls the Token. Look at the situation when you put 10 recipients into the array:

At this point, compared to the consumption of the transfer method that directly calls Token 10 times, the batch transfer through BatchTransfer Caller contract saves about 30% of the total Gas consumption, which is very impressive.

- 05 -

Summary

In the case of network congestions in ETH, if we want to initiate batch transactions, we need to consider security problems, find a balance between transaction approval time and gas price, and ensure the transactions approval speed and reduce fees consumption through some dynamic adjustment mechanisms and external utilizations of contracts.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Hashgard Official Social Platform

Telegram Group: https://t.me/hashgardeng

Reddit: https://www.reddit.com/r/Hashgard/

Telegram Announcements: https://t.me/hashgardengchannel

Medium: https://medium.com/@hashgard

Twitter: https://twitter.com/Hashgard1

Linkedin: https://www.linkedin.com/company/hashgard/

Our other Telegram Chats:

China Telegram Group: https://t.me/hashgard

China Telegram Announcement: https://t.me/hashgardchannel

Vietnam Telegram: https://t.me/hashgardvietnam