Title
ZkNoid: mainnet era. The L1 lottery implementation
Project background
ZkNoid is a provable gaming platform. It utilizes zero knowledge technologies to improve gaming experience. Allowing to recursively prove game process state changes in action games. Control privacy in multiplayer games. Hold competitions with leaderboards scores secured by game process proofs. Reduce the cost of playing web3 games moving large calculations to off-chain and proving their correctness.
Platform solves the bad ZK user experience problem. ZK approaches are not native to users and sometimes users get confused about them. Proofs generation, dealing with appchains, game actions proving require a lot of UI explanations, loaders and wrappings for user. In ZkNoid popular ZK gaming patterns are unified and simplified offering a clear way for new users to interact with games
ZkNoid provides SDK allowing developers to bootstrap their games using ready infrastructure and integrate them to the project economy. Framework presents both on-chain and frontend reusable parts. Protokit app network improves UX by enabling gasless sessions, custom fee system and by reducing block creation time
Proposal overview
Within 1M the long awaited Mainnet event is coming to the whole Mina community allowing real users to interact with zkApps. In our project we’re excited with the milestone and eager to launch a game dealing with real assets as soon as possible. Most of ZkNoid games depend on protokit appchain solution that greatly improves gaming experience but not yet ready for going mainnet.
Taking into account the slow block production on L1 (one block once in 3 minutes) we’re heading towards launching a simple lottery game to be the first platform game working with real funds.
During an active round that takes 480 blocks or approximately 24 hours, user can buy any number of lottery tickets to participate in. Each ticket costs 1 Mina + commission (preliminarily 3%) and contains 6 numbers from 1 to 9.
At the end of the round, 6 numbers are generated using VRF. Depending on how many numbers were guessed, tickets are awarded with points.
For example:
- 0 numbers - 0 points
- 1 number - 90 point
- 2 numbers - 324 points
- 3 numbers - 2187 points
- 4 numbers - 26244 points
- 5 numbers - 590490 points
- 6 numbers - 31886460 points
User points for all his tickets are summed up producing user share of the bank funds.
Player can see his win tickets with win amounts and claim the corresponding rewards
Ecosystem impact
-
Code Reuse : ZkNoid has modular design. This means, all the implemented modules for the lottery can be reused by other developers allowing to bootstrap a similar lottery game or a game utilizing similar mechanics. Currently our SDK is used by one external developer, Satyam Bansal who built MinaPolis. We’re expanding our developers community
-
Developer Education: ZkNoid educates people and helps users to touch new technologies. L1 lottery game will bring a lot of new users to the Mina ecosystem making them to face the new ZK approaches. They become interested in the new conceptions of proving, making provable off-chain computations remaining cost effective and allowing to control privacy.
-
Developer Guides: While building we create high quality content containing researches and guides in our blog https://zknoid.medium.com/ and twitter x.com. We’re proud to create a guide “Protokit tips & tricks” that helped a lot of developers and was used as material for lecture held by Mina protocol. Our experience of overcoming obstacles during lottery game implementation would help developers in their mainnet missions.
Ecosystem collaborations
-
Zeko: Participating ZekoBoost contest, testing the platform and reporting issues. The L1 lottery will be deployed to Zeko chain expanding the key infrastructure project in the Mina ecosystem.
-
ZkOn: Integrating VRF for the randomness as well as price feeds and game competitions results feeding to L1. This showcases ZkOn project integration providing feedback and helping other developers in integration
-
AuroWallet: Making adaptations for mobile wallet and investigating L1 token support. Considering to use the token to pay lottery ticket fees in the future. After integration this can showcase mobile intergations for developers and improve the L1 tokens experience on the Mina protocol
-
Pallad Wallet: Investigating integration to our platform allowing to showcase unique wallet features on the lottery game.
-
StakeTab: team who developed MinaScan receiving marketing support. They can boost our mainnet game showcasing a working zkApp for the community. Their section about our project – Minascan Block Explorer.
-
zkok: Community updates & news about zkNoid, including mailing – https://zkok.io/zknoid-testnet-and-rewards-for-participants/.
-
Community participation: For our new games feedback receiving and testnet we launch quest event where users completed tasks related to games playing and testing. We share 500 $Mina among the zkApps pioneers during a giveaway event
Audience
Our lottery audience is divided into two categories. Players and developers.
Players are interested in playing games on the Mina blockchain. The proposed game would be the first gaming zkApp ready for the real funds. Players will try their luck in a fair lottery getting used to ZK gaming experience. Educational materials will help to learn more about the internals of technologies used. Our testers community we’ve build using quest events would be the first players to test the game and give feedback. Target audience is the whole Mina community
Developers can build their own games for the store. Currently SDK is used by one external developer and it’s going to allow plug-in mechanics used in lottery game, reuse ZkOn VRF, Zeko, Pallad Wallet integrations. Would be a great option for building on hackathons. Target audience is the Mina developers who are interested in building games
Architecture
Round structure
- Buying tickets - This phase lasts 480 slots (approximately 1 day). During this phase, users can buy as many tickets as they want. Numbers on tickets are chosen by the user and do not need to be unique across different tickets.
- Determining the winning ticket - After the ticket buying phase is finished, we need to determine the winning ticket. For this purpose, we use ZkOn VRF. This phase lasts up to 960 slots (2 days), and if after that time the winning ticket is not chosen, users can get a refund for purchased tickets.
- Getting reward - This phase is indefinitely long, during which users can claim rewards for their tickets. Each ticket’s score is calculated based on how many numbers were guessed correctly. To acquire the reward, the user must provide proof that the ticket was purchased and not used before, and also provide proof of the total score for the round. The winnings are calculated as bank[round] * ticketScore / totalScore.
Total score proof
Recursive proof is here for proving the total score for a finished round. Proof is updated within each ticket
Onchain values
We’re going to store the following values onchain
- ticketRoot - Root of a 2D Merkle tree. Each leaf of this Merkle tree is the root of a Merkle tree containing tickets for the corresponding round.
- ticketNullifier - Root of a Merkle tree that tracks all used tickets.
- bankRoot - Root of a Merkle tree with bank values for each round.
- roundResultRoot - Root of a Merkle tree that stores the winning numbers for each round packed into a single field.
- startSlot - Slot of contract deployment.
- commission - Determines the commission for a single token.
Functions
Here are the three main functions of the smart contract. Some checks are omitted for simplicity:
buyTicket
- Update the ticket Merkle tree with a new ticket for the current round.
- Update the bank Merkle tree using the ticket price and the number of tickets.
- Transfer funds to zkapp.
produceResult
- Calls the VRF function to generate winning numbers stores it in roundResult map.
getReward
- Check that the ticket is valid and has not been used before.
- Check the total score proof for this round.
- Compute ticket bank shares using the ticket, winning numbers, and total score.
- Update the nullifier so this ticket can’t be used later.
- Transfer funds to the user.
Merkle map
Merkle map data type is responsible for the most of the described merkle tree storing. However, in most cases, we don’t need a Merkle map with a height of 256. For circuit optimization, we will provide a Merkle map with a smaller height.
Action/reducer
Taking into account the slow block production time and the inability to concurrently update the Merkle tree inside a block, we’re going to implement actions/reducers for Merkle tree updates.
Off-chain storage
Off-chain storage stores all Merkle maps and produces Merkle witnesses for users. It also creates the total score proof upon round finish and provides it to users.
Our backend will be TRPC based working with mongodb database under the hood. Routers for the following data will be implemented:
- Tickets list. Stores tickets bought for each round. Used to generate ticketRoot
- Ticket nullifier. Stores info about all the claimed tickets. Used to generate ticketNullifier root
- Bank. Stores info for each round bank funds. Used to generate bankRoot
- Winning numbers. Stores rounds outcomes. Used to generate roundResultRoot
Websocket connection is used to subscribe for events and off-chain data changes, update lottery view once new data is pushed
Design
There are 3 game main views should be located on the game page containing the following elements
-
Current lottery view
- Time counter
- Total tickets bought and the game bank
- Player’s bought tickets
- Buy button
- Button to go to previous lotteries pages
-
Buy tickets view
- Blank ticket with the ability to fill the fields with numbers (Ticket consist of 6 numbers entered by players)
- Button to add the ticket
- Button to confirm the ticket buy
- Exit view button
- Button to randomize the ticket numbers
-
Previous lotteries list
- Show stats about bought tickets and bank
- The winning combination
- Tickets bought by user in previous lottery with correct numbers highlighting and reward size
- Claim rewards button if reward is available
- Switch to older or newer lotteries
User flow
- User enters lottery
- Taps buy button
- Enters numbers for e.g. two tickets and buys them
- Waits for the end of the countdown
- Continues waiting until random generation of win numbers occurred
- Sees that he have a ticket with a reward. Taps claim button and receives the reward
Vision
Our vision is to create a ZK Games Marketplace.
Indie developers can easily create and market new high-quality games with the help of our SDKs, which support most popular game engines. These games can range from traditional board games to action and strategy games. After being validated by a DAO and approved through voting, the games are integrated into our platform.
Users can enjoy these games by browsing the store, bridging funds, and wagering money if they choose. They can invite friends by creating private lobbies or join public competitions. Same as current web2 experience.
Existing Work
On our landing page you can get an overview of our project
ZkApp page is the games store where you can connect wallet and play the ready to play games
Quest event page where testnet players receive rewards for completing tasks involving games testing and playing.
Source code is on github. There are repositories for our extensible games store with SDK for developers, landing and quest pages. Our token repo and L1 contracts
In the documentation you can learn more about the project, learn how to extend it and use SDK
https://docs.zknoid.io/docs
We write high-quality articles telling about the features of Zero Knowledge technologies, educational materials and interesting content. Check it in our blog – ZkNoid – Medium
Twitter with educational materials and project updates – x.com
We’re live, launched testnet and the quest event. Currently there are 4 games live: Arkanoid, Randzu, Thimblerig, Checkers. Poker is half done as cards engine is implemented we need a month more to integrate actual design into it and finish the gaming process implementation.
During the testnet event we collected a lot of bugs and actively fixing them, tuning the games based on the feedback
Budget & milestones
Mid-Point milestones
Contracts
- Implementing main functions buyTicket, produceResult, getReward
- Fee charging mechanism implementation
- Refund implementation
- Total user round score proof implementation
- 90% test coverage for these functions
Backend
- CRUDS for merkle maps storage
- Merkle proof generation
Visual
- Design and basic implementation of Current lottery, Buy tickets, Previous lotteries list views
Final milestones
Contracts
- ZKOn VRF integration
- Backup commit-reveal scheme
- Action/Reducers for merkle map update
Backend
- Recursive total score proof computation
- Full synchronization with L1
Visual
- Design for all the states for all the views. Implementation, connection with blockchain and backend
- Illustrations implementation
- Userflow building
Project Timeline : 1M
Budget Requested : 20.000 MINA
Budget Breakdown
We have the team of four high skilled team full-time working members who are consistently contributing to the Mina ecosystem. The following tasks will be implemented by the team members
- Lottery smartcontract development (4000 Mina)
- Lottery implementation
- Tests implementation
- Front-end smartcontracts integration (2000 Mina)
- L1 modules for ZkNoid framework SDK (1000 Mina)
- Webworker support for lottery L1 contracts, prover keys caching
- Webworker support for recursive proofs generation
- ZkOn VRF integration (1000 Mina)
- Backend implementation (3500 Mina)
- Offchain storage
- Lottery reveal
- Design (3000 Mina)
- Structuring of the 3 game views
- Possible game states research
- Edits, approval
- Design all the lottery views
- Mobile adaptation for auro wallet mobile
- Illustrations implementation
- Animations implementation (external work)
- Front-end implementation (3000 Mina)
- Current lottery view
- Buy tickets view
- Previous lotteries list
- Mobile adaptation for auro wallet mobile
- Initial lottery rounds subsidizing (500 Mina)
- Content (1000 Mina)
- Lottery docs
- Educational materials implementation including blog articles and tweets
- Quest giveaway. 500 Mina will be shared among the community within the next quest event (https://quest.zknoid.io/) taking place from 20th to 30th of June. Reward is distributed among testers for new features testing and providing feedback. Here are the previous quest event giveaway results – x.com
- External work. 250 Mina will be used to pay for motion animator, sound designer services and other external employees job
- Service expenses. 250 Mina will be used to pay for ZkOn monthly services for a month providing VRF
Wallet Address: B62qkh5QbigkTTXF464h5k6GW76SHL7wejUbKxKy5vZ9qr9dEcowe6G
Team Info
This section provides details about team.
We have the amazing complementary team working hard together to push the project forward
Andrey Simaranov
Github: asimaranov (Test Bot) · GitHub
- Top-1 solidity auditor at Mixbytes auditor DAO.
- Core builder of xraise.io project – account abstraction based wallet.
- Blockchain and full-stack developer. Studied at MSU, applied math and computer science
- Implemented launchpads, stakings, wallets, votings, DAOs as a solidity and fullstack developer. Most of contracts are private, here is an example of public contracts contracts/contracts at main · RaiseDAO/contracts · GitHub
- Implemented leaderboard for Mixbytes auditor DAO that become official GitHub - strongholdsec/leaderboard
- Won prizes on EthGlobal Istanbul, India and London
- Designed ZkNoid project architecture, built most infrastructure.
Aleksandr Ivlev
Core builder
- Crypto enthusiast since 2020. CS MS in MIPT. Experienced solidity developer with two years experience in DEFI projects. Implemented arkanoid contracts and games UI for our project.
- Made a huge contribution to the development of ZkNoid smart contracts. Implemented such things as cards engine, arkanoid verification
Shiroy
UI/UX designer
- UI/UX & Graphic designer in crypto since 2022 as a member of PowerPool R&D and marketing team powerpool.finance
- End to end visual design of the project. Designed in figma all the pages like zknoid.io, app.zknoid.io, quest.zknoid.io. Drew all the media illustrations. Works with community and project statistics
Neo Gar
Front-end developer
- Implemented corefront-end.
- Designed and implemented the lobbies UI
Risks & Mitigations
What risks or dependencies do you foresee with building this project?
- ZkOn timings on VRF launch may be delayed. ZkOn may require audits to make the infrastructure secure.
- Mina infrastructure can be hard for users to on-ramp. ZK brings paradigm-changing approaches that may be not native for crypto users. This can be solved by good service UX for on-ramping process, providing instructions and explanations.
- Proofs verification can take too much time especially for users with weak hardware
- Developers may not want to develop ZK games
- We may need the help of a lawyer to resolve some legal issues
- Security vulnerabilities
What are your mitigations if any?
- Support ZkOn in audits and development. Support Mina ecosystem project audits.
- Incentivze developers who want to try ZK gaming with ZkNoid using grant programs, project token payouts hackathons.