Comparisons and Reflections

We looked at a few other implementations of decentralized RPS for comparison. First, we looked at a demo made for Raiden (which is awesome, more about it can be found here). There are a few key differences between Peter’s “secret RPS” implementation and the Raiden rock-paper-scissors demo.

In Raiden,

Players pick a “player”, and then they pick a move. (for example, Darth Vader + Scissors). These are essentially “votes” for a particular move. The hashed selection is sent along with a payment (using Raiden) to a “game guardian”. A timer (drawn from the game server) is used to determine when the game ends. When the game ends, the unencrypted data is submitted by the game guardian to the game server, where the winner is calculated and result is returned to the game guardian. The game guardian instructs the Raiden nodes to distribute funds accordingly.

These choices are intended to showcase Raiden’s payment channels — hence the “voting” on an avatar and a choice rather than picking individual moves in a 1v1 game. However, in production this may leave such an approach open to sybil and whale manipulation. Peter’s implementation allows any player to start or join a specific game, rather than one all-encompassing game.

RPS could also be implemented in a straightforward smart contract on Ethereum, where the flow would be:

Players pick their moves, hash the move data and submit it to the contract. After play is concluded, players reveal their hashed data

This design pattern, known as “commit-reveal”, is also used in voting to prevent vote-memeing. Unfortunately, it really slows down the pace of play. See this cool example from 2+ years ago, which demonstrates some of the intricacies and drawbacks of such periodization, as well as this more recent effort. Both of these saw limited usage due to usability — note in particular the 24 hr waiting period in the more recent example.

Two things come up from these examples: timing and winner calculation.

Timing

In single-round play, we think Secret RPS has a distinct UX advantage over these other two implementations.

However, it would be awesome to enable best of 3 or best of 5 round-based play, letting users develop more complex strategies. Without the ability to tell time inside the secret contract (which our initial release lacks), this leaves Peter’s implementation open to the dropped-player problem across multiple rounds.

For example, say Alice and Bob are playing. Alice wins the first round, and Bob suddenly has his laptop with his private keys stolen. There’s no way for the game to “time out” and for Alice to retrieve her funds (or Bob for that matter. Sorry to do this to you Bob!). This is something we hope to address soon as it appears in multiple use-cases, especially for gaming. In a single-round (which is what the code is for right now), you can always play yourself to get the funds back if no counterparty accepts your game. This UX isn’t ideal, but adding a start time to the game struct, and then check for elapsed time in the withdraw() function would be straightforward to implement.

Winner Calculation

In Secret RPS, the winner is calculated within the Enigma Node immediately when both players have made their respective moves. Users can withdraw their funds anytime after this occurs with the withdraw() function. This is in contrast to the “game guardian” in the Raiden example, where a server external to the network performs the computation and returns instruction to the Raiden nodes. For gaming implementations, this design may present both regulatory risk and other liabilities.

Wrapping it up

Usability is incredibly important, and we’re really beginning to come to terms with that as a community. Looking at emerging projects like Veil, the proliferation of decentralized exchange relayers, 3box, and other usability layers, it’s clear that this has been a blind spot in dApp development so far. What is really interesting to us here at Enigma is to what degree data privacy and scalability solutions can enable usability gains — and how Enigma specifically can contribute.

We’re looking forward to building on what we’ve learned here from Peter’s implementation, and we’re also looking forward to moving this demo forward into production as we approach mainnet. We’re also excited about what other kinds of dApps can be built using similar mechanisms: poker, dice, on-chain CryptoKitty battles…

So, if:

You have ideas for how we can improve this implementation technically or edge-case questions

You’re a designer / front-end developer and want to work with us to improve these aspects

You have corrections to my interpretation of how these other implementations work

You want to build on these ideas to create even more games (Poker? Lottery?)

Please, get in touch! You can also post your thoughts on the Enigma Developers Forum.