ZkNoid: L1 Lottery/SDK improvements

Mina Navigator Proposals
1

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

2 Likes
2

Title

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

  1. Frontend asks backend to generate a promo-code and a value to put in transaction memo
  2. Frontend asks user to make a payment transaction with the correct memo
  3. Payment is sent to the network and 20 blocks passing is waited for the finalization
  4. After finalization backend activates the promo-code

Promo code usage mechanism

  1. User submits a promo code to backend
  2. Promo code is verified and invalidated. Ticket buy task is created
  3. Ticked buy task is processed by a background worker.
  4. 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:

  • Support of mina:requestProvider event

Recently 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

  • 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…)
    • Technology Architecture (Multiplayer, Competitions, Cards engine…etc)
    • SDK - Development Kit
    • Guides
    • Integration Guide
  • ZkNoid Token
    • Tokenomics
    • Revenue Model
    • Token distribution and treasury
  • Security
    • Audit
    • Bug Bounty

Budget & milestones

Mid-Point milestones

Lottery game

  • Gift code mechanism
    • Initial implementation
  • Contracts improvements
    • Contracts preparation for audit
  • UX improvements
    • Pending tickets showing
  • Backend improvements
    • Implement microservices:
      • State manager
      • Events sync
      • Rounds info updater
      • Produce result
    • Optimize reduce proof generation

SDK & games store

  • Migration to the new protokit version
  • 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

Andrey Simaranov

Github : asimaranov

  • 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 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

1 Like
3

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.

1 Like