2.3 Rock, Paper, and Scissors

In this section, we’ll have Alice and Bob actually execute the game of Rock, Paper, Scissors!.

We have to decide how to represent the hands of the game. A simple way is to represent them as the numbers 0, 1, and 2, standing for Rock, Paper, and Scissors. However, Reach only supports unsigned integers of 256 bits, so it is better to represent them as the equivalence class of integers modulo three, so we won’t distinguish between 0 and 3 as Rock.

We’ll use a similar strategy for representing the three outcomes of the game: B wins, Draw, and A wins.

The first step is to change the Reach program to specify that Alice and Bob’s frontends can be interacted with to get the move that they will play, and later informed of the outcome of the game.

 1    'reach 0.1';
 2    
 3    const Player =
 4          { getHand: Fun([], UInt256),
 5            seeOutcome: Fun([UInt256], Null) };
 6    
 7    export const main =
 8      Reach.App(
 9        {},
10        [['Alice', Player], ['Bob', Player]],
11        (A, B) => {
..          // ...
26          exit(); });

• Lines 3 through 5 defines a participant interact interface that will be shared between the two players. In this case, it provides two methods: getHand, which returns a number; and seeOutcome, which receives a number.

• Line 10 uses this interface for both participants. Because of this line, interact in the rest of the program will be bound to an object with methods corresponding to the these actions, which will connect to the frontend of the corresponding participant.

Before continuing with the Reach application, let’s move over to the JavaScript interface and implement these methods in our frontend.

..    // ...
13    const HAND = ['Rock', 'Paper', 'Scissors'];
14    const OUTCOME = ['Bob wins', 'Draw', 'Alice wins'];
15    const Player = (Who) => ({
16      getHand: () => { const hand = Math.floor(Math.random()*3);
17                       console.log(`${Who} played ${HAND[hand]}`);
18                       return hand; },
19      seeOutcome: (outcome) =>
20      console.log(`${Who} saw outcome ${OUTCOME[outcome]}`) });
21    
22    await Promise.all([
23      backend.Alice(
24        stdlib, ctcAlice,
25        Player('Alice')),
26      backend.Bob(
27        stdlib, ctcBob,
28        Player('Bob'))
29    ]);
..    // ...

• Lines 13 and 14 define arrays to hold the meaning of the hands and outcomes.

• Line 15 defines a constructor for the Player implementation.

• Lines 16 through 18 define the getHand method.

• Lines 19 and 20 define the seeOutcome method.

• Finally, lines 25 and 28 instantiate the implementation once for Alice and once for Bob. These are the actual objects that will be bound to interact in the Reach program.

There should be nothing interesting or controversial about these implementations; that’s the point of Reach: we get to just write normal business logic without worrying about the details of the consensus network and decentralized application.

Let’s return to the Reach program and look inside of the body of the program for what actions Alice and Bob take.

In a real-life game of Rock, Paper, Scissors!, Alice and Bob simultaneously decide what hand they will play and reveal it at the same time. "Simultaneity" is a complex concept that is hard to realize in practice. For example, if you’ve ever player against a little kid, you may notice them trying to see what you’re going to choose and delaying until the last minute to show their hand so they will win. In a decentralized application, it is not possible to have simultaneity. Instead, we have to select a particular participant who will "go first". In this case, we’ll choose Alice.

Does Alice go first, or do we call the player that goes first "Alice"? This might seem like an unnecessary distinction to make, but it is a very subtle point about the way that Reach works. In our frontend, we explicitly ran backend.Alice and backend.Bob. When we did that, we were committing that particular JavaScript thread to be either Alice or Bob. In our game, whoever chose to run the Alice backend is the one that will go first. In other words, Alice goes first. This will be more obvious at the end of the tutorial when we’ll make the choice interactively about which role to play.

The game proceeds in three steps.

First, Alice’s backend interacts with her frontend, gets her hand, and publishes it.

..    // ...
12    A.only(() => {
13      const handA = declassify(interact.getHand()); });
14    A.publish(handA);
15    commit();
..    // ...

• Line 12 states that this block of code is something that only A (i.e., Alice) performs.

• That means that the variable, handA, bound on line 13 is known only to Alice.

• Line 13 binds that value to the result of interacting with Alice through the getHand method, which we wrote in JavaScript.

• Line 13 also declassifies the value, because in Reach, all information from frontends is secret until it is explicitly made public.

• Line 14 has Alice join the application by publishing the value to the consensus network, so it can be used to evaluate the outcome of the game. Once this happens, the code is in a "consensus step" where all participants act together.

• Line 15 commits the state of the consensus network and returns to "local step" where individual participants can act alone.

The next step is similar, in that Bob publishes his hand; however, we don’t immediately commit the state, instead we compute the outcome of the game.

..    // ...
17    B.only(() => {
18      const handB = declassify(interact.getHand()); });
19    B.publish(handB);
20    
21    const outcome = (handA + (4 - handB)) % 3;
22    commit();
..    // ...

• Lines 17 through 19 match Alice’s similar local step and joining of the application through a consensus transfer publication.

• But, line 21 computes the outcome of the game before committing. ((handA + (4 - handB)) % 3 is a clever equation to compute the winner of a game of Rock, Paper, Scissors! using modular arithmetic. Consider when handA is 0 (i.e., Rock) and handB is 2 (i.e., Scissors), then this equation is ((handA + (4 - handB)) % 3) = ((0 + (4 - 2)) % 3) = ((0 + 2) % 3) = (2 % 3) = 2, which is the last outcome, that is A wins, as we expect it to be.)

Finally, we use the each form to have each of the participants send the final outcome to their frontends.

..    // ...
24    each([A, B], () => {
25      interact.seeOutcome(outcome); });
..    // ...

• Line 24 states that this is a local step that each of the participants performs.

At this point, we can run the program and see its output by running

  $ ./reach run

Since the players act randomly, the results will be different every time. When I ran the program three times, this is the output I got:

Alice is pretty good at Rock, Paper, Scissors!!

Consensus networks in general, and Reach specifically, guarantee that all participants agree on the outcome of their decentralized computation. Indeed, this is where the name consensus network comes from, as they enable these distributed, and untrusted, parties to come to a consensus, or agreement, about the intermediate states of a computation; and if they agree on the intermediate states, they will also agree on the output. That’s why every time you run ./reach run, both Alice and Bob will see the same outcome!

If your version isn’t working, look at the complete versions of tut-2/index.rsh and tut-2/index.mjs to make sure you copied everything down correctly!

In the next step, we’ll add some stakes to the game, because Alice needs to take her skills to the bank!