[Tech] Part 2 — Distributing Bounties and Airdrops (60K TX)
Introduction

The last post was about the preparation of Bounties and Airdrops. Since there were too many recipients of the campaign, we focused on reducing gas costs rather than reusable, versatile contracts. When the airdrop preparation was complete, we tested the airdrop distribution on the Ropsten Testnet.

by anonymous developer

Ropsten TestNet Airdrop

We wanted something that anyone can use to conduct their airdrop through this program. By clicking buttons from a client, “Server of node.js” will process the airdrop also showing the procedure to the client. When the result is out, the server will receive a receipt which was requested to be generate on the screen. So, we built a page for the client which automated the airdrop process when inserting the txIndex, Gas Limit, and Gas Price and clicking the button. We also added a function to indicate the process status and to pause the process.

There were a few issues with using web3 when signing and transmitting transactions from node.js.

1. Notation

We have to indicate each value in a hexadecimal value because the exponential notation is not recognizable.

ex) ‘0x’ + (1000000000).toString()

2. Private Key Format

When making a new transaction and sign there should be no 0x in the Private key value. If there is 0x in Private key’s value, there will be an underpriced gas error.

* When using Private key to create a public key, there should be 0x value. Web 3 did not have consistency which was problematic.

3. Timeout

After the completion of a transaction and receiving Receipt, we modify the record in the DB’s monitoring table. However, there are some cases that the same transaction is recorded in the DB twice. When logging is done, if node.js does not respond for 2 minutes, it sends a header asking the web browser to send the request again. If there is still no response for 2 minutes even after the request, Chrome considers it as a failure and FireFox continues requesting again and again. As it was a time-out problem, we modified the server’s time-out to 1200 seconds.

Aside from the client page that creates transactions, the operations team used a separate dashboard to monitor the distribution. For this reason, we had to keep the DB updated. These are a few issues when recording in the Database.

- Initially, we were hoping to record tokens in an integer number or a form of a floating decimal. However, we had to find alternatives since Ethereum has a large scale of numbers (Unit256). We considered dividing index and decimals and saving each in an integer (bigint) or string variable (varchar). We concluded to save the number in a form of a string variable and convert them separately because we thought it was a waste using two separate fields for variables which records the token amount.

- Node.js’s mysql module only accepts callback form. As a result, it was a total disaster that there were over 10 logics overlapping each other: checking the log to see if the code works fine, recording transaction transmission trial, processing airdrop, and recording the result of the transaction again. In order to optimize the process, we produced a function that wraps any kind of function with a ‘Promise.’

Ethereum Mainnet

We initially set the time-out as 1200 seconds (Testnet Issue #3) because we could not finish the airdrop distributions in time since it took forever when average transaction pending time exceeds 10 minutes. However, the price of gas fluctuation is significant. Even when we entered the same gas price, the transactions sometimes completed in seconds and sometimes completed in hours. Hence, we increased the time infinitely. (we made a code that automatically changes the gas price according to pending time, but we could not use it for a few other problems such as fork, nonce, and others).

Even though we fixed the time-out length as 1200 seconds for node.js, there was a problem that node.js died after 750 seconds when pending. There was no error message showing, so we traced the source and found that web3 was the problem. Web3 called it an error when there were no result for 15 seconds from each block and after 50 blocks pass. However, the beta41 error is not properly showing outputs, so we increased the pending time limit and continued the distribution.

It may have been due to the Constantinople hard fork as the distribution was right before it, the gas price was too high and fluctuating greater than usual when we were processing airdrop on the mainnet. The transactions suddenly became pending for several hours even though it was often completed in 30 seconds at the same price. As the delay was getting worse, there was a Connection Timeout in Mysql. We were able to solve the MySQL connection problem by disconnecting it before requesting the transaction, and when receiving the receipt, reconnecting it to operate the DB work.

As the pending time became longer, it would be necessary to reduce the pending time by replacing an existing transaction with a new transaction with higher gas prices. The problem was that when a number of transactions were pending when one transaction completes, the nonce of the remaining transactions in the pool increased by 1, and all the transactions were sequentially included in the block. We tried to find the reason, but we could not simulate it, so we avoided replacing transactions as much as possible.

We wanted to verify once more if the token distributed into the allocated wallets successfully after the completion of a transaction. We chose to check the balance of the wallet through balanceOf which is included in ERC20. However, as the airdrop period was extending, there were about 5000 token holders who transferred their tokens from their wallet. Moreover, we could not lock it because we were already listed on the exchange. Next time, we thought we could use getPastEvent or lock it if necessary.

Join REMIIT’s Community

Telegram: https://t.me/remiit

Website: https://remiit.io/

Twitter: https://twitter.com/remiitplatform
['Team Remiit']
['Blockchain Development', 'Cryptocurrency', 'Blockchain Technology', 'Blockchain', 'Airdrop']