This article was first published on quantstamp - Medium
What We Learned from Fomo3D — Part 2
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 ...
To keep reading, please go to the original article at:
quantstamp - Medium