Fantasy turns real: A developer’s journey to building his first dApp shows the perils and promise of developing on Ethereum
Michael J. Cohen is a front-end developer in New York City and spent the summer building his first distributed app, or dApp as they are commonly known. His project was a weekly fantasy football game called Blockgame. He tells his story here.
On a Friday in May, during a casual conversation about crypto markets, a friend confidently suggested I consider investing in Maker, an Ethereum token that backs a stablecoin called dai. Having followed crypto markets and the blockchain from a distance, I hadn’t really taken the time to understand the technology and its potential applications. So, I did some research. First, I tried to understand the problem Maker is trying to solve. Second, I wanted to wrap my head around the highly technical solution. In truth, the collateralized debt and distributed governance features were a bit much to handle for a first dive into crypto, and I failed miserably. Still, I invested $150.
While my initial pass trying to understand blockchain tech was underwhelming, it made me realized I should have started at the base protocol layer. Mastering Maker without first grasping its Ethereum backbone didn’t make all that much sense. So, I got to work.
Learning How to Write Smart Contracts
But it’s very doable. I started my education with CryptoZombies, an entertaining and well-designed introduction to dApp development. I finished the six lessons with a solid grasp on the syntax, inheritance feature,s and interoperability of smart contracts, but still feeling like I was missing a few elements of the dApp developer toolkit.
After working through a 24-part YouTube series and writing “Hello, World” to the testnet at least four times, I started to feel more comfortable with my smart contract skills. It was time to try it myself.
Picking a Project
It’s really difficult to learn a new language or library without applying it in a substantive way. It’s not an original observation, but it’s true. So, I started to look for a straightforward but stimulating project to hone my skills.
Having begun to recognize the strengths and capabilities of the blockchain, sports betting seemed like a compelling application (1) there are discrete outcomes easily modeled by a smart contract and (2) crypto allows for a low friction and portable currency (once you have it, of course).
Apparently, I wasn’t the first to notice that gambling is a natural use case for Ethereum. At time of writing, the top two non-exchange dApps by ether volume are dice games (source: dappradar.com). The following three are pyramid-scheme-like “investment” games. Several of other top dApps are crypto-collectible games, which aren’t explicitly games of chance, but which are at least speculative in nature. I thought I should maybe try something different.
My second thought was to build a multimedia chat board for dApp developers. After some research, I started to think that the idea was a little too ambitious for a first project. It also didn’t strike me as practical application of the Ethereum network. It was the sort of app where the blockchain was in many ways an inferior solution compared to a conventional backend.
Crafting a game on a smart contract
So, I wanted something — at least somewhat original — that leveraged the benefits of the blockchain, but wasn’t too elaborate. And, on top of that, something that wasn’t too computationally expensive. With the football season a few months away, I thought some sort of fantasy football game would be a good fit. There could be an entry fee and prizes for the top finishers, but it would require strategy and skill, instead of pure chance. (Editor’s note: That distinction makes fantasy games typically legal, even with an entry fees. Games of chance that charge entry fees are generally illegal lotteries under U.S. law.) The user interaction with the smart contract would be fairly straightforward to understand and implement. Finally, the beginning of the football season gave me a hard deadline to work against, adding some extra motivation to finish my dApp.
The game goes like this. A player gets $150 to spend on six NFL teams in a given week. The teams are priced by strength of offense ( + ) and strength of the opponent’s defense ( – ). After all the teams have played, the entries are tabulated and sorted according to which selection of teams had the highest aggregate point total — offense, defense and special teams.
I got a first pass on a smart contract done within about a month, working an hour or so a few nights per week a bit on weekends. A solid portion of that time was spent getting acclimated to Truffle (the most widely used dApp development framework). Even compared to the JS ecosystem, it seemed like the standard suite of Ethereum dev tools has evolved rapidly over the last few years. More than a few times, Google pointed me toward a Github post or comment from 2016 that had already become largely obsolete. My guess is that some of the confusion stemmed from way Truffle — to their credit — has tucked popular libraries into the framework and integrated them with one another, making old instructions more difficult to follow.
Thinking Like a dApp Developer
To wrap up each week’s contest, I had written a smart-contract method to iterate through an array of entries, calculating each score based on the week’s NFL results and then sorting the players from best to worst. From a non-blockchain standpoint, there are efficient and inefficient approaches to this problem and while there are well-established best practices, there are many effective options. When I tested this function in my smart contract, however, Truffle threw an “out of gas” error exception and the contract failed to return the top players. It didn’t know who had won!
Without getting into the complexities of Ethereum, “gas” is a measure of the computational load and a key input in the ether cost of a function. For the network to run, there are constraints on how much gas a function can “cost” if it wants to be validated by the network. The gas requirement exceeding a certain threshold was the reason my method wasn’t running. Looking back on it, I realize that optimizing for gas was the key mindset adjustment I needed on the path to building my first dApp.
So, calculating and sorting the results was too expensive. My first solution was to limit the sorted top players array to 15 — that way the contract would only need to sort a score if it was greater than the 15th place entry at that moment in the sorting process. This helped. My tests passed! But only when there were fewer than ~15 entrants. Any more contestants and I hit the same out of gas exception, so this wasn’t a viable solution.
Next, I broke up the sorting function into A and B parts. In Function A, the contract ran through the first 15 entries where a disproportionate amount of gas was being used (each of the first 15 entries were naturally among the Top 15). Function B sorted the remainder. When I ran this approach through testing, it worked up until about 150 entries — 10 times better, but there were still problems. It was sloppy and still not sufficiently scalable. It would also have cost $4-$5 in ether (at $200-$250 USD to 1 ether) to validate each function on the network. This wasn’t the right solution either.
I was getting a little discouraged. Something that was so basic off-chain was proving so difficult on-chain. Programming with a different set of constraints required a different set of tools.
So I wrote one contract method to return the array of entries and another to register the top players and scores. Then I built an admin section in my dApp to receive, sort, and submit the top results. This solution worked! — 15, 150, 1,500 entries or more. A scaleable method was achieved at last by looking at the problem from a different angle.
After reading some more about expensive functions, I started to realize that moving work off chain is actually quite a common approach. dApp development is deep in compromise and weighing on/off-chain tradeoffs seems to be a critical element of modeling a solution to any problem.
It took a little bit of work to hook my contract up to a React front end, but I was starting to feel more comfortable as a dApp developer. After making a few tweaks to the contract and deploying it to the testnet, I finished the front-end just in time for football season.
There are still a number of opportunities for improvement — high transaction costs and manual data entry topping the list — but Blockgame works and I’m looking forward to continuing my dApp education.
Check out Michael Cohen’s dApp at www.blockgame.cash. You can find him on LinkedIn here.
The post Fantasy turns real: A developer’s journey to building his first dApp shows the perils and promise of developing on Ethereum appeared first on The Block.
Fantasy turns real: A developer’s journey to building his first dApp shows the perils and promise of developing on Ethereum written by Contributor Network @ https://www.theblockcrypto.com/2018/11/02/fantasy-turns-real-a-developers-journey-to-building-his-first-dapp-shows-the-perils-and-promise-of-developing-on-ethereum/ November 2, 2018 Contributor Network