Turbo Noir ZK gaming framework

[Chomtana]

Summary

Turbo Noir is a framework that lets you add Zero-Knowledge (ZK) proofs to your games or apps — or build new ZK games from scratch — without knowing any cryptography. Just write your game rules once using a simple action → reducer style, and the framework takes care of all the proof and blockchain steps.

Motivation

We have spent the past year trying to make fair peer-to-peer games. The big problem: without a central server, cheating is easy, and even fancy voting systems (BFT consensus) fail if all players cheat. ZK proofs looked like the only real fix.

But building a ZK circuit for even a tiny 2048 game was painful:

• The circuit was hard to design and ate up weeks of work.
• Writing simple “if” branches was awkward.
• Generaing a ZK proof for 2048 game took almost 10 minutes.

Frameworks such as RISC-0 and SP1 let us write circuits in Rust and sped things up, but we still needed an extra Groth16 proof (≈1 minute) for on-chain verification, and those framworks can’t do recursive proofs like Noir can.

Even with Rust or Noir you still face tough chores: checking signatures, hashing moves, keeping data in sync across front end, back end, prover, and smart contract and managing multiplayer sessions.

Moreover, most games require randomness, but secure and fair randomness has never been implemented in any ZK framework.

Turbo Noir solves these problems. It ships with:

• Plug-and-play signature and hashing helpers.
• Multiplayer websocket server.
• Built-in ZK-secure and fast provably fair randomness and card-shuffling cryptography.

And while it’s built for games, you can use the same framework to build any verifiable app (vApp) that needs trust-free proofs.

Methodology

We already have Turbo’s ZK gaming framework running on SP1 and we can port it to Noir, so here’s the developer journey on Turbo SP1:

1. Clone the boilerplate

   git clone https://github.com/turbo-ing/turbo-sp1

   (It works, but we admit the flow could be smoother—that’s what the next iteration is for.)

2. Define your game state
   Open lib/src/state.rs and define the struct that captures every value your game needs to track.

use alloy_sol_types::sol;
use serde::{Deserialize, Serialize};

sol! {
    #[derive(Serialize, Deserialize, Debug, Default)]
    struct GamePublicState {
        uint32[4][4] board;
    }
}

#[derive(Serialize, Deserialize, Debug, Default)]
pub struct GamePrivateState {
    pub moves: u32,
}

3. List the possible actions
   In lib/src/action.rs, create an enum for every kind of move a player can make.

use serde_json::Value;
use turbo_program::traits::TurboActionSerialization;

#[derive(TurboActionSerialization, Debug)]
pub enum GameAction {
    MoveAndRandomTileAction(u8),
}

4. Write the reducer
   Implement how each action updates the state in lib/src/reducer.rs. The reducer takes the current state plus an action and returns the next state—nothing else to worry about.

pub fn reducer(
    public_state: &mut GamePublicState,
    private_state: &mut GamePrivateState,
    action: &GameAction,
    context: &mut TurboActionContext,
) {
    match action {
        // GameAction::MoveAction(direction) => {
        //     public_state.board = move_board(&public_state.board, *direction);
        //     private_state.moves += 1;
        // }
        // GameAction::NewTileAction(r, c) => {
        //     if public_state.board[*r as usize][*c as usize] == 0 {
        //         public_state.board[*r as usize][*c as usize] = 2;
        //     } else {
        //         panic!("Cannot place new tile in non-empty position");
        //     }
        // }
        GameAction::MoveAndRandomTileAction(direction) => {
            *context.client_response() = None;

            // A fix for initial state
            if private_state.moves == 0 {
                let rand = context.rand_u32() % 16;
                let (r, c) = (rand as usize / 4, rand as usize % 4);
                public_state.board[r][c] = 2;
                private_state.moves += 1;

                #[cfg(not(target_os = "zkvm"))]
                {
                    *context.client_response() = Some(json!({
                        "r": r, "c": c
                    }));
                }

                return;
            }

            let new_board = move_board(&public_state.board, *direction);
            private_state.moves += 1;

            let mut empty_positions = Vec::new();
            let mut is_moved = false;
            for row in 0..4 {
                for col in 0..4 {
                    if new_board[row][col] == 0 {
                        empty_positions.push((row, col));
                    }

                    if public_state.board[row][col] != new_board[row][col] {
                        is_moved = true;
                    }
                }
            }

            if is_moved {
                public_state.board = new_board;

                if !empty_positions.is_empty() {
                    let rand = context.rand_u32();
                    let (r, c) = empty_positions[rand as usize % empty_positions.len()];
                    public_state.board[r][c] = 2;

                    #[cfg(not(target_os = "zkvm"))]
                    {
                        *context.client_response() = Some(json!({
                            "r": r, "c": c
                        }));
                    }
                }
            }
        }
    }
}

5. Launch the websocket game server
   One command boots a local server that automatically handles player connections and pipes every move through the reducer while queuing up the ZK proofs.

6. Plug in your front-end
   Whether you’re using Unity or a browser build, our SDK wires your client to the websocket layer and takes care of all the operations from game start to proof generation.

7. Deploy to Turbo Cloud
   When it all looks good, deploy your module to Turbo Cloud. We scale the websockets and send proof generation request to the prover network for you.

If this grant is approved (or, even better, you back us with investment), we’ll port the entire stack to Noir, build a few example games and help with teams who want to build ZK game on Noir and Aztec

Business Model

TODO

Timeline and Deliverables

• 31 August 2025 - First working version of Turbo Noir ZK gaming framework for session-based games
• 30 September 2025 - Unity and Web-based games integration
• 30 September 2025 - A few basic example Noir-powered ZK indies game from us (2048, Snake, Candy Crush, etc) launched on Aztec (If the chain is ready for use) and an EVM chain
• 31 October 2025 - Aztec gaming portal
• 31 October 2025 - Turbo Noir ZK gaming framework for long-running games such as snake.io and agar.io
• 30 November 2025 - Either Noir powered snake.io or agar.io

Team

Chomtana Chanjaraswichai (Lead)

[email protected]

• Build Mina 2048 and SP1 2048 game using Turbo Framework
• Develop Turbo SP1 ZK gaming framework
• Develop an initial version of peer to peer gaming framework using libp2p
• Won multiple global hackathon in Web3, and ZK gaming at events such as Based SEA and ETHGlobal
• Built RetroList, now the primary project‑discovery interface for Optimism Retro Funding, got retweeted by the Optimism Foundation
• Won more than 300k OP grant both with Upnode team and personally

Alex Westlake

[email protected]

• Implement Mina ZK circuit for 2048 Mina game
• Build P2P (peer-to-peer) framework
• Building agar.io game using our peer-to-peer framework
• Research on using ZK proof to prevent fraud on P2P network

Start Date

1 July 2025