Implementing a zkCosmWasm game and necessary private state transition patterns 🎡

[bmorphism]

BOUNTY: 1337.42069 $JUNO

Acceptance 🔍

(PLEASE READ: all of the below items are mandatory for bounty payout)

• bounty claims need to be submitted as non-Draft fully runnable Pull Requests against main in this repository
• feature complete UI for 🪨📄✂️ integrating Keplr wallet and all the necessary contract interactions as QueryMsg, ExecuteMsg etc.
• zkCosmWasm game backend implementation feature complete and diagram of its operation clearly documented
• a pattern for Keplr / DID encrypted private state accesses by each user from zkVM code using a well-studied scheme
• game to be accessed via a set of HTTP requests and barebones UI hosted on the same machine as zkVM / CosmWasm backend code
• game needs to be played by p > 2 players w/ different wallets
• tests to show several games can be happening at the same time in arbitrary order
  • unit tests
  • multitest contract simulation tests
  • (GODMODE) wallet simulation tests
• if PR is approved and merged, the developer needs to start the process of merging the zkCosmWasm example back into the risc0/ organization.

Congrats, when your code is merged to main here, please open the PR to risc0/ will be sufficient as the last step that allows you to post your claim as a comment here, together with a Junø address, and any comments about the dev experience that you care to share for posterity.

Why 🤔

We now have the zkCosmWasm smart contract execution pathway using the 1337 multiplication example, and the overall pattern for client interactions is now established (adapted from the NEAR battleship example):
Client (Keplr / DID) 🔜 Verifier (CosmWasm) 🔛 Prover (zkVM ELF)
...it is now time to build something even more fun to further develop / discover the zkCW pattens:
an imperfect information zero-sum game that ze Germans call Schnick-Schnack-Schnuck 🐊

What 🌀

• single-command spinup of the game and HTTP server hosting game UI, zkVM, and barebones cosmwasm runtime
• feature-complete game wallet-connected UI that users can reach over HTTP (e.g. over the same LAN / VPC)
• application of the ability to pass structs in and out of the zkVM code using env
• a pattern to encrypt, persist, and associate given state to a specific cryptographically-enabled identity (Keplr wallet, for simplicity)
• unit and multitest tests implementing the simplest pass of How

How 👩🏻‍💻

Note: ৹POINTS here for simplicity represent u128 / Uint128 recorded in a private matter in any convenient manner; in the future, these can become native or cw20 tokens in a simple wasmd game chain.

Gameplay 🃏

(to be enabled using various ExecuteMsg types, as well as QueryMsg that help the players know if they are gmi or ngmi)
The RPS game consists of the following loop:

• new players each start with 1230 ৹POINTS that they can use to form up games
• each player seeking to enter the game puts down at least 123 ৹POINTS
• players join a new GAME_ID and indicate readiness to start round
• GAME_ID drafting begins when n > 1 players have indicated they are ready via ExecuteMessage
• players select their played gesture out of the initial set of {R, P, S}
• when all players have selected their gestures are revealed
• those who have not submitted gestures within any subsequent GAME_ID game completing, automatically forefeit a given round
• rounds go on until there is one person left standing, or the stalemate - same gesture - lasts for more than 3 rounds
• several games each with a unique GAME_ID should be able to interact with CosmWasm simultaneously

WinRAR 📚

If there is a winning player ("last one standing"), 42 ৹POINTS from the amount of total ৹POINTS put down by the players is sent to the pre-designated 'croupier wallet' (foreshadowing DAO treasury / bank module).

If the game ends in stalemate, all the ৹POINTS are sent to the second player to submit a gesture choice for this GAME_ID (their identity not known to the other players, but determined in a verifiably correct manner).

(optional) Theory 🕹

https://archive.org/details/isbn_9780465009381
https://www.sciencedirect.com/science/article/abs/pii/S0378437119314499?via%3Dihub
https://iopscience.iop.org/article/10.1209/0295-5075/134/48001
https://www.nature.com/articles/380240a0

[bmorphism]

@JakeHartnell let me know if this makes sense and fits within your understanding of what the next evolution of zkCosmWasm can be / how this can be simplified further, or conversely, made to include patterns that may benefit subsequent development of capabilities, up to supporting private DAO assets.

What do you think about opening the bounty up to select qualified (!) potential contributors as an invitation to compete / consider the codebase?

Points of note that came to mind:

• aligning Rust / CosmWasm integer types
• how to ensure determinism (True returned to CosmWasm is always True and so on, and so on)
• this should help develop the patterns for passing structs back and forth using env
• the instruction set for the zkVM ELF method is that of RISC-V RV32IM and means we should be able to perform general-purpose computations we typically expect from a typical ISA, with the exception of needing to use env and cryptographically sound methods for persisting any given player's private state (gestures), as well as global state of the game

Here too we could reference battleship for inspiration as far as the pattern enabling imperfect information, and specifically with the intent of effectively hiding the gesture selected by each player from other players while ensuring the rules of the game were applied (provably!) correctly, even if privately. #metamath