# (ZK) State Channel Games 2

## Consensus Failures and Fallbacks
There are two types of failures that can occur: timeouts and replay.

Timeouts: Alice and Bob are playing a game. Whether negligently (Alice's internet disconnects) or maliciously (Alice leaves the game before it is over). In order to enforce liveliness, counterparties must be able to post partial state onchain and trigger a countdown to timeout that slashes the entity that times out. This can be "griefed" however - a channel participant can make a state channel expensive by triggering the timeout onchain at every single state increment. Though a reputation system might be useful here, it is unclear how to fully remediate this attack since, when a timeout is triggered, it cannot be proven that the party triggering the timeout was honest or not. A reputational system would therefore have to either slash both participants (negatively impacting the reputation of the honest party responding to timeouts) or slash a participant who triggers too many timeouts (potentially punishing an actor who is honestly reporting liveliness failures).

Replay: Alice and Bob are playing a game. On turn (for example) 4, alice sends a disadvantageous move to bob. By turn 4+N, alice realizes the turn is bad and wants to make a different move, so she tries to use a new state increment for turn 4 and sends it to bob, potentially even triggering a timeout. There now exist two proofs of turn 4 constructed by Alice, both of which Bob can produce. Whether the first state increment proof has been posted via timeout or both increments exist offline, bob demonstrates onchain that alice constructed two proofs for the same turn increment. This would slash alice and immediately close the channel according to malicious ending exit rules.

Slashing can be done in one of two ways. In low-trust environments, financial collateral/ stake must be posted at the start of a channel open. This stake can be slashed if the party misbehaves in any of the previously described ways. In scenarios where sybil resistance is difficult, the only way to disincentivize malicious or neligent behavior is to make the financial cost of such behavior higher than the cost of accepting a valid but undesirable outcome in the state channel (slashing will result in undesirable outcome + the penalty).

In higher trust scenarios like games or applications with litigation (kleros or legal), we can rely on reputation systems. If the described misbehaviour occurs, it will result in parties discriminating against interacting with a counterparty. While this is not totally resilient to sybil, this can be time-weighted such that older profiles with high reputation have the best user experience & ease of interaction with counterparties.

## Infinite vs Finite state channels
In infinite state channels, there is also a stale state attack. An infinite state channel has no exit condition by which state cannot be incremented beyond it. For instance, take a payment channel. If the current state is `{Counterparty A: 100, Counterparty B: 300}` and alice wants to close the channel, they either need an optimistic period for bob to contest the settlement by providing newer state signed by alice, or both bob and alice must agree to close the channel to allow instant finality.

However, we can design "finite" state channels. There is no limit to how many state increments can occur in a finite state channel, and it does not need to be deterministic (i.e. always ends at 100 turns). However, there must be some provable "exit condition" that the state channel proof can demonstrate satisfiability over. If an exit condition can be proven, a state channel can be settled instantaneously (without optimistic challenge period).

## Game Genres that Function Best with State Channels
Like in regular blockchain gaming, the easiest games to build with state channels are turn-based games. This excludes a significant amount of games, however the market for turn-based games is still significant.
- Pokemon (battles at least, have to figure out how world traversal might work)
- Civilization (requires a fog of war mechanic)
- Baldur's Gate (I think? I've never played it, just make it multiplayer though)
- All card games (already explored fairly extensively though use of NFT's in web3)
- Other games like xcom, worms, etc

An extension on Jay's story-driven game would be dungeons and dragons. It would be hard to codify the rules where you can do anything (I think, again never played), but this is turn-based and incorporates incremental story telling.

## High tick-rate games
It is theoretically possible that games with higher tickrates could be done in state channels, though such an architecture would likely rely on the election of a "leader" for the game that hosts world state and orders state increments. Essentially, it begins to resemble an appchain/ rollup, even if it is ephemeral and the entire chain state is collapsed into a single state channel proof at the end. This is not something I have thought through enough though

## Fog of War
A common element of pvp turn-based games that is difficult to facilitate currently is "[fog of war](https://www.giantbomb.com/fog-of-war/3015-14/)". This describes a shared world state where each counterparty can only see parts of the world state according to their own state (position, abilities, etc). While this mechanic cannot be accomodated by a state channel alone, the incorporation of multi-party computation or private set intersection into such a game could facilitate this.

## Single Player with ZKML
Traditionally, onchain games are played against other players. However, it is possible to design a system where a single-player game can be played and validated onchain using zkml. Folding is an interesting way to accomplish zk state channels, and by employing folding in this system we can also significantly reduce the cost of proving a single player zkml game. An exmaple of such is https://github.com/dmpierre/zkconnect4

# On monetization, sustainability, etc
A sufficiently compelling game experience not bogged down by technical barriers will likely be enough to attract web3 users. Wager match mechanics are, in my opinion, the optimal way to keep players engaged on a longer term basis while allowing fees to be taken for protocol revenue. This obviously introduces more incentive to cheat, however this can be handled in the same ways that online poker attempts to prevent cheating. In certain cases, we could also employ a zkml model to check if the optimal move was made most or 100% of the time and target cheaters this way.