# Advancements in on-chain </br> gaming --- ### The early days First blockchain games used simple mechnisms such as randomness, commit reveal schemes and merkle tree proofs to build simple but fun games. --- ### Commit Reveal Schemes (RPS) ```sequence Alice -> Blockchain: commit(bytes32 someHash) Bob -> Blockchain: commit(bytes32 someHash) Alice -> Blockchain: reveal("rock", salt) Bob -> Blockchain: reveal("paper", salt) Note right of Alice: wait for all reveals Alice -> Blockchain: completeGame() Blockchain -> Bob: You win! ``` --- ### Randomness (cryptokitties / raffles / etc) ``` solidity contract RandomnessProvider { /// Stores the block a request is committed to. mapping(bytes32 => uint256) public revealBlock; /// User requests randomness for a future block along with a request id. function commitRandomness(bytes32 _requestId, uint256 _revealBlock) external { require(_revealBlock > block.number, "Must commit to a future block"); require(revealBlock[_requestId] == 0, "Request already submitted"); revealBlock[_requestId] = _revealBlock; } /// Returns the blockhash of the block after checking that the request's target /// block has been reached. function fetchRandomness(bytes32 _requestId) public view returns (uint256) { bytes32 randomnessBlock = revealBlock[_requestId]; require(block.number > randomnessBlock, "Request not ready"); require(block.number <= randomnessBlock + 256, "Request expired"); return blockhash(randomnessBlock); } } ``` ``` solidity function coinflip() view external returns (bool) { return uint256(blockhash(block.number-1)) % 2 == 0; } ``` --- ### Merkel Tree Proofs Using a merkel tree along with a Commit Reveal Scheme, the player can prove the authenticity of his game moves. https://github.com/nicholashc/MerkleShip --- ### Games for Developers Some popular games are [optimizing games](https://github.com/0xBeans/IAmTheOptimizor/blob/master/src/IAmTheOptimizor.sol) and [OxMonaco](https://hackmd.io/@0xMonia/rywyGK4jo#/4) a car racing game. ``` solidity // Problem: An array of length 10 will be pseudo randomly generated along with a target number `n`. Find the // 3 indexes in the array where the values of the array at the 3 indexes sum up to `n`. function compete(address player) external { // check so players dont use other ppls code require(IPlayer(player).owner() == msg.sender, "not your player"); // grab bytecode size uint256 size; assembly { size := extcodesize(player) } unchecked { // pseudo random number to seed the arrays // generate random arrays using seed uint256 startGas = gasleft(); IPlayer(player).solve( randomInputArray, target ); uint256 gasUsed = startGas - gasleft(); // cache LowestPoints memory currScore = lowestPoints; // new submission needs to be more optimized require( oldScore < currScore, "not optimized enough" ); // check indexes actually lead to correct sum require( ...make sure answer is correct... "incorrect answer" ); // burn previous optimizors token and issue a new one to new optimizor _burn(1); _mint(msg.sender, 1); hallOfFame.push(msg.sender); // set new optimizor requirement lowestPoints = LowestPoints( msg.sender, uint64(size), uint64(gasUsed), uint64(size + gasUsed) ); } } ``` --- ## Enter the dark forst Dark Forest: a fully decentralized and persistent RTS (real-time strategy) game. ![](https://i.imgur.com/i0tODST.png) --- - Dark forest is an Incomplete information game. - "Fog of war" is implemented with the power of zkSNARKs. ```sequence Note left of Player: State_1 Player -> Blockchain: H_1 = hash(state_1) Player -> Blockchain: Proof_1 = proof(state_1, H_1) Note left of Player: State_2 Player -> Blockchain: H_2 = hash(state_2) Player -> Blockchain: Proof_2 = proof(state_1, H_1, state_2, H_2) ``` The proof just proves the state changed correctly without revealing the details. --- "In Dark Forest, players don’t submit the coordinates of planets they conquer to the core smart contract - rather, they submit commitments to their planet locations (by hashing the planet coordinates), along with zero-knowledge proofs that the hashes are valid. This keeps planet locations secret." ~ **dark forest docs** --- ##### Some interesting implications: - Users can sell data. Game locations now have value. You can reveal your enemies location to a stronger opponent if they dont pay up :) - Since planet, artifacte and user locations are stored on chain as hashes, users can only discover locations by "hashing” regions of the game universe. - There is a speration between the "data layer" and the UI layer, users can freely create different frontends for the game. Anyone can integrate with dark forest! - [DAOs](https://twitter.com/d_fdao?lang=en) have been formed around the game --- ### Circom circuit example During the planet’s movement, the move circuit checks that the moving range does not exceed the planets maximum allowed movement distance: ``` javascript /* check (x1-x2)^2 + (y1-y2)^2 <= distMax^2 */ signal diffX; diffX <== x1 - x2; signal diffY; diffY <== y1 - y2; // here we load the LessThan circuit component ltDist = LessThan(32); signal firstDistSquare; signal secondDistSquare // <== assign values and also generate constraints at the same time. firstDistSquare <== diffX * diffX; secondDistSquare <== diffY * diffY; // here we set the inputs and assert the output ltDist.in[0] <== firstDistSquare + secondDistSquare; ltDist.in[1] <== distMax * distMax + 1; ltDist.out === 1; ``` --- ### Dark forest UI ![](https://i.imgur.com/fJzqMWR.png) --- --- ### Dark forest app store ![](https://i.imgur.com/o8fpTOF.png) --- ### Bottlenecks - Network fees - Despite using XDAI(Gnosis Chain), fees are still quite expensive when taking into account that every action requires verifying a proof on chain. - Proof generation - Generating such a large amount of proofs is challenging. Users can offload to an external prover. - Map exploration - Map hashing requires a GPU or CPU and can be quite demanding. Users with higher hash rates enjoy an advantage of discovering more resources first. --- ### Dark Forest and Hardware The Dark Forest circuits are written in Circom and executed in Groth16 (WASM by default). Addapting our accelerated RapidSnark implemetation could potentially speed up and lower the cost of proof generation. It is possible to write a external service offering proving as a service. --- # MUD The future of on-chain games ? --- ![](https://i.imgur.com/GqrmJGT.png) --- ### How would you desing a game in MUD? ECS for the rescue ![](https://i.imgur.com/895LJRx.png) --- ![](https://i.imgur.com/2NzAzZ0.png) --- The most impressive game built on MUD so far is a minecraft clone. https://opcraft.mud.dev/ --- ### What is so unique about OPCraft ? 1. Its completely on chain! 2. Its hosted on OPStack, so its incredibly fast and cheap. 3. Its easlity extendable (give dao example) --- ### ZK and MUD Currently MUD dosent have any ZK libraries or standards all state is public. What I would imageine is a system allowing private read and writes. Allowing users to have private state. --- Another interesting system that could be built is ZK challenges. Where a player has tokens staked when joining a game. When challenged for example: "Is your ship at position X?" the player will be given a window of time in which he must generate a valid proof.
{"metaMigratedAt":"2023-06-17T18:54:26.045Z","metaMigratedFrom":"YAML","title":"Advancements in on-chain </br> gaming","breaks":true,"slideOptions":"{\"transition\":\"slide\",\"theme\":\"white\"}","contributors":"[{\"id\":\"882ba7b9-d7b9-4681-bba7-3481539cafa3\",\"add\":9918,\"del\":1804}]"}
    322 views