How protokit can revolutionize on-chain gaming & how to cook it to implement a multiplayer game
Protokit is a product developed by Mina Protocol team. Basically it’s a tool that allows to set up your own app-specific L2 network. This network is separated from L1. It’s impossible to access L1 contracts – the only contracts exist in the network are defined by network developer and known as runtime modules. As only they are presented in the network they can be identified by names instead of addresses.
The only connection between L1 and app L2 networks is bridging. Mina token can be bridged to an internal user balance in an app smartcontract. Then other smartcontracts can check user balance and decrease it to pay for actions. It will be possible to bridge L1 tokens as well when the token inside Mina L1 network is standardised. In this case user deposit amounts and token infos will be stored inside L2.
This L2 network works off the L1 chain but captures state changes and pushes proofs to the Mina network. This solves mina limitations of storing smart contract state in not more than 8 slots of 32-bytes size while inheriting the L1 network security. This allows to handy implement such features as leaderboards, players waiting room for matchmaking.
Another usefull fact about app network – you can decide whether to charge fee from users for transaction or to make transactions completely free. This allows to create gassless transactions that are crucial for gaming UX: a session key can be created on frontend that is registered by user and used to sign game transactions in background without interruptions for transactions confirmation.
Session key is a keypair generated on frontend for temporal purpose, for example to sign transactions within one game competition. The public key of the keypair is registered on-chain by user transaction and then all the session transactions are signed and executed in background without user confirmation.
This is exceptionally useful in multiplayer games: to sync state between chess two players, a transaction should be executed after every user move. Session keys with gasless transactions brings the most comfortable gaming experience.
To cook both L1 and app L2 networks inside one application we decided to consider L2 as a game room network. User connects to it only when enters the game round. If game round is payed and required a fee to play, assets are bridged before entering
If it’s a multiplayer game, match making occurs. A competitor is chosen from the waiting room pool based on similar game level or other conditions. If there’re no suitable opponents, user is registered in the waiting room pool and waits for someone else to join. Once opponent is found, session key is generated on frontend and registered in the network. Now game can make background transaction with no players interruption
After round created user1 move is awaited. If user haven’t made his move within allowed time, user2 can prove it user1 move is skipped. Is user1 skipped several moves in a row, he disqualified and user2 wins. After user1 move transaction is executed and on-chain event is emitted. This event is handled by user2 frontend that displays the updated game state and asks user2 to move.
After one user won or there was a draw, competition is marked as finished and prize is unbridged to the winner to L1 network
This can be combined with game process proving as L2 network supports ZK proofs verification. While playing their move users recursively accumulate game process proofs, then final proof is verified in the move transaction.
Conclusion
ZK proofs open up wide possibilities for convenient gaming experience. Solutions like protokit make it possible to create multiplayer games that prove the entire gaming process with UX just like in web2 games. In ZkNoid we hope to start the generation of such games
