Handling disappearing transaction in Ethereum
In LikeCoin, we want to introduce a friendly and fun on-board experience, thus we have introduced a bonus system in like.co. Users are rewarded with LikeCoin for completing various missions, e.g. watching the LikeCoin introduction video, joining one of our communities.
Running a system like this involves sending many small transactions through the Ethereum network. To keep the cost low, we have to achieve the following goals:
1. Merge those transactions with the same “to-address” into single batches
2. Send them with a low gas price, since speed is not an important factor here
3. Notify the users when they receive the LikeCoin (after the transaction is completed on the network)
Things went smoothly when we were on test net. However once we get onto main net, things were different: many of our transactions sent were disappearing and (sometimes) reappearing mysteriously.
It turns out that when the current gas price is too high, transactions with low gas price will get stuck in txpool, since no miner is willing to process it just yet. Gas price in the Ethereum network fluctuates a lot, it gets very high when there is a big ICO launch; but could also be quite low when everyone is sleeping.
Theoretically, after the gas price fall back, the sent transactions will automatically be mined, without any extra work. In Practice however, low gas transactions tend to got dropped out of txpool due to memory limit. It is very possible that our transaction was already dropped after a long time. Therefore we need to remind the network to handle our transactions after the gas price drops.
Pray, then try again later
To solve the problem and achieve our goals, we have created two microservices. Both solution is based on Firebase Firestore as data storage, and is open sourced on Github.
Prayer is in charge of batching transactions in a time interval, and sending them to Ethereum network through Infura. The name
prayer comes from the fact that we are passively hoping for miners’ to do the work, and
likecoin-payer doesn’t sounds like a good name after all.
Tx-poll has two functions that is configurable when deploy. First it can act as an Ethereum transaction status tracker, which updates transaction states when it fails or completes. We then send notifications to our users accordingly.
On the other hand, it also support retrying a transaction, when it is not found in the Ethereum network. By retrying only the first few transactions in a relatively long interval, we can do this without heavily increasing INFURA’s workload. Actually it is pointless to retry too frequently: since Ethereum account nonce works in a strictly increasing way, every transactions in the same account will always be blocked by the earliest un-processed transaction.
Automated retrying transaction seems to be a generic useful case, especially for sending non-time-critical transactions with low cost. We are looking into expanding these microservices to not only support Firestore, but different kinds of database/storage backend, so it can fit in more scenarios.
Next episode (probably)
Now that we have mentioned nonce, it is in fact quite a trouble to tackle with, kik engineer wrote an related article on this topic before.
In LikeCoin, we have a mechanism to work around (or rather,
work with) this restriction. We will be writing another article soon, sharing our solutions. Stay tuned!
Give me some LIKEs if you like this article!
LikeCoin @ Hong Kong Open Source Conference 2018
LikeCoin will hold two sessions in HKOS2018 (Hong Kong Open Source Conference 2018). Come and join us!
Event name: LikeCoin @ Hong Kong Open Source Conference 2018
Location: Hong Kong Science Park Conference Hall 6
Time: 16/6 1400–1510
14:00–14:30 Blockchain for creative contents: What we do in LikeCoin
14:40–15:10 Dapp: a new approach to combine blockchain and cryptography into web application
You may join both sessions or join one which you are interested in. Tickets: