Written by Markus Buhatem Koch
This is the second part of a blog post on extracting and analyzing data from the Ethereum blockchain. You can skip the Intro if you’ve read part 1
Intro
If you are reading this, you’ve probably heard of the game that has caught everyone’s attention on the Ethereum network over the last few months: CryptoKitties!
In short, the game consists of collecting virtual cats. Cats are created by the players of the game, who can breed two cats to generate a new one. Each cat has its own genetic sequence, which determines their physical attributes. Their genome is a function of their parents' genes plus some randomness. In addition to breeding, up to 50,000 cats with predefined characteristics can be created by Axiom Zen, the company behind the game. There is a market for buying and selling cats and another one for “renting” cats for breeding purposes. You can read more about the game here.
Block Science is a technology research and analytics firm specializing in the design and evaluation of decentralized economic systems. Analyzing aspects of the CryptoKitties economy seemed like a great opportunity to improve our data extraction tools while at the same time getting our hands on some real world data from a live (and lively!) decentralized application.
This blog post has been split in two parts:
- Part 1 covers technical aspects related to extracting and transforming data from the Ethereum blockchain.
- Part 2 (this post) contains actual analysis of some game data.
Analyzing the data
We began our analysis by creating a dataframe with all log entries recorded between blocks 4605167 and 5374870 by the three CryptoKitties smart contracts: the game’s core mechanics, the sale auction and the siring auction (where players “rent” their cats for others to breed with). From the counts (Chart 1), we come to two interesting findings:
- The Pregnant event occurs much more often than the AuctionSuccessful event of the siring auction smart contract. This should mean that most breeding is happening between cats belonging to the same player, because we know from the source code of the game that every successful siring auction results in a pregnancy; and
- The Transfer event is only 6% more frequent than the sum of events that cause it — from the source code, we know that every auction created or cancelled, every birth and every sale result in a transfer. This means that 6% of transfers are taking place through some other mechanism than the official smart contracts — such as players gifting kitties to friends. We should see this percentage increase once new games built on top of CryptoKitties become popular enough that players will start losing their cats in challenges, for example; or once decentralized exchanges with more advanced trading features come up that allow crypto-kitties to be listed on them.
The Economics of Giving Birth to Kitties
Seeing the existence of an economic component around the birth of new cats, we proceed to study this process in more detail. When two cats breed, a variable is set on the pregnant cat that says on what block the pregnancy will be completed. However, there is no inherent timer in the Ethereum network that allows a piece of code to be automatically executed in a certain block. This means that someone must call a function in the game smart contract that “gives birth” to the new cat. This is the purpose of the giveBirth function: when called, it checks if the pregnancy has reached its course. It is only when the giveBirth function is called that the genes of the offspring are determined by a closed-source algorithm. In order to reduce the chances of players gaming the system, the developers created an incentive mechanism for giveBirth to be called as soon as the pregnancy has been completed.
Because this giveBirth() function includes a random element, it is critical that it is called quickly after the expected birthing time (within 250 blocks, or about 30 minutes). If the call takes any longer, it provides the opportunity for bad actors to “re-roll” the random element of their genetic combination and gain an unfair advantage against other breeders. To keep this from happening, we allow anyone to call giveBirth() and we give the entire birthing fee to the first caller that successfully births the new kitten. (source)
The mention to a 250 blocks deadline implies that CryptoKitties uses the hash of the block previous to the expected birthing block as a source of entropy to determine the genes of new kittens. Block hashes are only available to the EVM for 256 blocks (~250). After that, calls to blockhash return zero. This means that if the incentive for external agents did not exist a player could simulate the birth of a new kitty and, if they did not like the result, wait 256 blocks and try again.
Update (Aug 19, 2018): the recent publication of the Erays paper leads us to believe that this economic incentive is even more important than we first thought. According to the paper, if the birth happens after the 256 blocks period, CryptoKitties does not use the 'zero' as a source of entropy, but rather the current block number. Meaning an attacker would not only get a second re-roll, but as many re-rolls as they wanted to, simply by simulating the birth of their new kitty at different blocks.
So the game collects a fee from every breeding (called birthing fee), and allows any Ethereum account to claim that fee simply by calling the giveBirth function on the pregnant cat at (or after) the right block. The new cat still goes to the owner of the pregnant cat. But anyone can give birth to a cat whose pregnancy period has ended and be compensated for it.
This has led to the emergence of “CryptoMidwives”, as Michael Zargham dubbed them: agents who, even if they are not themselves players of the game, fulfill a critical function in the CryptoKitties economy. The concept is not unique to CryptoKitties, and could be generalized to “CryptoServices” — a design pattern where the account that calls certain functions of a smart contract is rewarded for doing so.
// Send the balance fee to the person who made birth happen.
msg.sender.send(autoBirthFee);
The event log dataset shows us that most births are caused by only a few accounts. Early in the history of the game, accounts associated with AxiomZen were the only ones giving births to kitties. As time went by, other accounts began calling the giveBirth method. We can also see that only a few midwives account for most of the births: the orange area in Chart 2 represents the top 5 accounts in every 1000 blocks (a total of 151 accounts). Except for a spike around block 4.700.000, AxiomZen and the top callers account for the vast majority of births all the time.
The spikes in activity by AxiomZen seem to correlate well with moments of increase in the average gas price of Ethereum transactions. This was to be expected, since the increased costs of giving births makes it less attractive to external agents. As a response to the network congestion in December, AxiomZen increased the birthing fee from 0.002 ether to 0.015 ether for a few days, later lowering it to 0.008 ether, which held well during the January peak.
When we enrich the event log dataset with information from the transactions that generated them, we observe that in general the CryptoMidwives are not directly calling the giveBirth function in the game contract, but rather going through an intermediary smart contract. This allows them to make a single transaction to a closed-source smart contract, which in turn calls the giveBirth function as many times as it is instructed to. See transaction 0x6cc717fc… for an example.
With the data available in the blockchain, we can even look into these agents' revenue and profitability. Let’s focus on the top 10 CryptoMidwives of 2018. Account 0x05be6e… is the top ranking in number of births, clearly ahead of the competition. Account 0xa21037… (which belongs to AxiomZen) comes in eighth place, which is good, because they should only have to act as a last resort.
Since December 11, the reward for a successful birth has been 0.008 ETH. With that information, we can calculate the revenue of each of the top 10 CryptoMidwives.
However, giving birth to crypto kitties costs fees. Besides, competition in this market is fierce! Many attempts to call giveBirth “arrive late” — meaning that when the transaction is processed by the miners the cat is no longer pregnant because another transaction was processed first. Those late arrivals don’t take as much gas, but might still cost a significant amount in fees. Subtracting all those fees from the rewards, we come to the profits of each midwife. Interestingly, account 0x80cfd2…, which is sixth in revenue, stands out in this performance indicator. Clearly they must have found some way to save in fees, whether through smart contract design, better timing of their transaction broadcast, better choice of gas price, or a combination of these.
In order to investigate the smart contract design hypothesis, we have created a metric we call “code efficiency”. This is a simple ratio of kitties delivered per gas used. If we look at the normalized values of average code efficiency for the smart contracts used by the top midwives os 2018 (chart 7), we see there’s very little difference between them.
If instead of defining efficiency in terms of gas used we define it in terms of profit (profit per kitty delivered), we see that account 0x80cfd2 is a lot less efficient than account 0x05be6e (Chart 8). Assuming similar code efficiency, this would mean that 0x80cfd2 is paying higher gas prices for their transactions that successfully give births to kitties.
The higher gas prices could explain the higher profitability of account 0x80cfd2 — it might result in them winning every race to giveBirth they compete in. And indeed, every transaction from account 0x80cfd2 has resulted in one or more kitties being born. The same cannot be said about 0x05be6e, which has a large number of transactions to their smart contracts that don’t give birth to any kitties.
However, fees incurred by account 0x05be6e that result in no births are not only caused by transactions that lose the gas price war. It seems their main smart contract, 0x39243a, requires some sort of periodic interaction that is very expensive in terms of gas. See for example transaction 0xcc0f970e. If it weren’t for that kind of transaction, 0x05be6e would not only lead the revenue ranking, but also the profitability one.
Update (May 25, 2018): further analysis indicates that transactions like 0xcc0f970e are what enable the midwife smart contract to save on gas on the transactions that give birth to kitties, using "storage refunds" — the same technique behind GasToken. I have to thank Ricardo for helping me figure this out. The contract used by account 0x80cfd2 also seems to take advantage of those refunds, but using a different account to save data to storage (0x3a91b4…). A more accurate profitability analysis would have to take into consideration clusters of accounts and smart contracts belonging to a single agent.
You can find the source code for these analyses on a Jupyter Notebook in our GitHub.
Conclusion
The economic incentive created to make sure cats are born as soon as possible seems to be working. The concentration of Birth events in few accounts indicates that bots have been created to give birth to cats as soon as possible. But it seems likely that once there are no further efficiencies to gain from smarter midwife contracts, the bots will have to wage a gas price war in order to stay competitive. Which means that ultimately a large portion of the birthing fees will probably end up in the hands of miners.
In any case, the birthing fee makes CryptoKitties more expensive to be played than if this mechanism wasn’t necessary. As the first game of its kind to gain significant traction on the Ethereum network, CryptoKitties will certainly continue to inspire many developers for quite some time. It will be interesting to see how new games deal with this sort of challenge in the future.
Future Work
As is the case with many analyses, this one leads to more questions. Leave yours and your feedback in the comments! We’ll continue to look into this dataset in future articles.
Special thanks to the Block Science team for research, insights and review.
About BlockScience
BlockScience® is a complex systems engineering, R&D, and analytics firm. Our goal is to combine academic-grade research with advanced mathematical and computational engineering to design safe and resilient socio-technical systems. We provide engineering, design, and analytics services to a wide range of clients, including for-profit, non-profit, academic, and government organizations, and contribute to open-source research and software development.
