Current Architecture:
Our current version working with Protokit consists of 3 main modules:
Balances: control user balance (in Mina) to buy games.
GameToken: allow creators to publish their games, customize them and controls the sales of games.
DRM: keeps device information hash of users that have bought game, and their device’s last session informations.
First, game producers register their games in the system using GameToken with a submission fee (currently 100 Mina fee in test appchain). In doing so, they set their own properties such as:
gamePrice, discount, timeoutInterval, number_of_devices_allowed
and only they can change them afterwards. In this way, users can purchase the game added to the system.
Users purchase their games or can pay for their friends and gift to them on Mina by paying the sales amount gamePrice - discount set by the publisher with Mina. Users who have purchased the game are stored in a mapping as:
[key: (gameId, UserPublicKey)] -> value: Bool
After buying the game users can download games to their computers (we currently support Windows, MacOS and Linux). However, they will need to register their device in order to play. To submit their devices, they use zk-proofs with a built-in system to ensure privacy. This not only ensures privacy but also prevents them from spoofing information they don’t have.
These are the unique identifiers that our system uses to distinguish devices from each other:
cpuId
systemSerial
systemUUID
baseboardSerial
macAddress
diskSerial (not active yet)
After the device information is collected (without taking it out of the user’s computer), the hash is created with the zk-program to save in DRM module.
This proof allows the device to be registered in any slot of the user’s choice from the number of slots specified by the game publisher. min: 1, max: 4 slots
Session creation and playing
DRM Mina uses its own DRM protection to solve ownership verification in the most player-friendly, flexible and secure way possible. The verification process consists of 3 main parts:
App-chain
Game and its verification scripts
Local Nodejs host for generating zk-proofs and Mina txs
When the user first opens the game, the game verifier takes the device’s information in the background and runs some checks first, then it sends a query to the app-chain sequencer to get and check the current session information on the chain. If the game is enabled, it selects a random value that is different from the current one and sends the necessary information to the Nodejs host (which runs beside the game) and asks it to update the state and continuously checks the on-chain state for a certain period of time.
Session Proof Generation and Submission
As public input when generating session proof it takes:
gameId
currentSessionKey
newSessionKey
In addition to these, it also receives the information that we do not want to leave the user’s computer but at the same time we need to make sure that it is generated from the correct device as private input. After providing the necessary checks, it gives gameId, newSessionKey, hash as public output. In this way, both confidential information is prevented from leaving the computer and fraud attempts or double usage of proofs that can be made while updating the session state are prevented.
The user’s wallet is not needed to send this transaction. The host can send the transaction to the sequencer from the random temporary wallet it created. The sent tx changes the state if it contains a valid proof. If the in-game validator validates it within the specified time, the player can play the game without generating a new session during the timeoutInterval but if not, the player is logged out from game.
New Architecture:
With the new architecture, we plan to move game purchases, session creation and other contract interactions directly to L1 through OffchainState. In addition, we want to handle the process of sending the session proof that users need to generate to play their games to the network through a separate sequencer so that they do not sign and send tx on every game session.
In addition to this, with the device data collected from volunteers so far, we will check the validity of the identifier information in the contract and in the game in general terms.
The design of the purchasing system will be similar to the old one, but instead of doing it in the central sequencer, we will move it to L1. The sequencer will act as the data layer for offchain storage. Of course, the content and logics of the contract may need to change during this process.
In the current version, users send their proofs to the appchain and let it handle the settlement, but there is no settlement part in the current version. In the new version, the local Nodejs prover that will run on the users’ local will send the proofs to our new sequencer customized for this instead of the appchain, the proofs collected in a recursive way with other users who send in that block will finally be settled to L1 by the sequencer.
With all of this, we will release a more optimized and customizable version of the current DRM Mina Unity package in line with the revised contracts. We will also prepare the documentation of the system so that users who want to integrate the package into their own games can learn how to do it and find answers to their questions.
, thanks for the feedback. In this architecture sequencer will work as a transaction aggregaotr to prevent users from paying transaction fees for each game session, because they need to proof they can change corresponding state to auth. Of course, if the sequencer gets congested or crashes, they can send the transaction directly from their computer if they wish but this time they need an Mina account on their local prover. Actually, the problem we will face is similar to the one we would have if we were using the protokit appchain in its current form, which can also crash and stop. Since Sequencer will only be used as a transaction aggregator, it cannot be said that the system stops completely if it crashes. However, since we are using a centralized system as a data availability layer for now, temporary blockages may occur in some cases. We will try to solve these as well.
.