Logbook: ZK Battleship - part 1

Source: Dev.to

The Hackathon

February 2026 – The Stellar Development Foundation announced Stellar Hacks: ZK Gaming, a hackathon to build on‑chain games using zero‑knowledge proofs.
The prize? Recognition, feedback from Stellar devs, and the chance to show that ZK isn’t just academic‑paper stuff.

I signed up without ever having made a game before. I thought it would be just another project with smart contracts and maybe a bit more interesting because it required implementing zero‑knowledge proofs. In my head, writing a Battleship would be perfect to integrate with ZK.

Devlog – Stealth Battleship

• Duration: 17 days
• Commits: 331
• Languages: 4

The Problem

You know Battleship: two players, each with a board, place their ships, then take turns attacking coordinates. The opponent replies “hit” or “miss”.

In the physical world the boards are hidden behind a barrier. In the digital world, who guards the boards?

Approach 1 – Server‑side authority

The server sees everything. It works, but you must trust the server not to cheat. If the server wants to favor a player, it can, and you’d never know.

Approach 2 – Commit‑reveal

Each player hashes their board at the start and publishes the hash. At the end they reveal the original board and everyone checks the hash.
Vulnerability: a losing player can simply disconnect and never reveal, leaving no proof.

Approach 3 – Board on‑chain

Put everything on the blockchain – verifiable and immutable.
Problem: the blockchain is public. Anyone can read the transactions before they’re confirmed, so your opponent would see your ships before the game even starts.

None of the three works. They all fail because, at some point, someone sees information they shouldn’t.

Zero‑Knowledge Proofs (ZK) to the Rescue

The idea is simple to understand, but profound in its consequences:

I can prove to you that something is true, without showing you the information that makes it true.

Analogy – The Diamond

Imagine I’m preparing a surprise marriage proposal. I ask a craftsman to create a diamond ring, but the ring must stay hidden. The craftsman makes a claim: “The diamond on the ring is real.” I want to be sure, but seeing the ring would ruin the surprise.

I take the ring to a diamond specialist. He examines it, runs the necessary tests, and hands me a certificate that says:

• The analyzed diamond is real.
• The stone passed all authenticity tests.

I never saw the ring, its size, shape, color, value, or any other detail. Yet I have a proof. I have zero knowledge about the ring, except that it is real.

In the game: the board is the diamond, the specialist is the math.

How the Game Works with ZK

1. Start: Each player places their ships and generates a ZK proof that the board is valid. The proof is public; the board is not.
2. Each move: When I attack coordinate (3, 5) on my opponent’s board, they reply “hit” or “miss” and send a ZK proof that the answer is honest with respect to the original board.
3. End: When all ships are sunk, the entire match is replayed inside a circuit that deterministically calculates the winner and generates a final ZK proof.

Nobody ever sees the other’s board. There’s no omniscient server. There’s no reveal that can be avoided. Math guarantees everything.

Stellar Protocol 25 – “X‑Ray”

Stellar just launched Protocol 25, codename X‑Ray. This upgrade added advanced cryptography operations — BN254, Poseidon2, and BLS12‑381 — directly into the protocol (not in smart contracts, not on L2).

Why This Matters

Verifying a ZK proof requires heavy math: elliptic‑curve point multiplication, hashing, pairings. On other blockchains this runs inside smart contracts, which is slow and expensive. On Stellar these operations are now native protocol instructions.

Result: Verifying a ZK proof on Stellar costs around $0.005 USD, orders of magnitude cheaper than on any other blockchain.
(Yes, I initially thought it was $30 USD – I explain this mistake in Part 3.)

First Prototype (48 hours)

• Board: 6 × 6 with 3 ships
• AI: Hunt/target algorithm
• Features: Animations, ranking, match history, dark naval aesthetics, Orbitron fonts, navy‑blue gradients with gold accents, tutorial, configurable difficulty, internationalization in 3 languages

It looked great, but it was a normal game – no ZK, no blockchain, nothing that justified the hackathon.

Project Timeline

Feb 23 deserves an asterisk. 112 commits in a single day – the day everything needed to work together: ZK proofs generated on the client, verified on the backend, submitted to the blockchain, with two real players facing each other via WebSocket online.
Each fix led to another bug, which led to another discovery. GOOD TIMES GUARANTEED.

What’s Next

In the following articles I’ll dive into each phase with real code, real mistakes, and the “eureka” moments that made the project work:

1. Part 2: Writing ZK proofs in Noir and discovering that the mobile app can’t run ZK proofs (bb.js)
2. Part 3: Verifying proofs on the Stellar blockchain and spending 214 XLM chasing a bug
3. Part 4: Connecting two players in real time and the avalanche of race conditions
4. Part 5: The lesson that cost 214 XLM — what I learned and would do differently

If you’ve never worked with ZK, blockchain, or games together — well, neither.

her had I. Let's go.

### Next: Part 2 — "Proving without showing"