Turn Based Games in the Blockchain

using digital signatures

Overview

This paper defines an approach to a turn based game engine using peer-to-peer technology coupled with Florincoin's blockchain protocol.

A purely peer-to-peer gaming engine would allow open source games to be played on a global scale using the Florincoin protocol without storing every turn in the blockchain. This is possible through proof-of-turn; a protocol defining game initiation requests, turn handling, game conclusion and dispute control entries. A schema for verifying users' turns without storing each turn in the blockchain enables the system to scale without becoming unmanagable. Storing the beginning and end of a game allows Elo and reputation to be calculated on chain, while disputes can be handled off-chain as users keep their proof-of-turn data stored locally.

Process

The process of beginning, playing, and ending a game requires the following steps:
Request to play
Each game begins with a request to play. The game creator sends a request to one or many recipients. A request is built upon the following parameters provided by the game creator:
  • txmp: Transaction message protocol version to be used.
  • game: The name of the game to be played. Each game has its own unique name within each transaction message protocol.
  • block: An identifying block. This integer helps to identify this game. It is also the latest possible block that this game can begin on.
  • address: Their public key, to further identify the game on the network.
  • salthash: The SHA256 hash digest of a salt that is chosen using a strong random number generator.
  • sig: The signed JSON string.
Here is an example of a request to play which is received on the front-end by one or many recipients:
{
  "txmp":"t1",
  "game":"Example_Game",
  "block":500000,
  "address":"FJFiJDXs5WeW8RYbDn4BXsK5HQCPuLuAKj",
  "salthash":"cbdc61b2ccd24d3e1e1a51c2addf91fbc214096ae6280318a65f5a0035d969b3",
  "sig":"Hw8EAFC/NKLcTaMJXWGdKXRzGycAlaa1Zzw8hYVM2wUksYfXVxI/nvt+NOIA9t4n22DS5gtMbJi3/Cn3AJdxUoc="
}
In this example, this is the JSON string that was signed. It includes all data except the signature:
{
  "txmp":"t1",
  "game":"Example_Game",
  "block":500000,
  "address":"FJFiJDXs5WeW8RYbDn4BXsK5HQCPuLuAKj",
  "salthash":"cbdc61b2ccd24d3e1e1a51c2addf91fbc214096ae6280318a65f5a0035d969b3"
}
This is the salt chosen for salthash:
salt128941824908124098190248910248091284091280
This front-end request is designed to allow users to easily invite their friends who may not be friends with the original game creator. Of course, a game request can also be posted to the public or restricted (invite-only).
Note: specification is not completed yet. There may yet be another JSON object for game specifications (such as max players, difficulty, board size, starting HP, and other relevant parameters for a game).
Joining a game
After receiving a request to play, any player interested in joining the game must post a message to the blockchain with the following requirements:
  • game: The name of the game to be played. Should match the game param in the JSON request to play.
  • block: The latest block this game can begin on. Should match the block param in the JSON request to play.
  • gamehash: The hash of the JSON request received from the game creator. This serves as the game ID.
  • salthash: All players choose a significantly random salt, hash it, and publish it to the blockchain.
This is the basic structure of a tx-comment a player would post to the blockchain to signify their interest in joining the game:
t1:joingame>[game],[block],[gamehash],[salthash]
Here is an example using the above request to play data:
t1:joingame>Example_Game,500000,9737054d4d8b75852f94074c947b487e0389a5fb27d1e05636f6a87fdfa7418a,b599e0fae351e5279e2725b38cc5a6ebfccf85a00b5bee65118879c9de33aeb8
The salt chosen for this user is:
user2SALT9128490182409812490812490
Taking a turn
After the game has begun (block 500,000 in this case has passed) and the game meets its other requirements, users connect via the front-end to take their turns. The game creator goes first. These are the required parameters to be passed via a JSON string for each turn:
  • prevturnhash: The hash of the previous turn JSON. Omitted for turn 1.
  • movenum: An integer which represents the number of the move.
  • movecode: A code which includes the move data. For example, chess notation move data would be something like "E2-E4 E7-E5".
  • salt: The plaintext of the salt chosen and hashed previously.
  • sig: A digital signature composed by signing the prevturnhash as well as the movenum, movecode, and salt.
{
  "prevturnhash":"",
  "movenum":1,
  "movecode":"E2-E4 E7-E5",
  "salt":"salt128941824908124098190248910248091284091280",
  "sig":"H9gcTb5eG3eR+zkaVLaCywPKyPycTVjDbejxls4xJBfoWpQ2ETGWDxPJ3boLTV83cKyVOkV0pSfkvxBNAe+AWnY="
}
The signed data in this example was the JSON representation of the prevturnhash, movecode, and salt:
{
  "prevturnhash":"",
  "movenum":1,
  "movecode":"E2-E4 E7-E5",
  "salt":"salt128941824908124098190248910248091284091280"
}
Important: at this point, the user's salt is revealed. The salt is a mechanism to avoid signed movecodes from being repeated and used in disputes for other games.

It's now the second player's turn. Their requirements for a turn are exactly the same. Here's the JSON they pass to the front-end:
{
  "prevturnhash":"2567d3c627d80ed896e0d68037f9466b94f319598f47c5f53271af981f4de8a0",
  "movenum":2,
  "movecode":"E1-G1 B4-C3",
  "salt":"user2SALT9128490182409812490812490",
  "sig":"H54SzFbvBKqWdZkgwH/fXpwWj3cAmu7o1IDVzIHeQekMCd70YJvIwpWzDVEFWtc8FnG84la299joP66QKknOQCQ="
}
As usual, the signed data is the JSON representation of the prevturnhash, movecode, and salt:
{
  "prevturnhash":"2567d3c627d80ed896e0d68037f9466b94f319598f47c5f53271af981f4de8a0",
  "movenum":2,
  "movecode":"E1-G1 B4-C3",
  "salt":"user2SALT9128490182409812490812490"
}
The address for this user is:
FKPAUyySMoWG5WACf39E9icNhw8tvqwm2j
Here is a visual representation of this process: visual
Ending the game
The game is won when a win condition is met on the front-end. The winner posts the hash of the last move in which he was declared the winner.
t1:wingame>[prevhash]
Disputes
Any dispute can easily be settled using the hashing structure of turns.
  • All players should keep a file generated by the front-end holding the hash-signature structure of the entire game.
  • The player with the longest hash-signature chain can prove he stayed in the game the longest.
  • All turns can be reconstructed and proven to be executed by each individual player by checking signatures.
  • ELO and reputation are stored on the blockchain.
poweredby