The Conflux bounty hack (also known as the Gateway to Blockchain bounty hack) was a joint operation between the Conflux team and the Reach team to showcase the variety of dapps that can easily be built using the Reach language and run on the Conflux blockchain. The competition ran from July 5th to August 20th with participants spending five of the weeks therein creating a dapp chosen from a list of possible projects; these projects ranged from basic DAOs to games recreated on the blockchain.
My Background
This is the second Reach-affiliated bounty hack I’ve participated in, the other one, The Algorand/Genesis bounty hack (in which I built a basic auction), was back in February. Alas, despite having that history with the language, this was only the second contract/dapp I’ve written in Reach; however, having that gap of a few months between writing Reach contracts has given me a clear view of how much the language has improved in just the last few months.
The Improvements
Since I last used it, the team has added a great deal of depth to the error messages you might run into while coding a reach application; these come in the form of links to pages, in the error messages, that give a bit of context about the error and, if it’s a common enough situation, a potential fix that in both cases where I saw it told me exactly how to fix the error. In addition to this, there have been a variety of syntax improvements that improve code readability and a whole slew of new features (being able to use real-time instead of block time, being able to call external contracts, and more).
The Project
I showed up about a week late for the competition so I got the pick of the leftover projects; however, one of those leftovers was Mancala, and considering this game is tied to playing, and losing, so many matches with my siblings when I was a kid I had to pick up the project. Mancala is technically a family of games, with Kalah being the variant most popular in the west, (and the one I’m most familiar with) it is composed of a board like the one below, with each circular inlet representing a house, the pebbles representing seeds, and the oblong inlets representing a storehouse.
The game is run in accordance wit six rules (courtesy of Wikipedia):
- At the beginning of the game, four seeds are placed in each house. This is the traditional method.
- Each player controls the six houses (one row) and their seeds on the player’s side of the board. The player’s score is the number of seeds in the store to their right.
- Players take turns sowing their seeds. On a turn, the player removes all seeds from one of the houses under their control. Moving counter-clockwise, the player drops one seed in each house in turn, including the player’s own store but not their opponent’s.
- If the last sown seed lands in an empty house owned by the player, and the opposite house contains seeds, both the last seed and the opposite seeds are captured and placed into the player’s store.
- If the last sown seed lands in the player’s store, the player gets an additional move. There is no limit on the number of moves a player can make in their turn.
- When one player no longer has any seeds in any of their houses, the game ends. The other player moves all remaining seeds to their store, and the player with the most seeds in their store wins.
How it went
This game seemed fairly simple to me, but I quickly ran into several interesting quandaries. In addition to this being only the second Reach contract I’ve written, it’s also only the second time I’ve dealt with an immutable language; learning how to go from thinking in mutable code to thinking in immutable code, while frustrating, introduced me to some interesting concepts.
Reach also has a very interesting feature called the verification engine. This runs your program through a series of checks to verify whole categories of errors are impossible. Want to lock away some CFX in a contract? You can’t with Reach, as the verification engine will throw an error and prevent the code from compiling. However, this verification engine can be very frustrating to work with if you don’t know what you are doing; especially if you extend the verification engine to also check all arithmetic (which is what I did).
Regardless of those difficulties, and with a lot (and I mean a lot) of help from the team through the Reach Discord, I was able to complete the project with just hours to spare. The late start and working full time did not give me as much time to spend on this project as I would have liked; also, if you check the project’s README, you can see that there was a whole laundry list of stretch goals that I had in mind that I sadly did not have time to work on.
I want to go into more detail about the challenges I ran into, how I got past them, and what I learned from them, but those stories will have to go in future Medium posts. For now, I need to finish this article.
Going Forward
The project isn’t going to end here. While it might be done, it isn’t polished to a degree that I’m okay with; I still have a lot of questions to ask the Reach team about optimizing contracts, different approaches to programming with Reach, and how to implement things like timers for player turns in the contract. I also want to have this dapp hosted on Conflux mainnet once I’ve polished it enough, so expect that to happen at a later date.
If you’ve been thinking about getting into dapp development, then I highly recommend Reach as your first foray. If a frontend developer who barely worked with smart contracts, immutable languages, or the Reach contract language outside of these past two competitions can build an Auction and the game of Mancala as their first applications, then just think of what you can build!