This topic is to discuss the proposal submitted by @asimaranov
Please see below for the details of the proposal and discussion.
01 Sept, 2024
Current status: Under Consideration.
Opened for community discussion on : 1st Sept 2024
This topic is to discuss the proposal submitted by @asimaranov
Please see below for the details of the proposal and discussion.
01 Sept, 2024
Current status: Under Consideration.
Opened for community discussion on : 1st Sept 2024
ZkNoid: Road to lottery public testnet and SDK improvements
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 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
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.
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 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
After playing the game we noticed some UX pitfalls that require the better wrapping of frontend.
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
We’ll add on frontend the links to minascan for ticket buying and claiming transactions
A view to see all the tickets in all the rounds will be added
There are several optimizations for improving the backend reliability under high load
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
Instead of state manager reinitialization it will be able to rollback it’s state and be updated with new events
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
Here is the work for our contracts to make
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
We want to prepare text and video guides explaining how to play the lottery and answering the common questions
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
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
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.
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 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
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
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
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
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
We’ll implement series of articles about ZkNoid SDK and Mina. We’ll host several workshops based on articles. The following includes
Ecosystem collaborations
The following collaboration will take place in the Mina ecosystem
Pallad wallet support will be added to the ZkNoid game store
ZkNoid will announce bounties for builders in collaboration with Astromina
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
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
Promo code buying mechanism
Promo code usage mechanism
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
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
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
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:
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
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
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
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
Generates and sends to network reduce proof, processing the tickets submitted by players
Generates and sends to network distribution proof, allowing to calculate each player’s share then
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.
Pallad wallet unified the interface of dealing with wallets on Mina. We’ll integrate the following interfaces support:
mina:requestProvider
eventRecently pallad proposed a call to list all the mina wallets connected to a website and allow user to choose one. The proposal had been approved by auro wallet as well: feat: add multi-provider discovery events by mrcnk · Pull Request #39 · aurowallet/auro-wallet-browser-extension · GitHub
Integration will allow users to choose the wallet they want to use
Pallad unified the provider types
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
The following docs structure will be applied
Mid-Point milestones
Lottery game
SDK & games store
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)
SDK & games store (50000 MINA)
Content for builders & workshops (24000 MINA)
This section provides details about team.
We have the amazing complementary team working hard together to push the project forward
Andrey Simaranov
Github : asimaranov
Aleksandr Ivlev
Core builder
Shiroy
UI/UX designer
NeoGar
Front-end developer
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
Definitely a large sum asked.
Very curious about the audit and audit costs.
I think here is an erc 20 audit https://minaprotocol.com/wp-content/uploads/Veridise-Mina-Fungible-Token-Standard-Audit.pdf done by a different firm which I am yet to read through.
Aside from audit. Definitely legal costs related to gambling are huge due to gambling licenses.
From what I understood from talking to VCs and lawyers ERC 20 require also an additional legal structure.