ZkNoid:L1 Lottery

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.

22nd July, 2024
There is a delay in the delivery of this proposal as the team is awaiting the VRF to be connected to the solution. We are in touch with the team and will update as progress is made.

14th June,2024
Current status: Funded
Funding Note: We see this proposal to a useful zkApp to Mina L1. This we see has very high impact in relation to attracting users and increasing protocol usage. Integration with ecosystem partners is very much valued and this can serve as a template for other applications. The builders are part of the ecosystem and have delivered successfully in the past. The risk is classified as Medium because we have identified a potential race issue and have a solution which we are discussing with the team. zkApps dealing with tokens carry an inherent risk. Budget is on the higher side , but the impact justifies the funding decision.

2nd June,2024
Current status: Under Consideration.
Opened for community discussion on : 02 June, 2024.

2 Likes
2

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

Untitled
Untitled1722Ă—1748 221 KB

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

  1. 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.
  2. 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.
  3. 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

  1. 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.
  2. ticketNullifier - Root of a Merkle tree that tracks all used tickets.
  3. bankRoot - Root of a Merkle tree with bank values for each round.
  4. roundResultRoot - Root of a Merkle tree that stores the winning numbers for each round packed into a single field.
  5. startSlot - Slot of contract deployment.
  6. 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:

  1. Tickets list. Stores tickets bought for each round. Used to generate ticketRoot
  2. Ticket nullifier. Stores info about all the claimed tickets. Used to generate ticketNullifier root
  3. Bank. Stores info for each round bank funds. Used to generate bankRoot
  4. 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

    1. Time counter
    2. Total tickets bought and the game bank
    3. Player’s bought tickets
    4. Buy button
    5. Button to go to previous lotteries pages

  • Buy tickets view

    1. Blank ticket with the ability to fill the fields with numbers (Ticket consist of 6 numbers entered by players)
    2. Button to add the ticket
    3. Button to confirm the ticket buy
    4. Exit view button
    5. Button to randomize the ticket numbers

  • Previous lotteries list

    1. Show stats about bought tickets and bank
    2. The winning combination
    3. Tickets bought by user in previous lottery with correct numbers highlighting and reward size
    4. Claim rewards button if reward is available
    5. Switch to older or newer lotteries

User flow

  1. User enters lottery
  2. Taps buy button
  3. Enters numbers for e.g. two tickets and buys them
  4. Waits for the end of the countdown
  5. Continues waiting until random generation of win numbers occurred
  6. 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.
1 Like
3

Hey, I love the idea of the first Mina lottery game :slight_smile:
Few questions:

  • Could you explain a bit more in detail how are you planning on using action/reducer? How often are you planning to reduce and update the merkle, keeping in mind the limit of actions that can be reduced?

  • Who is responsible for calling VRF result? Can anyone invoke it?

  • Have you considered how would you mitigate the risk of an off-chain server going down?

  • It’s a little bit unclear to me why have you chosen those particular lengths for each phase. Would be great to understand that bit more, is that to do with VRF itself?

2 Likes
4

Hey,I like this idea.Is this like https://yologames.io/ on Blast ?

5

Thanks for the questions! Let me explain them all

  1. Action/reducer are used to allow multiple ticket buying transactions in the same block. This way the order of buy transactions doesn’t matter. However this solution brings the necessity to call a special contract function before the action queue is full. Otherwise next buy transactions will fail. It will be called by our backend or by any users as it’s open to call by anyone

  2. VRF is provided by ZkOn project and there will be a function to launch the random generation after the round end. This function can be called by anyone if for some reason the backend goes offline

  3. The main risks when server goes offline are not working infrastructure and data lost. Our backed will be open source that means anyone can launch his own instance. The other thing is that backend stores the merkle trees data used to generate merkle root. We’ll implement a way to recover this data from archive node by parsing events. This approach can be used by anyone to recover the data and start the backend on their servers

  4. Block production on Mina is pretty slow. Because of this we need to make all the time intervals big enough to cover the risks of block production delays. At the same time we don’t want to make users wait for a long time for the lottery results. Based on these considerations we chose one day period for the buying tickets phase. Period for the VRF generation chosen as 2 days to be safe enough to generate a random number considering any possible issues with infrastructure. While remaining reasonable for users to wait for the tickets cost refund if something completely unexpected happened with the infrastructure. Waiting for the previous round random generation doesn’t block the next round start

