Developing Multi-Blockchain web-dApps Using Reach: “serious” Rock Paper Scissors
Reach! I discovered Reach after Reach-ing out to CTO Jay McCarthy, once my professor at Vassar, with a blockchain whitepaper centered around a programming language visually similar to Racket (a language to which he contributes). He told me he had begun developing a new blockchain programming language that could automatically compile verified code to multiple blockchains. The concept was already incredible. I had full confidence that Jay’s experience in formal verification and compilers (coupled with his generally insightful approach to computing) meant this platform would be a game-changer.
The Reach Bounty Hack was the push I needed to dive into Reach and complete a project; a “serious” version of Rock Paper Scissors (as presented in the Reach tutorial). In this version, moves are submitted in batches to reduce the likely number of transactions, and transaction costs are split as fairly as possible between participants. My further goal (which I had begun in advance of the Bounty Hack) was to develop Reach RPS into a full-fledged web app with search functionality and a games database.
For my project architecture, I chose to use Vue for my front-end and Amazon Web Services for storing and searching game metadata. Of course, I’d write smart contracts in Reach and interface with the compiled .mjs smart contracts using Reach’s JavaScript standard library.
I came into this project with many questions. I had never programmed on any blockchain before, nor had I used AWS. Though I had some Vue experience, this project required careful state management and navigation, and I chose to learn Vuex Store and Vue Router. Mapping out the project’s data flow felt daunting. How would I coordinate blockchain state, front-end state, the user interface and the database of games?
The problem became much simpler once I realized Reach would entirely and automatically provide contract state. So long as I programmed the contract to communicate any state information I needed using Participant Interact Interface functions, once I attach the client to the smart contract, Reach automatically calls these front-end functions with the specified contract state information. From these hooks, I could update the UI and database as needed. Therefore, my job in the front-end was to allow players to attach to backends, communicate contract state (to both the player and database), and provide user input to the backend (both the game parameters and the moves).
Cryptocurrency wallet management was simple to set up. Reach’s standard library currently provides an interface for Ethereum and, just before the Bounty Hack, added one for Algorand. To prompt access to accounts listed in MetaMask (a browser extension to manage ETH wallets), all I had to do was call the stdlib.getDefaultAccount() function. Because of the recency of Algorand support, as well as the relatively new and ongoing development of Algorand wallet protocols, there were some kinks to work out. Algorand’s live networks are approaching feature parity with TEAL 3, which Reach’s ALGO smart contracts depend on, so I needed to run and connect to Reach’s custom Algorand development network. [Since this article was written, Algorand Mainnet adopted TEAL 3 and Reach is nearing release for Algorand Mainnet support] Once I learned how to use Vue CLI to set up a development server and proxy transaction requests to the development network (and undo some of my own Dockerish mischief) Algorand contracts ran seamlessly. (Sidenote: since writing this article, the development team has already eliminated the need for a proxy server when developing on Algorand.) It was, all in all, a straightforward process amply helped by Dan and Jay from Reach as well as Krysztof (a Reach Sherpa) on the Reach Discord server).
As I developed my architecture, I began to modify the smart contract program for Rock Paper Scissors. Reach challenged me in that it is incredibly well-formed in type, grammar, function, and general structure. This is one of its benefits. The Reach compiler automatically formally verifies programs and preserves abstraction such that it may cleanly accomplish blockchain multiplicity. As a programmer recently immersed in web development and used to my own slippery style of JavaScript, I had to carefully pour through Reach’s precisely-written documentation, debug piece by piece, and often ask Jay for clarification (which he willingly and thoroughly provided). The compiler gives specific, helpful error messages to guide you along the way. Once there are no errors, watching the compiler generates and proves 700 theorems about your program is extremely satisfying. Afterwards, I had two fully-functional smart contracts in Solidity and TEAL to plug into my web app. When the individual pieces were ready, the remaining processes worked simply.
If you’d like to try, you can play the live version here: https://nicholasburka.github.io/rps-gui/dist/index.html
I’d start with a testnet or localnet before wagering any hard-earned ETH, so you learn the game flow of dRPS. Note that contracts cannot be rejoined after the page is closed — the game must be completed in one session. The Reach team plans to support contract re-attachment in the coming months.
If I spent more time on this project (and I might) I would want to work on:
- Pending contract re-attachment; hyper-robust web dev error handling for contract/db synchronization. With another day I would have built a resubmit function for cases in which a contract is created but the database is inaccessible (i.e. derelict contract handling).
- Cryptocurrency-level network specification: identify & communicate whether someone’s wallet is running on Ganache, Mainnet, etc, and store/fetch games accordingly.
- Take a maker’s fee from contracts.
- Wallet address aliasing, friends lists, and invite functionality.
- Local storage.
- Simple AI; functions with Reach programs which, through a simple algorithm or decision tree, can play games as a stand-in for human players.
- Other variants of the game!
