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

For the JavaScript developers out there, learning the basics of Solidity and Ethereum smart contracts is about as hard as learning React Native – it’s not difficult to find high-level tutorials and code samples, and there’s no shortage of Medium How-Tos ranging widely in usefulness and legibility. In contrast to React or Angular, however, it sometimes is difficult to find the Stack Overflow or Github post with the approach or code snippet you’re looking for.

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 features, 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 a 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.

I made ample use of the test functionality built into Truffle, and the option of writing JavaScript tests to validate my Solidity code eased the development transition. But it also -- fortunately and unfortunately -- led me to discover an issue with my code that I wasn’t sure I knew how to fix – an issue that I worried made my project unfeasible on the network.

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.

But then I started to wonder why I had to sort the scores on-chain at all. The player entries and scores were both submitted and validated publicly on the blockchain, so the sorting could easily be vetted. Why not let JavaScript do the hard work off chain?

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.

Wrapping Up

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.