2 Likes
6

Thanks for the question! Something like that. But our lottery would be more classical with tickets buying. And instead of betting against platform, all the round funds will be redistributed among participants with a small service fee charging

2 Likes
7

Hi!

Thanks for the proposal. Some questions.

Can you elaborate on how the points were chosen for the numbers?

Can you please clarify if i understand the above variables correctly:

  • Bank[round] - Total MINA of all tickets purchased for this round.
  • ticketScore - Ticket score as calculated above
  • totalScore - How is this computed ?
  1. Can you please elaborate on round mechanics. Is it block based draw (480) or is it time based draw.
  2. Could you please explain the winning draw? VRF AFAIK can generate a random number on every call. How do you match the VRF number generated to round end? Is it coded to a specific timestamp?

Thanks!

1 Like
8

Awesome questions!

  1. Numbers corresponds to probability of guessing. We calculated it as 1/9^n * C_n^k for each n from 0 to 6(n - amount of numbers, that guessed correctly). So expected value for each outcome is equals

  2. totalScore is computed on backend(or by any user who stores ticket merkle tree) as a proof. Its equals to sum of points of all ticket points in this round

  3. We basically considered time base draw, but for now picked blocks(slots) number. It is not curtails which one we will choose.

  4. VRF called once after buy ticket round ends. Result of this VRF is stored on the result merkle tree. Winning ticket generation is bounded to round, and will fail in case it is calculated too early or if winner ticket was previously used

1 Like
9

Thanks for the replies. Let me take an example to clarify my VRF/Draw question.

Ex: 1 (Block based draw)

Game Start : Block 361152 : UTC 00:00 10th June , 2024
.......
Game End   : Block 361632 : UTC 23:30:11s 10th June, 2024 (+480 blocks)

We ended the game above when the block 361632 was added at the time mentioned (UTC 23:30:11s 10th June, 2024). Is the VRF API call tied to this time or is it irrelevant to the game? Can you please explain how to use the VRF API in this game to fetch the draw?

2 Likes
10

Once game ended, it enters the Determining the winning ticket phase. So when the first (tickets buying) phase is over - anyone can call a function to produce the winning number during the second phase. But this function can be called only once. Result the of VRF call lies in the result merkle tree(in fact merkle map - round → round result)

2 Likes
11

Can’t wait to buy tickets!.

Also Wouldn’t it be awesome If i can gift lottery tickets to my loved ones. just by entering their wallet address and paying the ticket cost.
If this feature exist, I would definitely surprise 50 peoples :sweat_smile:.

3 Likes
12

Is the result of this VRF call deterministic at the end of each round? What information is sent to the VRF API to fetch the result? I am trying to understand if there is also a possibility for the last ticket buyer to simulate results?

1 Like
13

Discussed this with ZkOn team. We will call VRF function on ZkOn zkApp from our smartcontract after round finished. After a while VRF generates a single random number for us and pushes it to our contract by calling a special zkApp function

14

No it is not deterministic. Random number is provided by VRF, and is not based on tickets information

15

I think you may hit a problem when trying to implement action/reducer model with current design.
Even if you manage to always clean the action queue before it’s full, you may find that as you’re hitting reduce, some user may try to dispatch an action before your transaction gets included in the block which will then lock the contract.

You also will have to use action/reducer for withdrawals right? As you have to update nullifier root. You haven’t mention that. Which again poses same issue as above.

2 Likes
16

Hi.

As far as I know, Mina stores actionState for 5 last block in which actions were dispatched. So we need to generate reduce transaction within ~ 15 minutes, and the contract will not be locked. We are going to achieve it, as was suggested on some topic on discord, via recursive proofs. So we’re going to send a transaction, which proves that actions can be reduced.

With nullifier we are going to try to do the same thing. However, with nullifier, the problem is a little bit more complicated because, in withdraw transaction we will need to check not only nullifier tree, but also all actions. We are still thinking about how to deal with it.

All of this havent been mentioned in the proposal as long as it is still under development. The core logic can work completely without reducers, but with a way worse UX.
Implementing action/reducers is one of the tasks of this proposal.

2 Likes
17

Exciting to see and great for user engagement. :+1:

1 Like
18

I think there’s a way to implement a purely L1 lottery, with little technical complexity, here’s how i’d do it:

