Pathfinder: My path from Circuits to zkVMs

In my blog series thus far, I’ve discussed vibe coding circuits using Circom. Circom was great for my early explorations because I was trying to prove relatively simple things like random number generation, and I was trying to get all of this done quickly. But I was no longer interested in keeping things simple, I wanted to start proving much more complex things. And I was willing to sink more time into this whole vibe coding thing now, because I had proved to myself that I could make it work. Finally, I was interested in exploring how to use zkVerify in a different way. I had noticed in particular that STARK proofs were not being widely used, so I challenged myself to start using Risc0’s zkVM to prove an entire program.

Initially I was very off put by it. It took me hours to get my computer set up appropriately. I began by trying to simply get their example code to run on my computer which also proved to be relatively challenging. One of my favorite examples was proving that inference from a machine learning model was truly being generated from a model trained on a particular dataset, without having to gather the same data and train the same model. I thought this was incredibly powerful, yet quite challenging to demo to other people.

So I took a step back and thought about how I could create something that was demoable, fun and yet relatively straightforward to write as a Risc0 program and potentially most importantly, something that was simple enough to prove on my local machine.

The Challenge: Prove You Solved the Maze

Imagine a classic maze game. You have a starting point, an ending point, and a complex layout of walls. The challenge isn't just to solve it, but to prove you solved it without showing anyone your solution. This is the core of the ZK Pathfinding demo.

At its heart, the Zero-Knowledge Pathfinding Proof proves one fundamental statement:

"I know a secret sequence of valid moves that correctly navigates from the designated start point to the designated end point within the publicly known maze, without revealing any of my individual moves."

Deconstructing the Proof: Public vs. Private

Like any ZK system, this one operates on a split between public information that everyone agrees on and private information known only to the prover.

What the World Sees (Public Inputs)

This is the information available to anyone, including the verifier. It sets the stage for the challenge.

• The dimensions of the maze (width and height).
• The exact layout of the maze walls and open paths.
• The fixed starting coordinates.
• The fixed ending coordinates.
• A cryptographic hash of the maze layout, which we'll call the Maze ID. This ensures everyone is working with the exact same maze.

What Only the Prover Knows (Private Inputs)

This is the "secret sauce," the solution that the prover wants to prove they possess.

• The precise sequence of $Up$, $Down$, $Left$, $Right$ movements taken to solve the maze.

The Magic Inside the zkVM: From Code to Proof

Here's where the paradigm shift from Circom becomes clear. Instead of designing a circuit to check each possible move, I wrote a standard program (in this case, using Rust) that runs inside the Risc Zero zkVM.

This "guest program" takes the full maze data and the secret path as private inputs. Its logic is surprisingly straightforward and feels like writing a regular validation function:

1. Verify the Context: The program first re-calculates the hash of the maze data it received and confirms it matches the public Maze ID. This is a critical step to prevent cheating by solving a different, easier maze.
2. Simulate the Path: It then simulates the secret path, one move at a time.
3. Assert the Rules: For each step in the simulation, the program makes cryptographic assertions. Think of these as assert() statements that are cryptographically enforced by the zkVM.
   • It asserts the move does not go out of bounds.
   • It asserts the move does not go into a wall.
4. Confirm the Destination: Finally, after the last move, it asserts that the prover's final position is exactly the designated end point.

If the program runs from start to finish without any of these assertions failing, the zkVM generates a ZK proof. This proof is a compact cryptographic artifact that attests to the fact that this specific program executed correctly, producing the public Maze ID as an output, all thanks to a valid, secret path.

Verification: The Payoff of Trustless Certainty

So, the prover has a proof. What does it mean when someone else verifies it?

Verification is the crucial step that brings trust to the system. An external party—be it a user, an API, or a smart contract on a blockchain—can take this proof and instantly gain cryptographic certainty without any of the heavy lifting.

• No Re-execution Needed: The verifier doesn't need to know the secret path or re-run the simulation. The proof itself acts as a compact, undeniable certificate of correctness. This is a game-changer for scalability, especially on blockchains, as it saves immense computational cost (and gas fees).
• Trustless Validation: The verifier doesn't have to trust the prover. The cryptographic guarantees of the ZK proof ensure that if the proof is valid, the underlying computation must have been correct according to the program's logic.

In essence, successful verification means: "Yes, this proof is valid. I am now certain that someone solved the maze identified by this hash, and I didn't need to see their solution or solve it myself."

Beyond the Maze: Real-World Applications

This maze-solver, while simple, is a powerful demonstration of a much bigger concept. The ability to prove correct execution of general-purpose code opens up a vast landscape of applications:

• Private Gaming & Skill Proofs: Prove you achieved a high score without revealing your strategy, or that your move in a turn-based game is valid without revealing your future intentions.
• Confidential Computation & Data Privacy: Prove you're the highest bidder in an auction without revealing your bid. Prove you meet a credit score requirement for a loan without revealing your full financial history. Prove you are over 18 without revealing your birthdate.
• Blockchain Scalability (Rollups): This technology is the engine behind ZK-Rollups. Thousands of transactions can be processed off-chain in a zkVM, with only a single, compact proof posted on-chain, drastically increasing throughput and lowering costs.
• Supply Chain & Secure ML: Prove a product's journey through a supply chain without revealing sensitive vendor details, or prove a machine learning model's prediction was generated by a specific algorithm without revealing the model's weights.

I believe the ZK Pathfinding demo beautifully illustrates the evolution of applied zero-knowledge. I hope this was interesting and insightful. In the next parts of my series I’ll start to discuss some more challenging and fun examples, but wanted to get this out there as a starting point! Enjoy and I look forward to discussing this with all of you!

Check out the ZK Pathfinding Challenge Demo: