This topic is to discuss the proposal submitted by @SebastienGllmt
Please see below for the details of the proposal and discussion.
1st Aug, 2024 Funding Note: This proposal is approved for funding. This proposal has a medium impact on the ecosystem. Paima has successfully launched products and thus risk associated with this delivery is low. The budget is inline with the work proposed. We hope the deliverables of game templates will introduce new teams to the ecosystem over mid-term.
13 July, 2024 Current status: Under Consideration. Opened for community discussion on : 13th July 2024
Paima Studios is a game studio building onchain games, and we are building our next commercial game leveraging Mina Protocol. However, multiple public-good infrastructure pieces are missing to enable this.
Notably,
It’s it’s hard to build a commercial product using Mina if you can’t tap into the EVM userbase
Core infrastructure and cryptographic primitives to build games that leverage Mina are missing
To solve this,
We will release MIT open-source primitives for Mina to solve the challenges missing above
We will release MIT open-source templates using these primitives so other companies have a starting point for building their own experience
We will release a commercial game leveraging the primitives (and idle game game where VDFs prove you have idled). Early preview of the Twitter (announced at the time of writing this proposal) here: x.com
Proposal Overview
Problem: there are missing pieces to build a successful commercial product in Mina
Solution: Create public-good infrastructure for Mina, templatize them for ease-of-use, and release a commercial game to prove their viability in business and bring adoption to Mina
Impact: this work will
lower the development cost of using Mina by having more primitives and templates to leverage
increase adoption of Mina by improving access to EVM users and creating a commercial game
For the VDF specifically, there are 2 common algorithms for implementing VDF:
Wesolowski: complex, but faster
Piertzak: slower, but simpler (and recursive)
We will write a VDF verifier and not a prover in o1js, given writing a prover is significantly more complex (in implementation and performance), and isn’t required as the user can generate a proof on their local machine, and all we need in o1js is a verification of this local computation.
Given Piertzak’s implementation uses recursion, we believe this will be the easiest to implement into Mina’s recursion system. Both implementations have a Rust implementation which will serve as the basis of our o1js implementation. Notably, the Piertzak implementation can be found here
Vision
Our plan is to leverage this template to build commercial games leveraging Mina protocol
May: Mina template for basic Paima Engine integration, including
The ability to synchronize Mina events and actions from a rollup node
The ability to connect to and verify signatures of Mina wallets from our SDK
June: Mina template that uses ZkProgram for local proof generation (needed for the game to scale by having the user run a lot of the proof generation on their machine). This will support
EVM wallet usage, including a writeup about how the EVM verification ZkProgram works and benchmark vs other approaches
Connecting it to a batcher system so that games can subsidize tx fees to allow it to be usable from MetaMask
July: Mina template leveraging a Verifiable Delay Function (VDF) verifier to enable use-cases that depend on timers (very common in games)
Additionally,
The template will be live and updated with new features every month
We plan to leverage this in a future commercial game (release date TBD)
Budget & milestones
Deliverables
A Paima Engine template that is updated into 3 parts. One for basic Mina support, another for ZkProgram support, and another for VDF support.
Mid-poiont milestone
A template with Mina support anybody can run, with an implementation for the EVM ZkProgram milestone
Project timeline: 3 months
Budget: 30k MINA
Budget breakdown: 10000 MINA/month on
1 senior developer for the core implementation of the template
2 senior developer part-time for as-needed support (Paima Engine feature requests, o1js support)
1 project manager to review code and ensure milestones are properly met
Build Tarochi, a decentralized RPG game deployed to Arbitrum+Cardano which has 100+ ETH in lifetime volume
Built Paima Engine, one of the largest sovereign rollups in crypto
Build a lot of core infrastructure for Cardano including its most popular Rust SDK
Risks & Mitigations
The main risk we forsee is that even with ZkProgram usage, performance may still be too slow to build a game. We have many options to speed it up including leveraging Zeko which has faster block times and can be used to create L3 with less restrictions than the Mina L1 (ex: more account updates), so we think we can surpass these risks
VDF is a complex primitive and it is sometimes hard to predict subtleties in the implemenetation. We have made this the last milestone to take into account that future work may be required on it
The blogpost about Mina integration architecture was before Aligned Layer announced. Do you still consider using Mina Bridge or Aligned layer for verifying Mina state on Ethereum?
We just released our blog post that talks about the Smart Contract vs ZkProgram topic precisely! It also talks about how we leverage this concept to build our account abstraction system so that players can access our game directly from EVM wallets
I believe Aligned Layer will get us to production faster, and will also lower long-term costs to combining our stack with other systems like DA layers (ex: Avail’s EVM connection is built using SP1 which will also be built with Aligned Layer, which makes it possible to use EVM+Avail+Mina together for an app)
I talk a bit about the trade-off of Aligned Layer vs using the Mina bridge directly near the end of our most recent blog post
Funding Note: This proposal is approved for funding. This proposal has a medium impact on the ecosystem. Paima has successfully launched products and thus risk associated with this delivery is low. The budget is inline with the work proposed. We hope the deliverables of game templates will introduce new teams to the ecosystem over mid-term.
We tried porting the Rust implementation of the Pietrzak VDF to o1js, but even after some modifications to the verifier algorithm, it’s still to to run in o1js. There is one possible idea we have for Pietrzak VDFs that has a chance of working, but the verification time would at least be in the minutes
Given getting VDFs to work in Mina seems it will transition to being more of an open research problem than an engineering problem like we would have hoped, we’ve decided to instead wrap up the initial roadmap of the work with a blog post sharing the different literature we’ve read through along with summarizing the open problems we think could lead to a working VDF in the future
We’ve also open-sourced the code for the benchmark of the GCD step that is required for class groups of an imaginary quadratic field that led us to rule out the Pietrzak VDF approach GitHub - PaimaStudios/o1js-gcd