Its relatively simple, there is a smart contract which you can use to purchase tickets, 1 ticket = 1 MINA (or actually less because 1e9 precision, needs to be adjusted in the example pseudo implementation). There is a max amount of tickets you can buy per action (so that we can iterate over a fixed size loop later on).
Buying tickets results in an action recorded on the L1 in the format of: [PublicKey, Amount (of tickets purchased)]
Tickets can be purchased only in the purchase period between certain blocks.
Then randomness needs to be captured in the form of epoch data, this needs to be adjusted in a way, that the epoch data / seed is not know before it is captured. So there needs to be sufficient delay between ending the lottery and capturing the seed. (i believe, but subject to research)

Once the randoness seed is captured, and all the tickets are bought as well → represented as actions and an actions hash. We can iterate over all the actions in an off-chain program. The program fills a merkle map (large tree basically) with tickets, using an incremental index of 0…2^255, keeping track of which index was used last (what is the highest index). Every leaf will store a public key in it, and thats the public key dispatched in the action previously (person who paid for the tickets. The program allocates as many leaves as the person bought tickets in the given action. If you buy 100 tickets, you get 100 leaves in the tree. The program outputs the tree’s root hash, the actions hash it processed (must then match precondition on-chain/L1). Plus it also emits the seed for the randomness it has used. The epoch data seed (randomness seed) is then linearly scaled down from its range of 0…2^255 (since its a hash, it can span the entire field) down to a range of 0…{#numberOfTickets}, where number of tickets is the largest index in the tree you’ve populated incrementally. Of course this would mean that every loterry will have one winner. You can play around with the ranges, to make it work in a way that not every lottery is won, and the amount is carried over the the next lottery. The winner is announced by providing a merkle witness, that evaluates to the same root hash as the winner calculation program proof. This can be executed by anyone, even in a browser, all they have to do is have access to an archive node to fetch the actions, and process them then submit them to the contract to claim the funds. Its completely decentralized, you dont need any off-chain storage, it works completely on the L1. It is in the best interest of everybody for this to happen on the L1, because block producers will make money from the tx fees.

The original design has quite a lot of complexity and uncertainities coming from miss understanding how actions work, i think they can be utilized very effectively to serve as a record of purchasing ticket(s).

1 Like
19

Hi, maht0rz.

Thank you for suggestion.

However we see following benefits of our own design:

  1. Faster Random Generation. We agree that it would be awesome to use epoche seed, but unfortunately new value for it is generated once per 14 days. We consider that this delay is too long. By using VRF we will both improve user experience and help in the development and showcasing of ZKON. We are considering the collaboration with ZKON project extremely beneficial for the Mina ecosystem. There are a lot of new opportunities of data providing useful in zkApps. Random feeding is a very good showcase. More advanced data providing can be used in future or by other projects built on Mina.

  2. Multiple Winners and Clear Rules. Our approach allows for multiple winners per round, similar to a traditional lottery. The more numbers a participant guesses correctly, the bigger the reward. Your solution, with only one winner per round, might make the game less enjoyable.

We believe these features will attract more users, especially those unfamiliar with Mina, thanks to the clear rules and better user experience.

1 Like
20

Hey,
yes, you would be able to call the reduce before the queue is full but that’s not what I’ve said about locking the contract. There is a high likelihood of users trying to dispatch as you’re reducing.

The solution that will work would require making snapshots of actions, reversing them and iterating from the latest. (this will take 2 storage field elements but you have proposed 6 so still should be good). I can explain a bit more in detail later on.

On top of that, you’ll have to create an account for the user that has the correct permissions so the tokens can definitely be sent (a problem if a user has permission.receive set to signature for example).
I’m referring to a similar problem as it is defined here:
https://docs.minaprotocol.com/zkapps/writing-a-zkapp/introduction-to-zkapps/secure-zkapps#dont-deadlock-your-zkapp-by-interacting-with-unknown-accounts

Unfortunately, this whole pattern and issue is not well documented, it has been mentioned to the o1labs and MF already.

If you’re happy to implement such an approach, I’ll help you with it. Ideally, we could discuss more on call and you guys could make it as reference implementation (currently there is some draft code that shows how it’s done from guys at o1labs, I could clean it up and provide you as boilerplate that you can adjust for you application/design and hopefully the whole community can benefit from it as well)

4 Likes