# ChainSafe & Toshimon Wrap-up

We are proud to announce that ChainSafe has been working with team at Toshimon to research new ways to leverage blockchain for gaming.

Toshimon came to us with a simple question. Can we make our player-vs-player (PvP) battle game provably fair and decentralized without compromising the player experience? We believe we have come up with a solution that provides exactly that.

## State channels for gaming

For a background on state channels please see:
- https://ethereum.org/en/developers/docs/scaling/state-channels/

State channels have seen limited adoption as a scaling solution in the wider blockchain world. There are a number of reasons for this but primarily the issues are:

1. Liveness requirements
- Participants must remain online to respond in case another player tries to cheat
2. Complexity of implementation
- For a dApp to be state channel compatible is must be reducible to a state machine that can be implemented in a smart contract
3. Restricted participants
- participants of a channel are fixed at initialziation and cannot change

Our first insight was to recognise that 1. and 3. are non issues for a PvP card game. Picture two people sitting at a table to play cards together. The games are typically quite short and the players don't change throuought.

Our unanswered question was if it is possible to implement a game with a complex rule set like Toshimon in a way that can be played within a state channel.

## The Toshimon Battle Game

The rules of Toshimon should be familiar to anyone who has played a mainline pokemon game. Players select a party of 5 monsters and do battle. Each player can only have one active monster in battle at a time.

Each turn a player can use one of the active monsters abilties to attack the opponents active monster, switch to a different monster, or use an item. Attacks may do damage, alter the attacker or defenders stats or inflict certain conditions (e.g. poisoned). The winner of the battle is the first player to reduce the hitpoints of all of the other teams party to zero.

There are over 160 different monsters in Toshimon (each with unique stats and move sets), around 140 different moves, and 10 different items. Each of these moves and items has a different effect on the monsters in the battle depending on their stats.

To further complicate things some aspects of the game have a random component. For example a random chance of a critical hit (or miss) and random variation for attacks.

As one can imagine, this is a vastly more complex game than what has been implemented in state channels in the past (e.g. tic-tac-toe or chess)

## Implementation Innovations

### Randomness Protocol

The randomness aspect was solved using a 2-party commit/reveal protocol. Each round players must commit to the move they intend to make and a random seed by publishing the hash in a state channel message. Players alternate turns so once both have commit then both reveal their moves and their contribution to the randomness.

The final player to reveal has all the information required to also compute the next state taking the combined random seeds as input. Within the state transition function this combined random seed can be used decide the outcomes of certain moves.

The one challenge in this protocol is the information advantage that Player B as over Player A in the final stage. Because they have commit to their move in advance they cannot use this advantage when selecting which move to make but they can use it to premptively exit the channel, a move which is always available.

To ensure that this advantage cannot be leveraged the outcome of the state channel is changed at each step of the protocol (A commit, B commit, A reveal, B reveal) to effectively count the signing player as the winner. This ensures B trying to exit the game in the final stage yields the same outcome as if B had lost the game, negating their advantage.

### State Transition Decomposition

The other key innovation of this design was observing that the state itself can contain contract addresses for small pieces of game logic (e.g. one move or one item) thus avoiding the need for a single registry for all of the game rules.

This has a number of very useful outcomes:
- The game logic can be decomposed into small state mutating functions. This allows for the large rule set to be decomposed into a collection of contracts to be deployed incrementally. Much like how cards in games such as Magic: The Gathering or Pokemon TCG can add new rules to the existing game

- It makes the game extensible. Anyone can add new functionality at any time but it is only allowed in a game if both players agree when initializing the channel

This is implemented in the state by each player storing a number of addresses of the item cards they hold, as well as a number of Toshimon which each store the addresses of the moves they are capable of. Again it is the responsibility of players to ensure the initial state is valid (e.g. Toshimon do not know moves they are incapable of).

For players using the official game client this can be done automatically but advanced players may choose to ignore this and play with their own custom rules.

## Conclusion

We look forward to seeing the production implementation of the game in the future and to seeing what is possible in a truly decentralized battle card game where players are free to play by their own rules.