Download ROCK, PAPER, SCISSORS...Cheat — Verified Decentralized ... and more Summaries Architecture in PDF only on Docsity!
ROCK, PAPER, SCISSORS...Cheat — Verified
Decentralized Game Play
Changping Chen, Ariel Hamlin, Jeffrey Lim, Manushaqe Muco
MIT
Version 1.
May 13, 2015
1 Introduction
In our project we address the problem of how to implement a stateful multi-player game while minimizing trust in third-parties. By “stateful” we mean that there is some meaningful state that persists between separate interactions, as opposed to each interaction being self- contained, as in chess, tic-tac-toe, etc. A typical example of a stateful game is poker, since each hand affects the money balances held by each player, which persist between hands. Most games that exist today prevent cheating either by centralization — requiring that all interactions be routed through a trusted third-party solely responsible for maintaining the game state; or else by obfuscating the software running on each player’s device to prevent them from illegally altering the state. In our project we seek a way to use cryptographic technology to alleviate these constraints. Our project implements a minimal game of this type as a proof-of-concept.
1.1 Overview
For this project we have implemented a minimal example of a game with these properties, which we call “Rock-Paper-Scissors-with-state” (RPSWS). The rules of the game are as follows:
- Any player may initiate an encounter with another player, who may or may not choose to accept. (The two players are known as the challenger and the defender respectively.) No player may be in more than one encounter at the same time.
- An encounter consists of a number of rounds. In each round, each player commits to their move (either Rock, Paper, or Scissors), and reveals the commitment to the other player. The winner of each round is found according to standard Rock-Paper-Scissors rules (Rock beats Scissors beats Paper beats Rock).
- The player to win two out three rounds wins the encounter.
When the encounter concludes, each player’s “skill rating” is adjusted according to a simple formula^1. Players’ skill ratings persist between encounters.
1.2 Architecture
Figure 1: Overall Architecture
The game ecosystem as a whole may be conceptualized as a number of players who periodically interact with each other and with a “ledger” that represents the global state, available in common to all players. The principle guiding our implementation is that each communication should involve as few parties as possible. Communication, when it does occur, goes over a peer-to-peer network for voters, and from point to point in the case of players. Players communicate with each other to play out encounters, which they then submit to the voters for verification and “disposition” (i.e. the process of updating the ledger to reflect the outcome of the encounter). Accordingly, in our design we have taken pains to ensure that gameplay only requires the players to interact with the ledger at the beginning and end of an encounter. In particular,
(^1) The winner gains (and the loser loses) an amount of points equal to
⌈ 1000 1+e W 1000 −L
⌉ , where W, L are the skill
ratings of the winner and loser before the encounter, respectively.
different. Of the main security properties of MPC, we are concerned primarily with the fair- ness of the outcome. We are not concerned with hiding the other player’s input; in fact, we want players to be able to tell if they have won or not, so that they can verify the skill level changes determined by the outcome of the game. Even though we are only concerned with the fairness of the protocol, we can still apply results from MPC in the case where we have a malicious majority (in a two party interaction, even one malicious player is considered a majority) [2].
3 Player
3.1 Design
As mentioned in the previous section, transactions are submitted to the ledger by “players”. A player is tied to an “account” (essentially, a public key) recorded in the ledger. While it is possible for a voter to be a player as well (in fact, this is how players can earn currency to fund their game transactions), our model does not require this. We assume a supporting infrastructure for players to contact each other in order to initiate encounters. This involves account identity and network information (such as IP address or open port numbers). Players must be connected to each other during an encounter, except in the case of aborts, which we discuss in Section 5.3.
Figure 2: Player Interactions
Game play proceeds with a player initiating an encounter, as shown in Diagram 2 as Message 1. This initiator is called the challenger and the other the defender. It contains of the challenger’s and defender’s account IDs, and various encounter-specific values to help prevent replay and forging attacks, in a manner we will discuss later. This message is signed by the challenger. The defender may accept or reject the challenge. If they accept, the gameplay advances with three rounds of RPS, each of which consists of four messages:
- Defender commitment: The defender chooses a move (Rock, Paper, or Scissors) and calculates a commitment. In a signed message they send this commitment, along with the signature of the previous message. This prevents the message from being taken out of context and assembled into a fake encounter transcript later. At this time, the defender also submits an InitiateEncounter transaction to the voters, instructing them to mark the two players as currently being in an encounter with each other, including all of the values specified in Message 1.
- Challenger commitment: Upon receives the defender’s commitment, the challenger first queries the voters to verify that the ledger has been updated with the InitiateEn- counter transaction. (This avoids the possibility of having an unregistered encounter that will not be allowed to alter the ledger.) Then, the challenger forms a commitment to their own move, again including the signature of the previous message.
- Defender reveal: The defender responds by revealing their own move.
- Challenger reveal: The challenger reveals their move.
This proceeds for three rounds. Afterward, the defender sends a “resolve” message to the challenger, and posts a CloseEncounter transaction to the voters, consisting of all of the messages sent so far. Once the voters have verified the validity of this transaction, they update the ledger accordingly.
3.2 Security Argument
We allow for the following limited malicious activity from players:
- Malicious parties (either the players themselves, or a third party who has access to the transcript) replaying a game transcript to the voters
- Either player quitting mid-encounter to prevent the game from reaching a conclusion
- Either player attempting to change their move after seeing the other’s move
- Man-in-the-middle attacks between the two players
- A malicious party forging an encounter (or parts thereof) to post to the voters
P2P Architecture In our model, players are assumed to have access to a third-party which provides routing information for players in order to initiate games. This is unnecessarily limiting for users to discover opponents and is very close to the third-party system this architecture was attempting to avoid. As a possible mitigation, it may be possible to apply concepts from peer-to-peer systems for routing and resource discovery.
Gateway Attacks If the player cannot make choices as to which voters they are willing to talk to, they are susceptible to gateway attacks. In our current architecture, commu- nication between a player and voters takes place through a relay, and as such, players have no control of which voters they communicate with. As a result, their communi- cations may be relayed to a malicious voter who may drop or otherwise mutate their transactions. Player choice of which voter they wish to communicate with would be an effective extension of our current architecture to mitigate gateway attacks. Then, a player can have some notion of “trust” in a particular voter and only communicate with those deemed trustworthy.
Player Censure There are several ways a player can detect malicious activity by their opponent: they try and reveal a move they did not commit to, their signature does not verify, or they never issued the InitiateEncounter transaction. In this case the player has no formal way to penalizing this behavior beyond choosing not to play another game with that player. In fact, if they choose to discontinue the game upon detecting malicious behavior, they themselves may be penalized for aborting the game prematurely. As a result, for future work, we propose extending functionality of player- to-player interaction to handle player-side censure of malicious behavior. There are several open problems in this case, as this faces issues similar to those raised in the fairness or attribution of abort — it may be difficult for the voters to determine which party is being malicious.
4 Voters
The ledger is implemented as a distributed network of voters, each of which maintains its own copy of the current ledger. Clients submit transactions to the voters through the relay, which then broadcasts them throughout the network; the voters update their ledgers based on these transactions. The voters’ responsibility is primarily to check transactions for external validity (i.e. consistency with the current state), as opposed to internal validity (i.e. the well-formedness of the transaction object itself), which can easily be checked by anyone without reference to the current state. However, voters do verify the internal validity of transactions in our design. A transaction that is internally valid will not necessarily be externally valid — for example, an InitiateEncounter transaction, even if validly signed, should be rejected if the two players are already in an encounter. Thus, even a small disagreement about the current state will lead to different transactions being accepted or rejected by different voters, which will lead to still further disagreement, and so on. It is therefore necessary that all voters come to consensus about which transactions to accept or reject — maintaining this consensus is more important than any particular ordering of transactions.
More precisely, this problem is known as distributed Byzantine consensus, referring to the fact that the system must withstand some amount of malicious behavior on the part of the voters. The most well-known system of this kind is Bitcoin [4], in which voters “vote” with their computing power by contributing to a proof-of-work chain. However, for our application we chose not to use Bitcoin (or a similar system), for two reasons: first, Bitcoin transactions take on the order of 10 minutes to confirm, which is too slow to accommodate reasonable gameplay; and second, proof-of-work is expensive for the voters in terms of hardware and electricity costs, which would be prohibitive for an application such as this that is primarily a form of entertainment rather than a financial instrument. Instead, we propose a proof-of-stake system, where voters’ votes are weighted according to how much “stake” they have – stake being a currency that can be transferred and used to pay for transaction fees). The mechanism we propose is based on the Ripple consensus protocol [6, 3], which intro- duced the idea of the “continuously closing ledger”. In Ripple, voting proceeds in stages, at the start of the consensus round, voters verify internally-valid transactions that they believe should be included to the ledger. Once the internal process is completed, transactions are broadcast to some subset of voters on the network. At each stage, each transaction must be approved by a certain fraction of the voters in order to advance to the next stage. This threshold increases in each stage, starting at 50% and increasing to 60%, 70%, and finally 80%, at which point the transactions are considered finalized, the ledger is updated, and the process restarts. Any internally-valid transactions that did not make it into one consensus round are deferred till the next; each round typically takes 4-5 seconds, which is fast enough to be a realistic mechanism for gameplay. In contrast to our system, Ripple voters weights other voters’ votes by membership in a unique node list (UNL) maintained by each voter — if a vote comes from someone in the UNL, it counts for 1; otherwise it counts for 0. The advantage of this is that it is not necessary to trust everyone in the UNL; it is only necessary to trust them not to collude with each other, which is a much less strict requirement. Nevertheless, the necessity to manually configure one’s UNL is a disadvantage, which we aim to alleviate by proof-of-stake. If the stake is distributed in such a manner that it is unlikely for a majority of the stake to be controlled by colluding entities, then it is reasonable to presume that it will remain so distributed even when individuals transfer their stake to others. If the stake can be distributed initially in this way (such as by giving 1/1000th of the stake to 1000 unrelated individuals), then by induction we can be confident that it will continue to be hard for an attacker to collect 51% of the stake. Stake is moved between individuals as part of transaction fees, or to add new voters into the voting pool. It should be noted, however, that such economic arguments are quite imprecise and non- rigorous, as far as security is concerned. Research is still ongoing into the question of under what conditions Bitcoin, Ripple, and similar systems can be proved secure.
5 Mitigating Player-Voter Communication Attacks
In this section we discuss the mitigations for multiple games, replay, and abort attacks. It is worth noting that delay attacks in which game transactions are delayed in their posting
to playing one. Let us assume that Alice is playing a game with Bob, or has committed to play a game with Bob. Alice’s current account state will reflect this fact – listing her as in encounter with Bob and that it started at a certain time. If Alice wants to initiate another game, the voters will check her current state and see that she is already committed to playing against Bob. A player is not allowed to play multiple games at once, so the voters will not include the initiate game request for Alice and the game will be discontinued.
5.3 Abort
As alluded to previous sections, we incentivize proper behavior in the case of one player prematurely ending, or aborting, the game. Ishai et al [2], show that in the case of a malicious majority, it is possible for the parties in the MPC protocol to know who aborts. Conversely, parties, such as the voters, who do not take place in this computation, cannot ascertain who the aborting party is. Within these results, we attempt to motivate ‘proper’ behavior within reason. Our protocol allows a user who believes the game has been aborted to post this fact to the ledger. The player includes the proof of the game so far in this notification which is stored in the users’ account state. The opposing player now has a set amount of time to refute the abort claim. At this point, there are two possibilities:
- The accused player rebuts the abort claim and posts their own move to the ledger to continue the game,
- Or the accused player fails to post and the skill involved comes out in favor of the accuser
Due to the fact that each transaction with the ledger has a set cost in stake, it is far cheaper to continue game play through player-to-player interaction — not to mention more timely. In gameplay through the ledger, players must wait for the ledger to be resolved before they can make the next move. It is worth noting, that while the voters do not know which player truly aborted, the players themselves do know. That being said, the honest player can blacklist the malicious player for future games.
6 Implementation
We created three individual components as part of our software prototype: relay, voter, and client. For more information about the implementation and the code refer to Section 7. Relay instantiates a TCP server that voters connect to. By keeping a list of connected voters, it can relay a message received from any voter to all other voters to simulate an idealized lossless peer-to-peer network. In the current implementation, a client does not directly join the voter network, but instead posts and receives message from voters through a separate HTTP server interface on the relay. Voter is a game proof verifier that records and maintains the global game state in a SQLite database. A voter upon receiving game proof from clients through relay’s HTTP interface,
will validate the proof according to predefined rules and broadcast its validation result via relay to other voters. A voter also receives validation results from other voters. Once a consensus is reached, the SQLite database representing the ledger is updated accordingly. A voter must have a valid account already existing on the ledger to do so. All components take advantage of asynchronous network programming featured in Python Tornado library. It abstracts low-level TCP networking API in a event-based paradigm and uses advanced Python coroutine feature to support concurrent access. This greatly eases the implementation of communications between components. We use PyCrypto for the cryptographic primitives, including RSA encryption and digital signatures. For hash functions, we use Python’s built-in hashlib module. Since no implementation for a commitment scheme was readily available, we created our simple commitment scheme. In our design, a user concatenates the value to be committed with a 20-byte randomly generated padding, and computes the SHA256 hash of the con- catenated string as the commitment. To reveal the commitment, a user sends its committed value and previously generated padding to the verifier who computes the correct commitment and checks if it matches the previously received commitment. We represent users in our system using their unique public-keys. In addition, similar to the Bitcoin network, we use a 48-character long account ID generated from the trailing 36 bytes of the hash of a user’s public key encoded in DER format. This significantly reduces the length of an account ID, while preserving the one-to-one mapping between users and account IDs. However, when users sign a message, they must include their public key along with the signature since the verifier may not necessarily have the signer’s public key for verification. The verifier must also check if the signer’s account ID corresponds to the received public key.
7 Conclusion
We have designed and implemented Rock-Paper-Scissor-with-State to provide a verifiable, decentralized, game platform. Our voter network leverages existing consensus methods to allow for decentralized global state and our players provide verifiable game encounters. It is our hope that this general platform with its security guarantees and protocol flexibility can provide a base for more complex game protocols that include verifiable randomness, increased number of parties, and more efficient proof verification.
7.1 Code Repository
Links to our implementation and information about usage can be found at the following locations:
- Rock-Paper-Scissors-Cheat Github Repository
- Code usage
