This topic is to discuss the proposal submitted by @asimaranov
Please see below for the details of the proposal and discussion.
11th Sept, 2024 Current status: Funded Funding Note: The proposal is approved for funding. The risk of this delivery is low and impact is high. The budget is on the higher end of the spectrum and we are happy to support them as the zkNoid team has been delivering great content throughout their participation in the grant program. This is also the final stretch of their lottery implementation and the proposed changes should improve the user experience vastly.
01 Sept, 2024 Current status: Under Consideration. Opened for community discussion on : 1st Sept 2024
ZkNoid: Road to lottery public testnet and SDK improvements
Project background
Zero knowledge technologies are widely known. They are becoming an integral part of the products we use. And that is for a good reason. They’re bringing an absolutely new dimensions in the space of making trustless systems. Don’t believe, prove it!
ZkNoid is home for provable gaming. Players on Mina Protocol could try the cutting edge games that started using Zero-Knowledge proofs in game mechanics. Being both the publisher and infrastructure provider, ZkNoid creates a closely connected gaming ecosystem
ZkNoid provides SDK for projects to plug in ready modules and start using ZKP in an user-friendly way with minimal efforts. After integration of the desired SDK parts and implementing the provable smart contracts and front-end, game can be listed on the platform. Such layers may be integrated as matchmaking, cards engine, commit reveal scheme, gasless sessions, custom fee system, protokit appchain
Proposal overview
Proposal implies moving towards the two strategic directions for ZkNoid project: improving the Lottery game and working on the platform SDK. The timeline for the proposal is 2 months
Lottery game
During the previous navigator’s proposal the working lottery game have been implemented. It’s a ready to play luck game where users can buy lottery tickets on the Mina network. Then wait for the end of the round and claim rewards – share of the bank depending on how much numbers of winning ticket are guessed correctly. The game can be played here
We overcame a lot of challenges during the proposal implementation. To allow multiple ticket buyings we deeply researched actions/reducers, implemented reduce, distribution proofs. Faced issues working with archive node for fetching and got fixes for them.
The next stage of the lottery game is the preparation for the reliability of public use.
Transactions reordering
While allowing multiple ticket buying transactions in one block using reducer we learnt that we can’t implement the same approach for the rewards claiming. Mina limits the number of account updates per transactions. As every reward transfer require an account update, reducing the claims will require a lot of transactions to make from our backend. We couldn’t left claims to be failed if called in parallel. In some rush hour a lot of players could try to claim and got their transactions failed
To get around we decided to implement the transactions reordering mechanism. Instead of sending transaction to network, frontend will require only to sign the claim. The users signed transactions are stored in database and sent by backend in the correct order to maintain correct merkle list order. This way claim will not fail.
Gift code mechanism
Gift codes are a great mechanism for users engagement. Projects fund their own promo codes on the lottery website. Promo code gives user the ability to enter the code and receive a free lottery ticket. The Project Team can distribute promo codes like airdrop. Players can try to play first time without having Mina and making payments. Users become interested to receive the code. This greatly increases user engagement in social media. New ways of collaborations between projects become possible.
This mechanism will be implemented on backend. After buying the promo code and making a deposit, code is recorded in database. After entering the code, backend executes the buy ticket transaction
UX improvements
After playing the game we noticed some UX pitfalls that require the better wrapping of frontend.
Pending tickets showing
We’d like to show player’s ticket in the pending state if buy transaction is not yet executed. Now ticket is not shown in the interface until the transaction is executed
Transaction links showing
We’ll add on frontend the links to minascan for ticket buying and claiming transactions
Tickets storage
A view to see all the tickets in all the rounds will be added
Backend improvements
There are several optimizations for improving the backend reliability under high load
Moving to micro-service architecture
Monolithic architecture showed several drawbacks in synchronization and scaling aspects. Trying to control the shared access to resources we noticed that redis locks doesn’t unlock in some cases e.g. when proofs generation stuck. Now this suspends all the backend and leads to the whole backend reloading by docker healthcheck. This can be improved using kafka hearthbeats for services. If service stuck – another instance will be used, while the stuck instance is reloaded.
The backend for zkApp considers processing of a big amount of the off-chain data. Merkle roots are generated using the data fetched from archive node. This means the long startup of the backend and the possibility of desynchronization of state manager instance while feeding with new data from archive node. Again, unhealthy state manager service will be restarted while another ready synced micro-service is used
Also using separate services if becomes possible to overcome the o1js prover per thread limit. Making it possible to generate several proofs in parallel, like distribution and reduce proofs
To overcome the issues and make architecture of the backend more clear and nicer, we’re moving towards mircoservices
Optimize statemanager by feeding with new events
Instead of state manager reinitialization it will be able to rollback it’s state and be updated with new events
Optimize reduce proof generation
Instead of reduce proof generation when round end we’ll accumulate it with new tickets buying. This way reduce proof generation time is significantly reduced
Contracts improvements
Here is the work for our contracts to make
Prepare contracts for audit
We have agreed to make a public audit for our smart contracts by extropy.io audit company. User funds will confirm that lottery game follow the required standards to deal with player’s money on mainnet
Content
We want to prepare text and video guides explaining how to play the lottery and answering the common questions
Video overview of lottery game process
Article with rules and answers for FAQ
Quest event
After lottery is reliable and ready for high load, we’ll launch the testnet quest. The goal is to make people play the lottery game, receive feedback and fix bugs reported by users. Then prepare the product to mainnet launch
Quest event launching requires
Implement tasks for the lottery public testnet quest event
Implement tracking for the testnet
Integrate quests for the displaying on the quest page
SDK & games store
We’re constantly delivering new features to the store, increasing it’s value for users and developers. Here are the set of new features to be implemented
Migration to the new protokit version
Recently the protokit app-chain solution published a big update. Architecture was reworked, support for persistent was added as well as storage and async contract functions. Migration requires to move to the new protokit architecture.
Improving support for both L1 and L2 games handling in store
Before the lottery game launch all the games store was built considering protokit support. After moving towards lottery and L1 games we’d like to improve L1 games support on the platform. Global game context will share the type of the game and ZkNoid infrastructure parts will process in the right way
Pallad wallet integration
Pallad wallet is just launched their stable api and become ready for integration. It constantly adds support for the unique features useful on our platform. We’ll allow Pallad wallet users to play games on ZkNoid store and will add support for exclusive features
Devops configs
As testnet users know, when zknoid appchain network was restarted, all the games progress was lost. That’s because protokit haven’t supported the persistent storage. Now all the network progress can be saved to a database. The devops configs will be implemented to launch network in docker-compose in the persistent way supporting startup scripts. Startup scripts are widely used in the platform to initialize the games data like default matchmaking rooms
Hackathon preparation:
ZkNoid SDK is ready for hackers to bootstrap their games with minimal efforts. Soon SDK will be presented for hackers on the EthOnline hackathon. Then – on the EthGlobal in Singapore. The preparation for hackathon will include
Code cleanups & refactoring
SDK architecture and code will be reviewed. The preparations will be made to simplify games building and the codebase understanding. Docstring and comments will be added for improving developer experience
Docs reorganization
The road of ZkNoid building was long and full of challenges. Overcoming the technical issues we changed our vision. Our documentation was implemented while building the project. We want to make a better structure for our docs and align it with the final vision of the project.
In docs there will be a quick overview for project audience: players, developers, investors allowing to easily understand the project idea, find the desired answers and start using ZkNoid
Content for builders & workshops
We’ll implement series of articles about ZkNoid SDK and Mina. We’ll host several workshops based on articles. The following includes
Education article series
Reducers in deep
Writing our own reducers
Batch reducers
Offchain storage
Article & Workshop for developers: How to use ZkNoid SDK
Article & Workshop for developers: Tips and tricks for building on Mina Blockchain
Article & Workshop: Exploring Randzu game
Article & Workshop: Implementing a simple game. An educative video will show developers how to bootstrap a game from scratch
Ecosystem impact
New users coming to Mina ecosystem and interacting to user-friendly zkApps
New developers coming on Mina
Reusable parts for other developers
Developers & Mina users education
Ecosystem collaborations
The following collaboration will take place in the Mina ecosystem
ZkNoid & Pallad wallet
Pallad wallet support will be added to the ZkNoid game store
ZkNoid & Astromina
ZkNoid will announce bounties for builders in collaboration with Astromina
Audience
ZkNoid target audience is represented by two categories. Players and developers.
Players are interested in playing games on the Mina blockchain. 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 & Design
Lottery game
Transactions reordering
Instead of sending claim transaction directly by front end, transaction will be signed with wallet and sent to mongodb. The main problem in claiming is that order of transactions matters and there are no guarantees that transactions sent in one block will be ordered in the right way. So backend will send claim transactions one-by-one per block
Gift code mechanism
Promo code buying mechanism
Frontend asks backend to generate a promo-code and a value to put in transaction memo
Frontend asks user to make a payment transaction with the correct memo
Payment is sent to the network and 20 blocks passing is waited for the finalization
After finalization backend activates the promo-code
Promo code usage mechanism
User submits a promo code to backend
Promo code is verified and invalidated. Ticket buy task is created
Ticked buy task is processed by a background worker.
Buy ticket transaction is sent by the worker and task is invalidated
UX improvements:
Pending tickets showing
When ticket is bought by user, buy transaction hash and ticket info is captured into a zustand store. Store is synchronized with user mempool transactions fetched by mina-mainnet/v1/transactions in blockberry api. The transaction status is periodically polled. Pending status is removed from ticket once transaction is executed
Transaction links showing
Backend will extract transaction hashes and store in mongodb for tickets buyings and reward claims. There transactions links be displayed on frontend for user tickets
Tickets storage
User tickets will be aggregated by backend within all the rounds and shown to user in a special section. This allows to see all the tickets in all the rounds
Backend improvements:
Moving to micro-service architecture
During the last proposal backend had been implemented in a monolithic architecture. Repo can be found here. It consists of several workers in NestJs
Workers are launched within the same NestJs application and their execution is triggered by Cron. While this approach works fine for the current lottery app, migration to the micro-services architecture will improve such aspects of the backend as scalability, prevention of synchronization problems
The workers will be reworked into the following micro-services:
State manager
Proofs and merkle witnesses will be serialized to share between the services. There will be only one point of holding the entire offchain state – state manager service. Other services will ask it to generate a proof or aggregate off-chain information
Events sync
This microservice fetches new actions and events from archive node. The events are captured in the mongodb. Service feeds state manager with the new data
Rounds info updater
Aggregates the off-chain data from state manager service and calculates all the necessary info for the frontend: round bank, round tickets, round winners. After that the info in stored into mongodb to be fetched and showed to user by trpc api
Produce result
This microservice triggers the random generation to choose round winning ticket after it’s end. It’s requests new merkle roots from the state manager
Reduce proving
Generates and sends to network reduce proof, processing the tickets submitted by players
Distribution proving
Generates and sends to network distribution proof, allowing to calculate each player’s share then
Empty ticket buying
Buys and empty ticket in new rounds to allow to prove reduce in the previous round
In the proposed version of backend, workers will become the separate packages that can be launched indecently and managed by docker-compose. They will be connected with kafka. There will be redis locks for transaction sending, proofs, generation.
Micro-services will support heartbeat mechanism. In case if some service e.g. reduce prover stuck or not responding, heartbeat won’t be sent and other group consumer will process the request. If offchain state became broken in some state manager service, it will be marked as unhealthy and reloaded while another consumer is used to process user requests.
SDK & games store
Pallad wallet integration
Pallad wallet unified the interface of dealing with wallets on Mina. We’ll integrate the following interfaces support:
Integration will allow users to choose the wallet they want to use
Provider & event types
Pallad unified the provider types
Wallet dependent calls, window.isAuro / window.isPallad support
There are two wallet apis created by wallet developers. For example Auro and Pallad both support the following calls to get the current wallet address: mina_requestAccounts and mina_accounts . They behave in different ways for different wallets. For example mina_requestAccounts in Auro triggers wallet unlock window if user already used the website. While Pallad returns the wallet address without any interruptions.
These behaviors need to be supported in different ways based on the wallet connected
Docs reorganization
The following docs structure will be applied
ZkNoid Overview
Description about (Description, Benefits, How to use, Partnerships)
ZkNoid Roadmap (Roadmap+History)
Zk Gaming Overview (What is Zk Gaming)
How it works (Network Architecture, high level overview)
Links and Contacts
Games Overview
Arkanoid (Description, Rules, Pictures, Used technologies)
Randzu
Thimblerig
TileVille
Lottery L1
Games Architecture
ZkNoid for developers
Developed Technologies (List of technology with description how it can be used, For examples: Merkel tree…)
Improving support for both L1 and L2 games handling in store
Pallad wallet integration
Devops configs
Content for builders & workshops
Education article series
Reducers in deep
Writing our own reducers
Article & Workshop for developers: How to use ZkNoid SDK
Article & Workshop for developers: Understanding tricky aspects for building on Mina Blockchain
Docs reorganization
ZkNoid Overview
Games Overview
ZkNoid for developers
Project Timeline : 2M
Budget Requested: 100.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 delivered within proposal implementation
Lottery game (50000 MINA)
Transactions reordering (8000 MINA)
Gift code mechanism (8000 MINA)
UX improvements (9000 MINA)
Pending tickets showing
Transaction links showing
Tickets storage
Backend improvements (14000 MINA)
Implementing the following microservices (10000 MINA)
State manager
Events sync
Rounds info updater
Produce result
Reduce proving
Distribution proving
Empty ticket buying
Optimize statemanager by feeding with new events (4000 MINA)
Contracts improvements (3000 MINA)
Contracts preparation for audit (3000 MINA)
Content (4000 MINA)
Video overview of lottery game process (2000 MINA)
Article with rules and answers for FAQ (2000 MINA)
Quest event (4000 MINA)
Implement tasks for the lottery public testnet quest event (1000 MINA)
Implement tracking for the testnet (2000 MINA)
Integrate quests for the displaying on the quest page (1000 MINA)
SDK & games store (50000 MINA)
Migration to the new protokit version (4000 MINA)
Code cleanups & refactoring (5000 MINA)
Improving support for both L1 and L2 games handling in store (4000 MINA)
Pallad wallet integration (4000 MINA)
Devops configs (3000 MINA)
Docs reorganization (6000 MINA)
Content for builders & workshops (24000 MINA)
Education article series
Reducers in deep
Writing our own reducers
Batch reducers
Offchain storage
Article & Workshop for developers: How to use ZkNoid SDK
Article & Workshop for developers: Understanding tricky aspects for building on Mina Blockchain
Article & Workshop: Exploring Randzu game
Article & Workshop: Implementing a simple game. An educative video will show developers how to bootstrap a game from scratch
Team Info
This section provides details about team.
We have the amazing complementary team working hard together to push the project forward
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 GitHub
Implemented the official leaderboard for Mixbytes auditor DAO GitHub
Won prizes on EthGlobal Istanbul, India and London
Designed ZkNoid project architecture
Aleksandr Ivlev
Core builder
Crypto enthusiast since 2020. CS MS in MIPT. Experienced solidity developer with two years experience in DEFI projects. Implemented a lot of parts of the project like lottery game contracts. Implemented reducers guides
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
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 analytics
NeoGar
Front-end developer
Made a huge contribution to the project front-end building
Risks & Mitigations
Security risks
Launching on mainnet and dealing with real funds leads to attacks possibility. To mitigate the risks we’re conducting audit with extropy.io firm.
Our project relies to the ZkOn random verifyable generation. Security issues of ZkOn may affect the lottery. Mitigation includes helping ZkOn project with conducting an audit
The proposal is approved for funding. The risk of this delivery is low and the impact is high. The budget is on the higher end of the spectrum and we are happy to support them as the zkNoid team has been delivering great content throughout their participation in the grant program. This is also the final stretch of their lottery implementation and the proposed changes should improve the user experience vastly.
Hello, here is a quick update on our progress regarding the proposal.
Last week, we concluded the public testnet, where we received valuable feedback and identified several issues. We have addressed many of these, and are now focusing on resolving the remaining issues and implementing the changes proposed in this document.
Over the past six weeks, we have achieved the following milestones:
EthGlobal Singapore Mentorship: Our team served as mentors, assisting three projects that utilized the ZKNoid SDK. These projects are now progressing through the onboarding process.
Gift Code Mechanism: Implemented a gift code mechanism. Some minor issues surfaced during the testnet phase, but overall, it is functioning well.
Audit Process: Successfully completed an audit with Extropy, identifying and resolving multiple issues. The full audit report is available here[Audit – ZkNoid].
Pending Tickets: Finished UX update for pending tickets and finishing backend part for it.
Backend Microservices: Developed and stress-tested several backend microservices, which performed effectively during the testnet.
Contract Architecture Update: Optimized the contract architecture to use one contract per round. This reduced code complexity, decreased transaction proving time, and eliminated redundant proofs.
SDK Migration: Upgraded the SDK to the latest Protokit version, refactoring the runtime module to support asynchronous methods.
ZkNoid is glad to say that the absolute majority of milestones had been successfully achieved!
Check out the fully working lottery game here – https://app.zknoid.io/games/lottery/global
See the latest ZkNoid achievements in our twitter – x.com
Check out educative articles on Medium ZkNoid – Medium