What We Learned from Fomo3D — Part 2

Published in

quantstamp

5 min readDec 19, 2018

Last time, in What We Learned from Fomo3D — Part 1, we were introduced to Fomo3D and talked about how its attempt at random number generation could be exploited.

In order to incentivize players to purchase keys, the Fomo3D smart contract would transfer Ether into a pool dedicated to airdrops then “randomly” assess whether the purchaser was eligible for an airdrop from this pool. Since Ethereum is inherently deterministic, the numbers generated were not truly random, and could be predicted by attackers. In an attempt to resolve the lack of randomness inevitably present in Ethereum, Fomo3D developers prohibited calls by external smart contracts. However, this attempt was naive and exploitable.

Now, we get into the second lesson that Fomo3D taught us, which happened at the end of the first round. Despite the general assumption that the game would be won by a colluding mining pool, it never made it that far. The first round of Fomo3D was ended by a user with address 0xa169df5ed3363cfc4c92ac96c6c5f2a42fccbf85 performed a systematic attack that exploited the greedy behaviour of the Ethereum miners.

When a user submits an Ethereum transaction, the transaction gets broadcasted and becomes part of the so-called mempool of transactions. The miners then select transactions from the mempool and organize them into a block to be attached to the chain via proof of work. The key point to notice here is that the selection of which transactions will be placed in the next block is left at the discretion of the miners. As the behaviour of miners is greedy, transactions that are valuable, i.e., those that consume a lot of gas and whose sender specified the highest gas price, will get packed into blocks before other transactions do. Furthermore, the size of blocks in terms of the maximum amount of gas per block is limited (currently 8,000,000). Therefore, by submitting many transactions that nearly consume an entire block and that yield gas revenue for the miners exceeding the yield of other transactions on the network, the attacker was able to prevent other transactions from getting mined. The user purchased a key in block 6191896. The network blocking happened between blocks 6191898 and 6191906, which was sufficient for the time limit for the next key purchase to lapse. During the attack, the number of transactions per block decreasing from around 100 to less than 10.

The possibility of manipulating transactions was warned against many times before Fomo3D. However, it was always cited as a possibility from the side of the miners. For example, in the Ponzi scheme Governmental, the goal of an investor was to remain the last for at least 1 minute to win the jackpot. Since the timestamp of a block is determined by the miner who attached the block to the chain by the proof of work, and since there is some levy for the accuracy of timestamps in Ethereum, there is space for the miner to manipulate the timestamp and increase their own chance of winning. The Ethereum community was also warned against colluding miners that could actively exclude transactions of other participants from blocks, again trying to become winners on their own. However, the end of round 1 of Fomo3D is the first time when we saw an external user taking advantage of the greedy predictable algorithm for selecting transactions to be mined. Moreover, all they needed to make it happen was some Ether to cover the high gas cost. This is an important lesson for all applications that rely on security mechanisms that require users to submit transactions.

For example, the Ethereum scaling concept Plasma proposes the introduction of a hierarchy of chains. The top-level chain is called the “root chain’’ and governs the lower level chains that are called “plasma chains.’’ The task of plasma chains is to handle a large number of transactions that only once in a while get summarized and recorded on the root chain. From the implementation perspective, the state of each plasma chain is recorded in a smart contract on the root chain.

If users want to transact on a plasma chain, they need first to lock their funds inside of the smart contract on the root chain. Once they are done transacting on the plasma chain, they ask for a release of their funds and leave. Since the root chain smart contract that governs a plasma chain has no visibility of the individual transactions of the plasma chain, it chooses to trust the chain by accepting the summary transactions, unless a user can prove otherwise. This proof of fraud has to arrive within a certain time limit. If it does not, the governing smart contract is free to assume that the fraudulent summary transaction is based on true activity on the plasma chain. And this is the catch — if root chain network is under such a DoS attack, a user can have a very hard time submitting the proof of fraud. The only question is how long would one need to block the network for and whether the result is worth the cost of gas needed for conducting such an attack. Plasma, as well as all other systems whose functionality relies on the need to submit a transaction at some critical moment, have to be implemented with this attack in mind so that the cost of executing it vastly exceeds the benefit.

The story of Fomo3D is now over. The winner of the first round received 10,469 ETH. Given how the win was achieved, it should not be surprising that the second round was much less popular with the winner earning less than 800 ETH (however, 680 ETH was contributed to jumpstarting round 2 from round 1). The game is currently in much later round with the pool containing just a bit over 1.2 ETH. The trend of dying is obvious here. Nevertheless, Fomo3D will remain a chapter in the history of Ethereum. It made its dent, it attracted the attention of many people, and most importantly, it gave the world another lesson in blockchain security.

Next…

For more content like this, be sure to get on our mailing list and join our Telegram.

What We Learned from Fomo3D — Part 2

Next…

Other relevant reading

Written by Martin Derka