As you know by now, using CC you can create your own custom consensus logic. Instead of having to recreate the entire blockchain codebase from scratch, you can just make a special custom CC vout type and the matching validation.
One day, I had a crazy idea. What if we could blockchain the entire gameplay so there is no doubt that the game was actually played. If this was possible, then when you see someones high score posted, you would know it was for real.
But how can we go from validating transactions to validating gameplay?
To simplify the problem, I started with sudoku, which is a very mathematical game where you fill in the blanks for numbers to make a pattern. Of course, there are solvers that can solve any sudoku in milliseconds, so we end up with a captcha problem to make sure it is a person doing the solving. This opened up an entire new problem, which ended up making the sudoku CC, a deadend in the quest for proof of gameplay.
Still, it did break new ground by having the solvetimes for each square logged and a simplistic algorithm to detect obvious computer solving, but ultimately it becomes a cat and mouse game, as the bot writer can test against the captcha algorithm to make sure the bot puts in a set of timestamps for each square that will be accepted.
What I needed was a game that wasnt algorithmically solvable, at least something that would take more than a trivia effort to solve with a bot. I remembered a classic game called rogue, which was a text only game using the keyboard for all user input. It is a turn based game and uses a deterministic random number generator. This is a critical aspect! Given the same starting seed and the identical user input, it would replay the identical game.
Aha!
Given this behavior as a constraint, it became possible to make the first Proof of Gameplay blockchain. I will just describe the single player mode, as multiplayer is just running parallel single player instances and the players compete to complete the game first, or more realistically to die last.
In rogue the starting level and basically everything is determined by the initial seed. As the player makes decisions, the RNG is used and updates the current seed. Some levels start with lots of good items, others are sparse, so to make it a random starting level, the hash of a future block is used as the initial seed. This prevents the player from simply selecting an advantageous seed. Great care must be used in all aspects of blockchain design to prevent any such advantages.
Here comes the crazy part! In order to be able to blockchain enforce the gameplay, the gameplay engine needs to be embedded inside the daemon!! Of course, only the internal gamestate needs to be updated based on the user input, we certainly dont want the daemon to start updating the screen with all the games it is validating.
To transactionalize the rogue game, I made a keystrokes tx, that use a baton to create an ordered linked list of all keystrokes for the game. I also added #ifdefs inside the rogue game engine to have a daemon mode, mostly by using the cursesd that i created for maintaining the curses screen state without doing any output. At the end of the game the entire set of keystrokes is replayed using the same seed to duplicate the identical ending gamestate.
On a modern system, the typical game is able to be validated in a couple milliseconds. Which is fast enough for thousands of games to be validated per block.
One surprising result was that the transaction to claim ingame gold and ingame character attributes didnt need to submit any details of how much gold nor what items were found! Since the replaying of all the keystrokes recreates the exact gamestate, all nodes are able to calculate exactly how much gold and what exact items a player had.
To my knowledge, the rogue CC was the first Proof of Gameplay implementation that allowed for trustless gameplay where any score or character details come with a proof of how it was created.
Granted, there is no captcha to determine if it was human play or bot play, but at first we can know that nobody had time to make any bots for it. Maybe, such games eventually become a battlefield of bot vs bot, at least at first it can be human vs human competition.
There are also a few unsolved issues with this iteration, but in following posts, I will explain both the attack and mitigation
